研究了几天session安全,得出几个观点,请指正:
- 可以xss通过获得cookie信息,包含sessionid
- 可以通过截取http,获得header信息,包含sessionid
- 以上两种法都有一定条件和难度
- 如果服务端单靠sessionid识别会话信息,那么通过xss获取了sessionid后,会泄露用户信息,如果再通过ip,useragent信息加以校验,可以减少风险
- 如果截取了http,换用https方式可以减少风险
- 即便是使用https,ssl证书也是可以伪造
结论:
- xss漏洞更低级一些,但是造成的风险很大。
- http截取,截取范围很小,风险小。当然,截取到admin的信息,那就不一样了。
- http截取/ssl证书伪造的技术要求、环境要求较高,防治的成本也大。
好吧,从来就没有绝对安全的事儿.
可以xss通过获得cookie信息,包含sessionid key:cookie有自己的httpOnly.(之前apache也曝过一个漏洞:发送的cookie过长会把cookie给返回,即使httpOnly,现在已经修复)退一步讲,你应该首先避免xss漏洞.
可以通过截取http,获得header信息,包含sessionid key:改用https,防止中间人(这个也没有绝对的安全,SSL证书也曾被黑客伪造,不过一般人可干不了这个事儿)
如果服务端单靠sessionid识别会话信息,那么通过xss获取了sessionid后,会泄露用户信息,如果再通过ip,useragent信息加以校验,可以减少风险
key:可以避免他拿到了session后在自己的ip上实现.不过,既然他都拿到xss了,对于跨站师来说,拿用户信息几乎不费吹灰之力,关键是如何避免XSS,大门都给小偷打开了,你还想着要给保险箱上一把锁,现在的小偷可是拿的是大铁锺!
如果截取了http,换用https方式可以减少风险
嗯,我同意
综上,session的本身的安全在于外围的安全性.其本身是安全的.安全的会话机制最关键的还是要避免一些常见的漏洞:XSS,CSRF(这只是我经常遇到的,无论大站还是小站,这方面问题最多)
另外,sessionid的随机性不够被猜到也是session的潜在安全问题之一。