在
web安全中，认证授权又是每个人都熟知的，就像我们都应该设置一个高强度的密码，以免被猜测破解，实际上还包括更多内容。
1. 权限
在很多系统如CRM，ERP，OA中都有权限管理，其中的目的一个是为了管理公司内部人员的权限，另外一个就是避免人人都有权限而帐号泄漏后会对公司带来的负面影响。
权限一般分为2种：访问权限和操作权限。访问权限即是某个页面的权限，对于特定的一些页面只有特定的人员才能访问。而操作权限指的是页面中具体到某个行为，肉眼能看到的可能就是一个审核按钮或提交按钮。我之前接触过的一个SAAS平台的CRM系统就用到了访问权限和操作权限两种，而现在公司后台管理都是访问权限，当然访问权限实施起来更加方便快捷，也容易维护。
权限的处理方式可以分为2种：用户权限和组权限。设置多个组，不同的组设置不同的权限，而用户设置到不同的组中，那就继承了组的权限，这种方式就是组权限管理，一般都是使用这种方式管理。而用户权限管理则比较简单，对每个用户设置权限，而不是拉入某个组里面，但是灵活性不够强，用户多的时候就比较费劲了，每次都要设置很久的权限，而一部分用户权限是有共性的，所以组权限都是目前很通用的处理方式。
在权限方面，还包括了
数据库的权限，网站管理的权限以及API/Service的权限。
DBA都需要控制好IDC的数据库权限，而不是将用户权限设置为*.*，需要建立专门供应用程序使用的帐号，并且需要对不同的数据库和不同的表赋予权限，专门供应用程序使用的帐号就不能进行更改表，更改数据库及删除操作，否则如果有
SQL注入漏洞或程序有bug的话，黑客就能轻易连接到数据库获取更多的信息。因为DBA帐号除了可以更改数据库结构，数据，及配置之外，还可以通过LOAD DATA INFILE读取某个文件，相当于整台服务器都被控制了。
API可以分为private API和open API。那私有API一般是不希望外网访问的，如果架设在内网的话，最好使用内网IP来访问，如果是公网的话，最好设置一定的权限管理。Open API的权限就相对复杂很多，除了校验参数正确性，还需校验用户是否在白名单中，在白名单里的话还需校验用户对应的权限，有些时候还需要考虑是否要加密传输等等。
2. 密码猜测
以下哪种错误提示更加适合呢？
1）输入的用户名不正确
2）输入的密码不正确
3）输入的用户名或密码不正确
看到前面两种提示信息，我们获得了什么信息呢？用户名不正确那可以猜测到正确的用户名，当只是提示密码不正确的时候说明用户名正确了，这两种提示其实是在暗示用户正确输入了什么，哪个不正确。而第三种给出的提示就比较模糊，可能是用户名可能是密码错误。如果非要说前两种提示信息更准确更易于普通用户的话，就会给黑客们带来可乘之机，而第三种就没辙了，实在不知道到底是哪个错误了，难道增加不少。使用工具或批处理脚本来强制枚举破解的话也需要更多的时间。
弱密码你中枪了吗？
2011年11月22日，
360安全中心发布了中国网民最常用的25个“弱密码”： 000000、111111、11111111、112233、123123、123321、123456、12345678、654321、666666、888888、abcdef、abcabc、abc123、a1b2c3、aaa111、123qwe、qwerty、qweasd、admin、password、p@ssword、passwd、iloveyou、5201314。别人给我使用过的管理帐号中就有设置这样的密码，非常危险。
那如何应对密码猜测攻击呢？一般有以下几种方案：1）超过错误次数帐户锁定；2）使用RSA/验证码；3）使用安全性高的密码策略。很多网站三种结合起来使用的。另外，在保存密码到数据库时也一定要检查是否经过严格的加密处理，不要再出现某天你的网站被暴库了结果还存的是明文密码。
3. 找回密码的安全性
最不安全的做法就是在邮件内容中发送明文新密码，一旦邮箱被盗，对应网站的帐号也会被盗；一般做法是邮件中发送修改密码链接，
测试时就需要特别注意用户信息标识是否加密，加密方法以及是否易破解；还有一种就是修改时回答问题，问题回答正确才能进行修改，大名鼎鼎的QQ就是这么做的。据传，原来支付宝有个很严重的安全问题，就是完全可以通过
手机号码找回登录密码和支付密码，会发送验证码到手机然后登录网页修改密码，有用户手机号码停机后，别人买了这个号然后登录了支付宝把钱转走了，现在支付宝找回登录密码时仍然可以通过手机号码找回，但是支付密码修改就需要手机短信和身份证件一起验证。不过我们很多人难免会在网络上留下手机号码的痕迹，聪明的善于挖掘汇总信息的人一定可以找到你的身份证号码，所以友情提示下：更换号码时一定要及时修改帐号关联的手机号码。
4. 注册攻击
常见的是恶意注册，以避免注册后恶意搜索引擎爬取，在线机器人投票，注册垃圾邮箱等。
缓解注册攻击的方法：使用RSA/验证码
5. Cookie安全
Cookie中记录着用户的个人信息，登录状态等。使用Cookie欺骗可以伪装成其他用户来获取隐私信息等。
常见的Cookie欺骗有几下几种方法：
1）设置cookie的有效期，通过cookie manager等chrome的插件即可完成；
2）通过分析多帐户的cookie值的编码规律，使用破解编码技术来任意修改cookie的值达到欺骗目的，这种方法较难实施；
3）结合XSS攻击上传代码获取访问页面用户 cookie的代码，获得其他用户的cookie
4）通过浏览器漏洞获取用户的cookie，这种方法就需要非常熟悉浏览器。
如何防范？
1）不要在Cookie中保存敏感信息；
2）不要在Cookie中保存没有经过加密的或者容易被解密的敏感信息；
3）对从客户端取得的Cookie信息进行严格校验，如登录时提交的用户名密码正确性；
4）记录非法的Cookie信息进行分析，并根据这些信息对系统进行改进；
5）使用SSL来传递Cookie信息；
6）结合session验证对用户访问授权；
7）及时更新浏览器漏洞；
8）设置httponly增强安全性；
9）实施系统安全性解决方案，避免XSS攻击
6. Session安全
服务端和客户端之间是通过session(会话)来连接沟通。当客户端的浏览器连接到服务器后，服务器就会建立一个该用户的session。每个用户的session都是独立的，并且由服务器来维护。每个用户的session是由一个独特的字符串来识别，成为session id。用户发出请求时，所发送的http表头内包含session id 的值。服务器使用http表头内的session id来识别是哪个用户提交的请求。一般Session ID传递方式：URL中指定session或存储在cookie中，后者广泛使用。
会话劫持
会话劫持是指攻击者利用各种手段来获取目标用户的session id。一旦获取到session id，那么攻击者可以利用目标用户的身份来登录网站，获取目标用户的操作权限。
攻击者获取目标用户session id的方法:
1）暴力破解:尝试各种session id，直到破解为止
2）计算:如果session id使用非随机的方式产生，那么就有可能计算出来
3）窃取:使用网络截获，XSS，CSRF攻击等方法获得
如何防范？
1）定期更改Session ID ，这样每次重新加载都会产生一个新的Session ID
2）只从cookie中传送Session ID，结合cookie验证
3）只接受server产生的Session ID
4）只在用户登录授权后生成Session或登录授权后变更Session
5）为Session ID设置Time-Out时间
6）验证来源，如果Refer的來源是可疑的，就刪除Session ID
7）如果用戶代理user-agent变更时，重新生成session ID
8）使用SSL连接
9）防止XSS，CSRF漏洞
以上内容已经提出了很多次关于XSS和CSRF，他们真的是罪魁祸首啊，因为有了这些漏洞，会导致很多的恶意攻击，好吧，以后会慢慢道来，揭开他们神秘面纱。
版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。