还剩1页未读,继续阅读
文本内容:
SESSION的安全性WEB安全电脑资料因为有相同的sessionid包含在请求的Cookie头部中,所以相同的phpsession将会被访问到,像这种情况下,发现浏览器的头部改变了,但是不能肯定这是否是一次攻击者的请求的话,比较好的措施就是弹出一个要求输入密码的输入框让用户输入,这样的话,对用户体验___不会很大,又能很有效地防止攻击当然,你可以在系统中加入核查User-Agent头部的代码,类似Listing3中的代码当然,你先必须在第一次请求时,初始化session的时候,用MD5算法加密useragent信息并且保存在session中,类似下面listing4中的代码虽然不一定需要用MD5来加密这个User-Agent信息,但使用这种方式以后就不需要再过滤这个$_SERVER[_USER_AGENT]数据了不然的话,在使用这个数据以前必须要进行数据过滤,因为任何客户端的数据都是不可信任的,必须要注意这一点在你检查这个User-Agent客户端头部信息以后,做为一个攻击者必须要完成两步才能劫持一个session:你可能会说,居然攻击者能获得有效的sessionid那么以他的水平,伪造一个相同的User-Agent不是件难事不错,但是我们可以说这至少给他添加了一些麻烦,在一定程度上也增加了session机制的安全性你应该也能想到了,既然我们可以检查User-Agent这个头部来加强安全性,那么不妨再利用其它的一些头部信息,把他们组合起来生成一个加密的token,并且让客户端在后续的请求中携带这个token!这样的话,攻击者基本上不可能猜测出这样一个token是怎么生成出来的,注意Aept这个头部不应该被用来生成token因为有些浏览器会自动改变这个头部,当用户刷新浏览器的时候在你的验证机制中加入了这个非常难于猜测出来的token以后,安全性会得到很大的提升假如这个token通过像sessionid一样的方式来进行传递,这种情况下,一个攻击者必须完成必要的3步来劫持用户的session:这里面有个问题如果sessionid以及token都是通过GET数据来传递的话,那么对于能获取sessionID的攻击者,同样就能够获取到这个token所以,比较安全靠谱的方式应该是利用两种不同的数据传递方式来...。