一、Who am I?
认证=Authentication 授权=Atuhorization
认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。
认证实际上就是一个验证凭证的过程。
如果只有一个凭证被用于认证，则称为"单因素认证";如果有多个凭证被用于认证，则称为"多因素认证"。
二、密码的那些事儿
密码是最常见的一种认证手段。
“密码强度”是设计密码认证方案时第一个需要考虑的问题。
密码的保存也要注意。一般来说，密码必须以不可逆的加密算法，或者是单向散列函数算法，加密后存储在数据库中。这样即使数据库被盗，也无法获取到密码的明文。
目前黑客们破解MD5后密码的方法一般是使用“彩虹表(Rainbow Table)"。就是收集尽可能多的密码明文和明文对应的MD5.一个好的彩虹表，可能会非常庞大，但这种方法确实有效。彩虹表的建立，还可以周期性地计算一些数据的MD5值，以扩充彩虹表的内容。
为了避免密码哈希值泄漏后，黑客能够直接通过彩虹表查询出密码明文，在计算密码明文的哈希值时，增加一个"Salt"。“Salt"是一个字符串，它的作用是为了增加明文的复杂度，并能使得彩虹表一类的攻击失效。
Salt的使用如下：
MD5(UserName+Password+Salt)
其中，Salt=abcddcba...(随机字符串)
Salt应该保存在服务器端的配置文件中，并妥善保管。
三、多因素认证
例如，手机动态口令、数字证书、宝令、支付盾、第三方证书等
四、Session与认证
登录成功后，不可能每个页面都进行一次认证，因此，认证成功后，就需要替换一个对用户透明的认证，就是SessionID。
最常见的做法就是把SessionID加密后保存在Cookie中，因为Cookie会随着HTTP请求头发送，且受到浏览器同源策略的保护。
SessionID一旦在生命周期内被窃取，就等同于账户失窃。同时由于SessionID是用户登录之后才持有的认证凭证，因此黑客不需要再攻击登录过程，在设计安全方案时需要意识到这一点。
Session劫持就是一种通过窃取用户SessionID后，使用该SessionID登录进目标账户的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。如果SessionID是保存在Cookie中的，则这种攻击可以称为Cookie劫持。
Cookie 泄漏的途径有很多，最常见的有XSS攻击、网络Sniff，以及本地木马窃取。对于通过XSS漏洞窃取Cookie的攻击，通过给Cookie标记 httponly，可以有效地缓解XSS窃取Cookie的问题。但是其他的泄漏途径，比如网络被嗅探，或者Cookie文件被窃取，则会涉及客户端的环 境安全，需要从客户端着手解决。
SessionID除了可以保存在Cookie中，还可以保存在URL中，作为请求的一个参数。但是这种方式的安全性难以经受考验。
在 手机操作系统中，由于很多手机浏览器暂不支持Cookie，所以只能将SessionID作为URL的一个参数用于认证。安全研究者kxlzx曾经在博客 上列出过一些无线WAP中因为sid泄漏所导致的安全漏洞。其中一个典型的场景就是通过Referer泄漏URL中的sid，QQ的WAO邮箱曾经出过此 漏洞，测试过程如下：
首先，发送到QQ邮箱的邮件中引用了一张外部网站的图片：
<img src="http://www.inbreak.net/logo.php">
然后，当手机用户用手机浏览器打开QQ邮箱时：
手机浏览器在解析图片时，实际上是发起了一次GET请求，这个请求会带上Referer。
Referer的值为:
http://w34.mail.qq.com/cgi-bing/readmail?sid=xxxxx4,wwwwww,&disptype=html&mailid=fdsaddsada&t=&conv=&p=&crr
可以看到sid就包含在Referer中，在www.inbreak.net的服务器日志中可以查看到此值，QQ邮箱的sid因此而泄漏了。
在sid的声明周期内，访问包含此sid的链接，就可以登录到该用户的邮箱中。
在生成SessionID时，需要保证足够的随机性，比如采用足够强的伪随机数生成算法。
五、Session Fixation攻击
什么是Session Fixation呢？举一个形象的例子，假设A有一辆汽车，A把汽车卖给了B，但是A并没有把所有的钥匙都给B，自己还藏了一把。这时候，如果B没有给车换锁的话，A仍然是可以用藏下的钥匙使用汽车的。
这个没有换”锁“而导致的安全问题，就是Session Fixation问题。
在用户登录网站的过程中，如果登录前后用户的SessionID没有发生变化，则会存在Session Fixation问题。
具 体攻击的过程是，用户X(攻击者)先获取到一个未经认证的SessionID，然后将这个SessionID交给用户Y去认证，Y完成认证后，服务器并未 更新此SessionID的值（注意是未改变SessionID，而不是未改变Session），所以X可以直接凭借此SessionID登录进Y的账 户。
X如何才能让Y使用这个SessionID呢？如果SessionID保存在Cookie中，比较难做到这一点。但若是SessionID保存在URL中，则X只需要诱使Y打开这个URL即可。
解决Session Fixation的正确做法是：在登录完成后，重写SessionID。
如果使用sid则需要重置sid的值；如果使用Cookie，则需要增加或改变用于认证的Cookie值。
六、Session保持攻击
如果攻击者能一直持有一个有效的Sesion(比如间隔性地刷新页面，以告诉服务器这个用户仍然在活动)，而服务器对于活动的Session也一直不销毁的话，攻击者就能通过此有效Session一直使用用户的账户，成为一个永久的”后门"。
但是Cookie有失效时间，Session也可能会过期，攻击者能永久地持有这个Session吗？
一 般的应用都会给Session设置一个失效时间，当到达失效时间后，Session将被销毁。但有一些系统，出于用户体验的考虑，只要这个用户还”活着 “，就不会让这个用户的Session失效。从而攻击者可以通过不停地发起访问请求，让Sessiion一直”活“下去。
安全研究者kxlzx曾经分享过这样一个案例，使用以下代码保持Session:
<script>
window.setInterval("keepsid()",60000);
function keepsid(){
document.getElementById("iframe1").src=url...;
}
</script>
而Cookie是可以完全由客户端控制的，通过发送带有自定义Cookie头的包，也能实现同样的效果。
想使得Cookie不失效，还有更简单的方法。
在 Web开发中，网站访问量如果比较大，维护session可能会给网站带来巨大的负担。因此，有一种做法，就是服务器端不维护Session，而把 Session放在Cookie中加密保存。当浏览器访问网站时，会自动带上Cookie，服务器端只需要解密Cookie即可得到当前用户的 Session了。这样的Session如何使其过期呢？很多应用都是利用Cookie的Expire标签来控制Session的失效时间，这就给了攻击 者可乘之机。
Cookie的Expire时间是完全可以由客户端控制的。纂改这个时间，并使之永远有效，就有可能获得一个永久有效的Session，而服务器端是完全无法察觉的。
攻击者甚至可以为Session Cookie增加一个Expire时间，使得原本浏览器关闭就会失效的Cookie持久化地保存在本地，变成一个第三方Cookie。
如何对抗这种Session保持攻击呢？
常见的做法是在一定时间后，强制销毁Session。比如3天后就强制Session过期。
还可以选择的方法是当用户客户端发生变化时，要求用户重新登录。比如用户的IP、UserAgent等信息发生了变化，这就可以强制销毁当前的Session，并要求用户重登陆。
最后，还需要考虑的是同一用户拥有几个有效的Session。若每个用户只允许拥有一个Session，则攻击者想要一直保持一个Session也是不太可能的。当用户再次登录时，攻击者所保持的Session将被“踢出“。
七、单点登录SSO
风险和便利共存。
目前胡两旺最为开放和流行的单点登录系统是OpenID。
认证=Authentication 授权=Atuhorization
认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。
认证实际上就是一个验证凭证的过程。
如果只有一个凭证被用于认证，则称为"单因素认证";如果有多个凭证被用于认证，则称为"多因素认证"。
二、密码的那些事儿
密码是最常见的一种认证手段。
“密码强度”是设计密码认证方案时第一个需要考虑的问题。
密码的保存也要注意。一般来说，密码必须以不可逆的加密算法，或者是单向散列函数算法，加密后存储在数据库中。这样即使数据库被盗，也无法获取到密码的明文。
目前黑客们破解MD5后密码的方法一般是使用“彩虹表(Rainbow Table)"。就是收集尽可能多的密码明文和明文对应的MD5.一个好的彩虹表，可能会非常庞大，但这种方法确实有效。彩虹表的建立，还可以周期性地计算一些数据的MD5值，以扩充彩虹表的内容。
为了避免密码哈希值泄漏后，黑客能够直接通过彩虹表查询出密码明文，在计算密码明文的哈希值时，增加一个"Salt"。“Salt"是一个字符串，它的作用是为了增加明文的复杂度，并能使得彩虹表一类的攻击失效。
Salt的使用如下：
MD5(UserName+Password+Salt)
其中，Salt=abcddcba...(随机字符串)
Salt应该保存在服务器端的配置文件中，并妥善保管。
三、多因素认证
例如，手机动态口令、数字证书、宝令、支付盾、第三方证书等
四、Session与认证
登录成功后，不可能每个页面都进行一次认证，因此，认证成功后，就需要替换一个对用户透明的认证，就是SessionID。
最常见的做法就是把SessionID加密后保存在Cookie中，因为Cookie会随着HTTP请求头发送，且受到浏览器同源策略的保护。
SessionID一旦在生命周期内被窃取，就等同于账户失窃。同时由于SessionID是用户登录之后才持有的认证凭证，因此黑客不需要再攻击登录过程，在设计安全方案时需要意识到这一点。
Session劫持就是一种通过窃取用户SessionID后，使用该SessionID登录进目标账户的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。如果SessionID是保存在Cookie中的，则这种攻击可以称为Cookie劫持。
Cookie 泄漏的途径有很多，最常见的有XSS攻击、网络Sniff，以及本地木马窃取。对于通过XSS漏洞窃取Cookie的攻击，通过给Cookie标记 httponly，可以有效地缓解XSS窃取Cookie的问题。但是其他的泄漏途径，比如网络被嗅探，或者Cookie文件被窃取，则会涉及客户端的环 境安全，需要从客户端着手解决。
SessionID除了可以保存在Cookie中，还可以保存在URL中，作为请求的一个参数。但是这种方式的安全性难以经受考验。
在 手机操作系统中，由于很多手机浏览器暂不支持Cookie，所以只能将SessionID作为URL的一个参数用于认证。安全研究者kxlzx曾经在博客 上列出过一些无线WAP中因为sid泄漏所导致的安全漏洞。其中一个典型的场景就是通过Referer泄漏URL中的sid，QQ的WAO邮箱曾经出过此 漏洞，测试过程如下：
首先，发送到QQ邮箱的邮件中引用了一张外部网站的图片：
<img src="http://www.inbreak.net/logo.php">
然后，当手机用户用手机浏览器打开QQ邮箱时：
手机浏览器在解析图片时，实际上是发起了一次GET请求，这个请求会带上Referer。
Referer的值为:
http://w34.mail.qq.com/cgi-bing/readmail?sid=xxxxx4,wwwwww,&disptype=html&mailid=fdsaddsada&t=&conv=&p=&crr
可以看到sid就包含在Referer中，在www.inbreak.net的服务器日志中可以查看到此值，QQ邮箱的sid因此而泄漏了。
在sid的声明周期内，访问包含此sid的链接，就可以登录到该用户的邮箱中。
在生成SessionID时，需要保证足够的随机性，比如采用足够强的伪随机数生成算法。
五、Session Fixation攻击
什么是Session Fixation呢？举一个形象的例子，假设A有一辆汽车，A把汽车卖给了B，但是A并没有把所有的钥匙都给B，自己还藏了一把。这时候，如果B没有给车换锁的话，A仍然是可以用藏下的钥匙使用汽车的。
这个没有换”锁“而导致的安全问题，就是Session Fixation问题。
在用户登录网站的过程中，如果登录前后用户的SessionID没有发生变化，则会存在Session Fixation问题。
具 体攻击的过程是，用户X(攻击者)先获取到一个未经认证的SessionID，然后将这个SessionID交给用户Y去认证，Y完成认证后，服务器并未 更新此SessionID的值（注意是未改变SessionID，而不是未改变Session），所以X可以直接凭借此SessionID登录进Y的账 户。
X如何才能让Y使用这个SessionID呢？如果SessionID保存在Cookie中，比较难做到这一点。但若是SessionID保存在URL中，则X只需要诱使Y打开这个URL即可。
解决Session Fixation的正确做法是：在登录完成后，重写SessionID。
如果使用sid则需要重置sid的值；如果使用Cookie，则需要增加或改变用于认证的Cookie值。
六、Session保持攻击
如果攻击者能一直持有一个有效的Sesion(比如间隔性地刷新页面，以告诉服务器这个用户仍然在活动)，而服务器对于活动的Session也一直不销毁的话，攻击者就能通过此有效Session一直使用用户的账户，成为一个永久的”后门"。
但是Cookie有失效时间，Session也可能会过期，攻击者能永久地持有这个Session吗？
一 般的应用都会给Session设置一个失效时间，当到达失效时间后，Session将被销毁。但有一些系统，出于用户体验的考虑，只要这个用户还”活着 “，就不会让这个用户的Session失效。从而攻击者可以通过不停地发起访问请求，让Sessiion一直”活“下去。
安全研究者kxlzx曾经分享过这样一个案例，使用以下代码保持Session:
<script>
window.setInterval("keepsid()",60000);
function keepsid(){
document.getElementById("iframe1").src=url...;
}
</script>
而Cookie是可以完全由客户端控制的，通过发送带有自定义Cookie头的包，也能实现同样的效果。
想使得Cookie不失效，还有更简单的方法。
在 Web开发中，网站访问量如果比较大，维护session可能会给网站带来巨大的负担。因此，有一种做法，就是服务器端不维护Session，而把 Session放在Cookie中加密保存。当浏览器访问网站时，会自动带上Cookie，服务器端只需要解密Cookie即可得到当前用户的 Session了。这样的Session如何使其过期呢？很多应用都是利用Cookie的Expire标签来控制Session的失效时间，这就给了攻击 者可乘之机。
Cookie的Expire时间是完全可以由客户端控制的。纂改这个时间，并使之永远有效，就有可能获得一个永久有效的Session，而服务器端是完全无法察觉的。
攻击者甚至可以为Session Cookie增加一个Expire时间，使得原本浏览器关闭就会失效的Cookie持久化地保存在本地，变成一个第三方Cookie。
如何对抗这种Session保持攻击呢？
常见的做法是在一定时间后，强制销毁Session。比如3天后就强制Session过期。
还可以选择的方法是当用户客户端发生变化时，要求用户重新登录。比如用户的IP、UserAgent等信息发生了变化，这就可以强制销毁当前的Session，并要求用户重登陆。
最后，还需要考虑的是同一用户拥有几个有效的Session。若每个用户只允许拥有一个Session，则攻击者想要一直保持一个Session也是不太可能的。当用户再次登录时，攻击者所保持的Session将被“踢出“。
七、单点登录SSO
风险和便利共存。
目前胡两旺最为开放和流行的单点登录系统是OpenID。
没有评论:
发表评论