Regarding sessions, the main issue to be concerned about is the confidentiality of session identifiers. If it's confidential, there's no risk of session hijacking. With a legitimate session ID, an attacker can very successfully impersonate one of your users.
An attacker can obtain a legitimate session ID in three ways:
##l Guess
##l Capture##l Fixed
PHP generates a highly random session ID, so the risk of being guessed does not exist. It is common to capture network communication data to obtain session identification. In order to avoid the risk of session identification being captured, SSL can be used, and browser vulnerabilities must be patched in a timely manner.
hint
Remember that the browser will include a corresponding Cookie header in all subsequent requests based on the requirements in the Set-Cookie header in the request. Most commonly, session identifiers are unnecessarily exposed in requests for embedded resources such as images. For example, when requesting a web page containing 10 images, the browser will issue 11 requests with session identifiers, but only one is necessary with the identifier. To prevent this unnecessary exposure, you may consider placing all embedded resources on a server with another domain name.
Session fixation is an attack technique that tricks a victim into using an attacker-specified session ID. This is the easiest way for an attacker to obtain a legitimate session ID.
In this simplest example, a link is used for a session fixation attack:
<a href="http://example.org/index.php?PHPSESSID=1234">Click Here</a>
Another method is to use a protocol-level redirection statement:
<?php header('Location: http://www.php.cn/'); ?>
This can also be done via the Refresh header, which is generated by specifying either a real HTTP header or the http-equiv attribute of the meta tag. The attacker's goal is to have users access a URL containing an attacker-specified session ID. This is the first step of a basic attack. The complete attack process is shown in Figure 4-3.
Figure 4-3. Session fixation attack using attacker-specified session ID
If successful, the attacker would be able to bypass the need to capture or guess a legitimate session ID, which would allow more and more dangerous attacks are possible.
To better understand this step, the best thing to do is to try it yourself. First create a script named fixation.php:
<?php session_start(); $_SESSION['username'] = 'chris'; ?>
Make sure you do not have any cookies saved on the current server, or ensure this by clearing all cookies. Access fixation.php via the URL containing PHPSESSID:
http://www.php.cn/
It creates a session variable username with a value of chris. After checking the session storage area, it was found that 1234 became the session ID of the data:
$ cat /tmp/sess_1234 username|s:5:"chris";
Create the second script test.php, which is in $_SESSION['username'] If it exists, enter the value:
<?php session_start(); if (isset($_SESSION['username'])) { echo $_SESSION['username']; } ?>
##
在另外一台计算机上或者在另一个浏览器中访问下面的URL,同时该URL指定了相同的会话标识:
http://www.php.cn/
这使你可以在另一台计算机上或浏览器中(模仿攻击者所在位置)恢复前面在fixation.php中建立的会话。这样,你就作为一个攻击者成功地劫持了一个会话。
很明显,我们不希望这种情况发生。因为通过上面的方法,攻击者会提供一个到你的应用的链接,只要通过这个链接对你的网站进行访问的用户都会使用攻击者所指定的会话标识。
产生这个问题的一个原因是会话是由URL中的会话标识所建立的。当没有指定会话标识时,PHP就会自动产生一个。这就为攻击者大开了方便之门。幸运的是,我们以可以使用session_regenerate_id( )函数来防止这种情况的发生。
<?php session_start(); if (!isset($_SESSION['initiated'])) { session_regenerate_id(); $_SESSION['initiated'] = TRUE; } ?>
这就保证了在会话初始化时能有一个全新的会话标识。可是,这并不是防止会话固定攻击的有效解决方案。攻击者能简单地通过访问你的网站,确定PHP给出的会话标识,并且在会话固定攻击中使用该会话标识。
这确实使攻击者没有机会去指定一个简单的会话标识,如1234,但攻击者依然可以通过检查cookie或URL(依赖于标识的传递方式)得到PHP指定的会话标识。该流程如图4-4所示。
该图说明了会话的这个弱点,同时它可以帮助你理解该问题涉及的范围。会话固定只是一个基础,攻击的目的是要取得一个能用来劫持会话的标识。这通常用于这样的一个系统,在这个系统中,攻击者能合法取得较低的权限(该权限级别只要能登录即可),这样劫持一个具有较高权限的会话是非常有用的。
如果会话标识在权限等级有改变时重新生成,就可以在事实上避开会话固定的风险:
<?php $_SESSION['logged_in'] = FALSE; if (check_login()) { session_regenerate_id(); $_SESSION['logged_in'] = TRUE; } ?>
Figure 4-4. 通过首先初始化会话进行会话固定攻击
小提示
我不推荐在每一页上重新生成会话标识。虽然这看起来确实是一个安全的方法。但与在权限等级变化时重新生成会话标识相比,并没有提供更多的保护手段。更重要的是,相反地它还会对你的合法用户产生影响,特别是会话标识通过URL传递时尤甚。用户可能会使用浏览器的访问历史机制去访问以前访问的页面,这样该页上的链接就会指向一个不再存在的会话标识。
如果你只在权限等级变化时重新生成会话标识,同样的情况也有可以发生,但是用户在访问权限变更前的页面时,不会因为会话丢失而奇怪,同时,这种情况也不常见。
以上就是PHP安全-会话固定的内容,更多相关内容请关注PHP中文网(www.php.cn)!