作者:hsc686 | 来源:互联网 | 2018-05-25 03:29
研究了几天session安全,得出几个观点,请指正:可以xss通过获得cookie信息,包含sessionid可以通过截取http,获得header信息,包含sessionid以上两种法都有一定条件和难度如果服务端单靠sessionid识别会话信...
研究了几天session安全,得出几个观点,请指正:
- 可以xss通过获得COOKIE信息,包含sessionid
- 可以通过截取http,获得header信息,包含sessionid
- 以上两种法都有一定条件和难度
- 如果服务端单靠sessionid识别会话信息,那么通过xss获取了sessionid后,会泄露用户信息,如果再通过ip,useragent信息加以校验,可以减少风险
- 如果截取了http,换用https方式可以减少风险
- 即便是使用https,ssl证书也是可以伪造
结论:
- xss漏洞更低级一些,但是造成的风险很大。
- http截取,截取范围很小,风险小。当然,截取到admin的信息,那就不一样了。
- http截取/ssl证书伪造的技术要求、环境要求较高,防治的成本也大。
回复内容:
研究了几天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方式可以减少风险
嗯,我同意
- 即便是使用https,ssl证书也是可以伪造
Key: 成功伪造证书的人少之又少.SSL相对绝大部分应用来说,其安全性已经足够了.
综上,session的本身的安全在于外围的安全性.其本身是安全的.安全的会话机制最关键的还是要避免一些常见的漏洞:XSS,CSRF(这只是我经常遇到的,无论大站还是小站,这方面问题最多)
- XSS可以通过给sessionid COOKIE设置 httponly 来防止。
- 监听http包的,校验IP是一种还不错的办法。因为通常用session做登录都不会持续很长时间,IP通常不会发生变化。admin登录的话,最好不要与前台系统做在一起,独立域名、特殊端口、限制IP/VPN内网、手机短信随机验证码等等方法都可以增强安全性。
- https的伪造证书监听,这个貌似只能获取到被欺骗用户提交的数据,因为证书本身验证的是服务器端的可信度。当然如果已经把客户端与服务端网络完全切断,加入了中间代理并伪造了服务器证书,这个应该仍然可以通过认证IP、SSL客户端证书来解决……这个不是很明白,恳请大神讲解。
另外,sessionid的随机性不够被猜到也是session的潜在安全问题之一。