有一点我们必须承认，大多数web应用程序都离不开session的使用。这篇文章将会结合php以及http协议来分析如何建立一个安全的会话管理机制。

我们先简单的了解一些http的知识，从而理解该协议的无状态特性。然后，学习一些关于cookie的基本操作。最后，我会一步步阐述如何使用一些简单，高效的方法来提高你的php应用程序的安全性以及稳定行。

我想大多数的php初级程序员一定会认为php默认的session机制的安全性似乎是有一定保障的，事实恰好相反 – php团队只是提供了一套便捷的session的解决方案提供给程序员使用，至于安全性的话，应该由程序员来加强，这是应用程序开发团队的责任。因为，这里面的方法很多，可以这么说吧，没有最好，只有更好。攻击的方式在不断变化，防守方也需要不断变招，所以，我个人认为php团队的做法还是比较明智的。

无状态性

Http是一种无状态性的协议。这是因为此种协议不要求浏览器在每次请求中标明它自己的身份，并且浏览器以及服务器之间并没有保持一个持久性的连接用于多个页面之间的访问。当一个用户访问一个站点的时候，用户的浏览器发送一个http请求到服务器，服务器返回给浏览器一个http响应。其实很简单的一个概念，客户端一个请求，服务器端一个回复，这就是整个基于http协议的通讯过程。

因为web应用程序是基于http协议进行通讯的，而我们已经讲过了http是无状态的，这就增加了维护web应用程序状态的难度, 对于开发者来说，是一个不小的挑战。Cookies是作为http的一个扩展诞生的，其主要用途是弥补http的无状态特性，提供了一种保持客户端与服务器端之间状态的途径，但是由于出于安全性的考虑，有的用户在浏览器中是禁止掉cookie的。这种情况下，状态信息只能通过url中的参数来传递到服务器端，不过这种方式的安全性很差。事实上，按照通常的想法，应该有客户端来表明自己的身份，从而和服务器之间维持一种状态，但是出于安全性方面的考虑，我们都应该明白一点 – 来自客户端的信息都是不能完全信任的。

尽管这样，针对维持web应用程序状态的问题，相对来说，还是有比较优雅的解决方案的。不过，应该说是没有完美的解决方案的，再好的解决方案也不可能适用所有的情况。这篇文章将介绍一些技术。这些技术可以用来比较稳定地维持应用程序的状态以及抵御一些针对session的攻击，比如会话劫持。并且你可以学习到cookie是怎样工作的，php 的session做了那些事情，以及怎样才能劫持session。

http 概览

如何才能保持web应用程序的状态以及选择最合适的解决方案呢？在回答这个问题之前，必须得先了解web的底层协议 – Hypertext Transfer Protocol (HTTP)。

当用户访问http://example.com这个域名的时候，浏览器就会自动和服务器建立tcp/ip连接，然后发送http请求到example.com的服务器的80端口。该个请求的语法如下所示：

GET / HTTP/1.1
Host: example.org

以上第一行叫做请求行，第二个参数（一个反斜线在这个例子中）表示所请求资源的路径。反斜线代表了根目录；服务器会转换这个根目录为服务器文件系统中的一个具体目录。

Apache的用户常用DocumentRoot这个命令来设置这个文档根路径。如果请求的url是http://example.org/path/to/script.php,那么请求的路径就是/path/to/script.php。假如document root 被定义为usr/lcoal/apache/htdocs的话,整个请求的资源路径就是/usr/local/apache/htdocs/path/to/script.php。

第二行描述的是http头部的语法。在这个例子中的头部是Host, 它标识了浏览器希望获取资源的域名主机。还有很多其它的请求头部可以包含在http请求中，比如user-Agent头部，在php可以通过$_SERVER['HTTP_USER_AGENT']获取请求中所携带的这个头部信息。

