php 安全基础 第四章 会话与 Cookies
正如大家知道的，HTTP是一种无状态的协议。这说明了两个HTTP请求之间缺乏联系。由于协议中未提供任何让客户端标识自己的方法，因此服务器也就无法区分客户端。
虽然HTTP无状态的特性还是有一些好处，毕竟维护状态是比较麻烦的，但是它向需要开发有状态的Web应用的开发人员提出了前所未有的挑战。由于无法标识客户端，就不可能确认用户是否已登录，在购物车中加入商品，或者是需要注册。
一个最初由网景公司构思的超强解决方案诞生了，它就是被命名为cookies的一种状态管理机制。Cookies是对HTTP协议的扩充。更确切地说，它们由两个HTTP头部组成：Set-Cookie响应头部和Cookie请求头部。
当客户端发出对一个特定URL的请求时，服务器会在响应时选择包含一个Set-Cookie头部。它要求客户端在下面的请求中包含一个相就的Cookie头部。图4-1说明了这个基本的交互过程。
图4-1. 两个HTTP事务间Cookie的完整交互过程
如果你根据这个基本概念在每一个请求中包含同一个唯一标识码（在cookie头部中），你就能唯一标识客户端从而把它发出的所有请求联系起来。这就是状态所要求的，同时也是这一机制的主要应用。
小提示
迄今为止，最好的cookies使用指南依然是网景公司提供的规范，网址是：http://wp.netscape.com/newsref/std/cookie_spec.html 。它是最类似和接近于全行业支持的标准。
基于会话管理的概念，可以通过管理每一个客户端的各自数据来管理状态。数据被存储在会话存储区中，通过每一次请求进行更新。由于会话记录在存储时有唯一的标识，因此它通常被称为会话标识。
如果你使用PHP内建的会话机制，所有的这些复杂过程都会由PHP为你处理。当 你调用函数session_start()时，PHP首先要确认在本次请求中是否包含会话标识。如果有的话，PHP就会读取该会话数据并通过$_SESSION超级公用数组提供给你。如果不存在，PHP会生成一个会话标识并在会话存储区建立一个新记录。PHP还会处理会话标识的传递并在每一个请求时更新会话存储区。图4-2演示了这个过程。
虽然这很简便有效，但最重要的还是要意识到这并不是一个完整的解决方案，因为在PHP的会话机制中没有内建的安全处理。除此之外，由于会话标识是完全随机产生的，因此是不可预测的。你必须自行建立安全机制以防止所有其它的会话攻击手段。在本章中，我会提出一些问题，并提供相应的解决方案。
4.1. Cookie 盗窃
因使用Cookie而产生的一个风险是用户的cookie会被攻击者所盗窃。如果会话标识保存在cookie中，cookie的暴露就是一个严重的风险，因为它能导致会话劫持。
图4-2. PHP为你处理相关会话管理的复杂过程
最常见的cookie暴露原因是浏览器漏洞和跨站脚本攻击（见第2章）。虽然现在并没有已知的该类浏览器漏洞，但是以往出现过几例，其中最有名的一例同时发生在IE浏览器的4.0，5.0，5.5及6.0版本（这些漏洞都有相应补丁提供）。
虽然浏览器漏洞的确不是web开发人员的错，但是你可以采取步骤以减轻它对用户的威胁。在某些情况下，你可能通过使用一些安全措施有效地消除风险。至少你可以告诉和指导用户打上修正漏洞的安全补丁。
基于以上原因，知道新的安全漏洞是很有必要的。你可以跟踪下面提供的几个网站和邮件列表，同时有很多服务提供了RSS推送，因此只要订阅RSS即可以得到新安全漏洞的警告。SecurityFocus网站维护着一系列软件漏洞的列表（http://online.securityfocus.com/vulnerabilities），你可以通过开发商、主题和版本进行检索。PHP安全协会也维护着SecurityFocus的所有最新通知。（http://phpsec.org/projects/vulnerabilities/securityfocus.html）
跨站脚本攻击是攻击者盗窃cookie的更为常见的手段。其中之一已有第二章中描述。由于客户端脚本能访问cookies，攻击者所要的送是写一段传送数据的脚本即可。唯一能限制这种情况发生的因素只有攻击者的创造力了。
防止cookie盗窃的手段是通过防止跨站脚本漏洞和检测导致cookie暴露的浏览器漏洞相结合。由于后者非常少见（此类漏洞将来也会比较罕见），所以它并不是需要关心的首要问题，但还是最好要紧记。
4.2. 会话数据暴露
会话数据常会包含一些个人信息和其它敏感数据。基于这个原因，会话数据的暴露是被普遍关心的问题。一般来说，暴露的范围不会很大，因为会话数据是保存在服务器环境中的，而不是在数据库或文件系统中。因此，会话数据自然不会公开暴露。
使用SSL是一种特别有效的手段，它可以使数据在服务器和客户端之间传送时暴露的可能性降到最低。这对于传送敏感数据的应用来说非常重要。SSL在HTTP之上提供了一个保护层，以使所有在HTTP请求和应答中的数据都得到了保护。
如果你关心的是会话数据保存区本身的安全，你可以对会话数据进行加密，这样没有正确的密钥就无法读取它的内容。这在PHP中非常容易做到，你只要使用session_set_save_handler( )并写上你自己的session加密存储和解密读取的处理函数即可。
4.3. 会话固定
关于会话，需要关注的主要问题是会话标识的保密性问题。如果它是保密的，就不会存在会话劫持的风险了。通过一个合法的会话标识，一个攻击者可以非常成功地冒充成为你的某一个用户。
一个攻击者可以通过三种方法来取得合法的会话标识：
l 猜测
l 捕获
l 固定
PHP生成的是随机性很强的会话标识，所以被猜测的风险是不存在的。常见的是通过捕获网络通信数据以得到会话标识。为了避免会话标识被捕获的风险，可以使用SSL，同时还要对浏览器漏洞及时修补。
小提示
要记住浏览器会根据请求中的Set-cookie头部中的要求对之后所有的请求中都包含一个相应的Cookie头部。最常见的是，会话标识会无谓的在对一些嵌入资源如图片的请求中被暴露。例如，请求一个包含10个图片的网页时，浏览器会发出11个带有会话标识的请求，但只有一个是有必要带有标识的。为了防止这种无谓的暴露，你可以考虑把所有的嵌入资源放在有另外一个域名的服务器上。
会话固定是一种诱骗受害者使用攻击者指定的会话标识的攻击手段。这是攻击者获取合法会话标识的最简单的方法。
在这个最简单的例子中，使用了一个链接进行会话固定攻击：
<a href="http://example.org/index.php?PHPSESSID=1234">Click Here</a>
另外一个方法是使用一个协议级别的转向语句：
<?php
header('Location: http://example.org/index.php?PHPSESSID=1234');
?>
这也可以通过Refresh头部来进行，产生该头部的方法是通过真正的HTTP头部或meta标签的http-equiv属性指定。攻击者的目标是让用户访问包含有攻击者指定的会话标识的URL。这是一个基本的攻击的第一步，完整的攻击过程见图4-3所示。
Figure 4-3. 使用攻击者指定的会话标识进行的会话固定攻击
如果成功了，攻击者就能绕过抓取或猜测合法会话标识的需要，这就使发起更多和更危险的攻击成为可能。
为了更好地使你理解这一步骤，最好的办法是你自己尝试一下。首先建立一个名为fixation.php的脚本：
<?php
session_start();
$_SESSION['username'] = 'chris';
?>
确认你没有保存着任何当前服务器的cookies，或通过清除所有的cookies以确保这一点。通过包含PHPSESSID的URL访问fixation.php：
http://example.org/fixation.php?PHPSESSID=1234
它建立了一个值为chris的会话变量username。在检查会话存储区后发现1234成为了该数据的会话标识：
$ cat /tmp/sess_1234
username|s:5:"chris";
建立第二段脚本test.php，它在$_SESSION[‘username’] 存在的情况下即输入出该值：
<?php
session_start();
if (isset($_SESSION['username']))
{
echo $_SESSION['username'];
}
?>
在另外一台计算机上或者在另一个浏览器中访问下面的URL，同时该URL指定了相同的会话标识：
http://example.org/test.php?PHPSESSID=1234
这使你可以在另一台计算机上或浏览器中（模仿攻击者所在位置）恢复前面在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传递时尤甚。用户可能会使用浏览器的访问历史机制去访问以前访问的页面，这样该页上的链接就会指向一个不再存在的会话标识。
如果你只在权限等级变化时重新生成会话标识，同样的情况也有可以发生，但是用户在访问权限变更前的页面时，不会因为会话丢失而奇怪，同时，这种情况也不常见。
4.4. 会话劫持
最常见的针对会话的攻击手段是会话劫持。它是所有攻击者可以用来访问其它人的会话的手段的总称。所有这些手段的第一步都是取得一个合法的会话标识来伪装成合法用户，因此保证会话标识不被泄露非常重要。前面几节中关于会话暴露和固定的知识能帮助你保证会话标识只有服务器及合法用户才能知道。
深度防范原则（见第一章）可以用在会话上，当会话标识不幸被攻击者知道的情况下，一些不起眼的安全措施也会提供一些保护。作为一个关心安全的开发者，你的目标应该是使前述的伪装过程变得更复杂。记住无论多小的障碍，都会以你的应用提供保护。
把伪装过程变得更复杂的关键是加强验证。会话标识是验证的首要方法，同时你可以用其它数据来补充它。你可以用的所有数据只是在每个HTTP请求中的数据：
GET / HTTP/1.1
Host: example.org
User-Agent: Firefox/1.0
Accept: text/html, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
你应该意识到请求的一致性，并把不一致的行为认为是可疑行为。例如，虽然User-Agent(发出本请求的浏览器类型)头部是可选的，但是只要是发出该头部的浏览器通常都不会变化它的值。如果你一个拥有1234的会话标识的用户在登录后一直用Mozilla Firfox浏览器，突然转换成了IE，这就比较可疑了。例如，此时你可以用要求输入密码方式来减轻风险，同时在误报时，这也对合法用户产生的冲击也比较小。你可以用下面的代码来检测User-Agent的一致性：
<?php
session_start();
if (isset($_SESSION['HTTP_USER_AGENT']))
{
if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT']))
{
/* Prompt for password */
exit;
}
}
else
{
$_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
}
?>
我观察过，在某些版本的IE浏览器中，用户正常访问一个网页和刷新一个网页时发出的Accept头部信息不同，因此Accept头部不能用来判断一致性。
确保User-Agent头部信息一致的确是有效的，但如果会话标识通过cookie传递（推荐方式），有道理认为，如果攻击者能取得会话标识，他同时也能取得其它HTTP头部。由于cookie暴露与浏览器漏洞或跨站脚本漏洞相关，受害者需要访问攻击者的网站并暴露所有头部信息。所有攻击者要做的只是重建头部以防止任何对头部信息一致性的检查。
比较好的方法是产生在URL中传递一个标记，可以认为这是第二种验证的形式（虽然更弱）。使用这个方法需要进行一些编程工作，PHP中没有相应的功能。例如，假设标记保存在$token中，你需要把它包含在所有你的应用的内部链接中：
<?php
$url = array();
$html = array();
$url['token'] = rawurlencode($token);
$html['token'] = htmlentities($url['token'], ENT_QUOTES, 'UTF-8');
?>
<a href="index.php?token=<?php echo $html['token']; ?>">Click Here</a>
为了更方便地管理这个传递过程，你可能会把整个请求串放在一个变量中。你可以把这个变量附加到所有链接后面，这样即便你一开始没有使用该技巧，今后还是可以很方便地对你的代码作出变化。
该标记需要包含不可预测的内容，即便是在攻击者知道了受害者浏览器发出的HTTP头部的全部信息也不行。一种方法是生成一个随机串作为标记：
<?php
$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';
$token = md5($string);
$_SESSION['token'] = $token;
?>
当你使用随机串时（如SHIFLETT），对它进行预测是不现实的。此时，捕获标记将比预测标记更为方便，通过在URL中传递标记和在cookie中传递会话标识，攻击时需要同时抓取它们二者。这样除非攻击者能够察看受害者发往你的应用所有的HTTP请求原始信息才可以，因为在这种情况下所有内容都暴露了。这种攻击方式实现起来非常困难（所以很罕见），要防止它需要使用SSL。
有专家警告不要依赖于检查User-Agent的一致性。这是因为服务器群集中的HTTP代理服务器会对User-Agent进行编辑，而本群集中的多个代理服务器在编辑该值时可能会不一致。
如果你不希望依赖于检查User-Agent的一致性。你可以生成一个随机的标记：
<?php
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>
这一方法的安全性虽然是弱一些，但它更可靠。上面的两个方法都对防止会话劫持提供了强有力的手段。你需要做的是在安全性和可靠性之间作出平衡。