但是遗憾的是，在这个请求例子中，没有任何信息可以唯一标识当前这个发出请求的客户端。有些开发者借助请求中的ip头部来唯一标识发出此次请求的客户端，但是这种方式存在很多问题。因为，有些用户是通过代理来访问的，比如用户A通过代理B连接网站www.example.com, 服务器端获取的ip信息是代理B分配给A的ip地址，如果用户这时断开代理，然后再次连接代理的话，它的代理ip地址又再次改变，也就说一个用户对应了多个ip地址，这种情况下，服务器端根据ip地址来标识用户的话，会认为请求是来自不同的用户，事实上是同一个用户。 还用另外一种情况就是，比如很多用户是在同一个局域网里通过路由连接互联网，然后都访问www.example.com的话，由于这些用户共享同一个外网ip地址，这会导致服务器认为这些用户是同一个用户发出的请求，因为他们是来自同一个ip地址的访问。

保持应用程序状态的第一步就是要知道如何来唯一地标识每个客户端。因为只有在http中请求中携带的信息才能用来标识客户端，所以在请求中必须包含某种可以用来标识客户端唯一身份的信息。Cookie设计出来就是用来解决这一问题的。

cookies

如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。一个cookie的设置以及发送过程分为以下四步：

1.客户端发送一个http请求到服务器端
2.服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
3.客户端发送一个http请求到服务器端，其中包含Cookie头部
4.服务器端发送一个http响应到客户端

这个通讯过程也可以用以下下示意图来描述：

客户端的第二次请求中包含的Cookie头部中，提供给了服务器端可以用来唯一标识客户端身份的信息。这时，服务器端也就可以判断客户端是否启用了cookies。尽管，用户可能在和应用程序交互的过程中突然禁用cookies的使用，但是，这个情况基本是不太可能发生的，所以可以不加以考虑，这在实践中也被证明是对的。

session的管理

直到现在，我只讨论了如何维护应用程序的状态，只是简单地涉及到了如果保持请求之间的关系。接下来，我阐述下在实际中用到比较多的技术 – Session的管理。涉及到session的管理，就不是单单地维持各个请求之间的状态，还需要维持会话期间针对每个特定用户使用到的数据。我们常常把这种数据叫做session数据，因为这些数据是跟某个特定用户与服务器之间的会话相关联的。如果你使用php内置的session的管理机制，那么session数据一般是保存在/tmp这个服务器端的文件夹中，并且其中的session数据会被自动地保存到超级数组$_SESSION中。一个最简单的使用session的例子，就是将相关的session数据从一个页面传递(注意：实际传递的是session id)到另一个页面。下面用示例代码1, start.php, 对这个例子加以演示：

示例代码1 – start.php

<?php
session_start();
$_SESSION[&#039;foo&#039;] = &#039;bar&#039;;
?>

<a href="continue.php">continue.php</a>

假如用户点击start.php中的链接访问continue.php,那么在continue.php中就可以通过$_SESSION['foo']获取在start.php中的定义的值’bar’。看下面的示例代码2:

示例代码2 – continue.php

<?php
session_start();
echo $_SESSION[&#039;foo&#039;]; /* bar */ 
?>

是不是非常简单，但是我要指出的话，如果你真的这样来写代码的话，说明你对php底层的对于session的实现机制还不是非常了解透彻。在不了解php内部给你自动做了多少事情的情况下，你会发现如果程序出错的话，这样的代码将变的很难调试，事实上，这样的代码也完全没有安全性可言。

session的安全性问题

一直以来很多开发者都认为php内置的session管理机制是具有一定的安全性，可以对一般的session攻击起到防御。事实上，这是一种误解，php团队只实现了一种方便有效的机制。具体的安全措施，应该有应用程序的开发团队来实施。 就像开篇谈到的，没有最好的解决方案，只有最合适你的方案。

现在，我们来看下一个比较常规的针对session的攻击：

1.用户访问http://www.example.org，并且登录。
2.example.org的服务器设置指示客户端设置相关cookie – PHPSESSID=12345
3.攻击者这时访问http://www.example.org/,并且在请求中携带了对应的cookie – PHPSESSID=12345
4.这样情况下，因为example.orge的服务器通过PHPSESSID来辨认对应的用户的，所以服务器错把攻击者当成了合法的用户。