【PHP基础-8】Cookie机制详解及Cookie身份认证应用案例

1 Cookie 概述

1.1 Cookie 机制

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.2 什么是Cookie

Cookie 并不是它的原意“甜饼”的意思，而是一个保存在客户机中的简单的文本文件，这个文件与特定的 Web 文档关联在一起，保存了该客户机访问这个Web 文档时的信息，当客户机再次访问这个 Web 文档时这些信息可供该文档使用。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

作用：由于“Cookie”具有可以保存在客户机上的神奇特性, 因此它可以帮助我们实现记录用户个人信息的功能, 而这一切都不必使用复杂的CGI等程序 。

1.3 Cookie 认证机制

在 Web认证中 ,因为HTTP协议本身的局限，必须采用其他技术将相关认证标记以某种方式持续传送，以免客户从一个页面跳转至另一个页面时重新输入认证信息。基于Cookie的认证过程，主要由以下三个阶段组成：

（1）发布Cookie

当用户试图访问某Web站点中需要认证的资源时，Web服务器会检查用户是否提供了认证Cookie，如果没有，则将用户重定向到登录页面。在用户成功登录后，Web服务器会产生认证Cookie，并通过HTTP响应中的Set-Cookie头发送给客户端，用于对用户随后的请求进行检查和验证，接着将用户重定向到初始请求的资源。

（2）检索Cookie

在用户随后的访问请求中，客户端浏览器检索Path和Domain等属性与用户请求资源相匹配的Cookie，并将找到的Cookie通过HTTP请求中的Cookie头提交给Web服务器。

（3）验证Cookie

Web服务器提取客户端浏览器递交的Cookie，验证其中的访问令牌。若合法，则将访问请求的资源发送给客户端浏览器；反之则拒绝用户的访问请求。Cookie 认证技术简化了用户访问 Web 网站资源的过程，即用户只需在初次登录网站时输入身份信息进行认证，随后便可以访问被授权的所有站点资源，不再需要重复手工提交身份信息。

综上所述，客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

1.4 Cookie 属性

（1）Name/Value：设置Cookie的名称及相对应的值，对于认证Cookie，Value值包括Web服务器所提供的访问令牌。
（2）Expires属性：设置Cookie的生存期。有两种存储类型的Cookie：会话性与持久性。Expires属性缺省时，为会话性Cookie，仅保存在客户端内存中，并在用户关闭浏览器时失效；持久性Cookie会保存在用户的硬盘中，直至生存期到或用户直接在网页中单击“注销”等按钮结束会话时才会失效。
（3）Path属性：定义了Web站点上可以访问该Cookie的目录。
（4）Domain属性：指定了可以访问该 Cookie 的 Web 站点或域名。Cookie 机制并未遵循严格的同源策略，允许一个子域可以设置或获取其父域的 Cookie。当需要实现单点登录方案时，Cookie 的上述特性非常有用，然而也增加了 Cookie受攻击的危险，比如攻击者可以借此发动会话定置攻击。因此，浏览器禁止在 Domain 属性中设置.org、.com 等通用顶级域名、以及在国家及地区顶级域下注册的二级域名，以减小攻击发生的范围。
（5）Secure属性：指定是否使用HTTPS安全协议发送Cookie。
使用HTTPS安全协议，可以保护Cookie在浏览器和Web服务器间的传输过程中不被窃取和篡改。该方法也可用于Web站点的身份鉴别，即在HTTPS的连接建立阶段，浏览器会检查Web网站的SSL证书的有效性。但是基于兼容性的原因（比如有些网站使用自签署的证书）在检测到SSL证书无效时，浏览器并不会立即终止用户的连接请求，而是显示安全风险信息，用户仍可以选择继续访问该站点。由于许多用户缺乏安全意识，因而仍可能连接到Pharming攻击所伪造的网站。
（6）HTTPOnly 属性：用于防止客户端脚本通过document.cookie属性访问Cookie，有助于保护Cookie不被跨站脚本攻击窃取或篡改。但是，HTTPOnly的应用仍存在局限性，一些浏览器可以阻止客户端脚本对Cookie的读操作，但允许写操作；此外大多数浏览器仍允许通过XMLHTTP对象读取HTTP响应中的Set-Cookie头。

1.5 Cookie的安全性问题

通过Cookie在客户端与服务器端进行交互，最终实现对用户身份的认证，Cookie成了用户整个身份的代替，其安全性决定了整个系统的安全性，Cookie的安全性问题主要有以下几方面:

（1）Cookie被用户非法篡改，如篡改其中的expire项，可将Cookie的有效期延长；篡改path项可使用户能够访问服务器上不被授权的内容；或修改domain项，使用户能够访问不被授权的服务器从而获得合法用户的信息等;
（2）被非法用户非法截获，然后在有限期内重放，则非法用户将享有合法用户的合法权益，可能会损害网站方的利益;
（3）若Cookie被服务器加密，而非法用户通过强力攻击或其他手段获得了相应的加密密钥，则非法用户可以伪造任何合法Cookie，从而可以访问合法用户的所有个性化信息，甚至是账户信息等。

2 Cookie 应用

2.1 Cookie 相关操作命令

设置Cookie语句命令：setcookie()。setcookie()函数说明，该函数返回值为布尔类型，可以使用isset()函数判断是否成功设置Cookie。

setcookie(
    string $name,
    string $value = "",
    int $expires = 0,
    string $path = "",
    string $domain = "",
    bool $secure = false,
    bool $httponly = false
): bool
#注意，传参只能按顺序从前往后传
例子：
setcookie("name", "DuZZ", null,null,null,null,null);其中null指没有设置，即按照默认
setcookie("name", "DuZZ", null,null,null,null,true);其中null指没有设置，即按照默认

接受Cookie信息的数组：$_COOKIE，利用预定义全局变量获取。
注销命令：setcookie("name", $_COOKIE['name'], time()-3600)，使cookie信息过期，将有效期设置为当前时刻1h之前。

2.2 应用案例实验

2.2.1 实验要求

（1）编写网站首页。当客户访问首页时，验证请求是否含有Cookie，如果有则显示“详细信息”并显示注销按钮（跳转至注销页面），如果没有则要求登录并显示登录按钮（跳转至登录页面）。
（2）编写登录页面。假设已有注册用户DuZZ，密码为123456。登录页面利用HTML表单收集客户端输入信息，利用PHP语句判断账户密码是否正确，正确则设置Cookie并返回首页，错误则要求继续输入账号密码。
（3）编写注销页面。注销后返回首页。

2.2.2 实验环境

服务端：本实验基于虚拟机win2008系统的WAMP环境进行，该环境相关配置过程参考文章《【语言环境】WAMP环境部署及优化—以win2008R2SP1为操作系统》
客户端：浏览器通过IP地址访问所编写网页。
服务端与客户端处于同一个局域网下。

2.2.3 案例代码

（1）index.php 首页代码：

<meta charset="utf-8">
<h1>cookie应用案例</h1>
<?php
if(isset($_COOKIE['name'])){
    echo "欢迎您，{$_COOKIE['name']} ，请开始测试";
    echo "
";
    echo "请注销";
}
else{
     echo " 请登录";
}
?>

（2）login.php 登录页面代码：

<meta charset="utf-8">
 <?php
if(isset($_POST['userSubmit'])){
    if(isset($_POST['userName']) && $_POST['userName']=="DuZZ"
     && isset($_POST['userPassword']) && $_POST['userPassword']==123456){
        if(setcookie("name", "DuZZ")){
        echo "登录成功, 返回首页";
        }
        else{
            echo "设置Cookie错误";
        }

    }
    else{
        echo "用户名或密码错误, 请重新登录";
    }
}
else{
$_html=<<<HTML
<h1>用户登录</h1>
<form 
    action=""
    method="post"       
>
    用户名:<input type="text" name="userName"><br/>
    密码:<input type="password" name="userPassword"><br/>
    <input type="submit" name="userSubmit" value="登录">
</form>
HTML;
echo $_html;
}
 ?>

（3）logout.php注销页面代码：

<meta charset="utf-8">
<?php
setcookie("name", $_COOKIE['name'], time()-3600);
echo "注销成功，返回首页";
?>

2.2.4 案例测试

（1）浏览器访问首页。输入网址http://172.16.1.1/PHP/Cookie/index.php。

（2）点击“请登录”进入登录页面。

（3）输入用户名：DuZZ，密码123456。点击登录，提示登录成功，点击返回首页。

(4)登录后的首页显示内容与未登录不一样，因为代码根据是否有COOKIE进行判断并分支执行。

（5）若要退出，则点击注销，进入注销页面。

3 Cookie攻击与防护

3.1 Cookie攻击

3.1.1 Cookie捕获/重放

攻击者可以通过木马等恶意程序，或使用跨站脚本攻击等手段偷窃存放在用户硬盘或内存中的Cookie。
借助网络攻击手段，包括①在不安全的局域网中被动地监听网络通信；②通过攻击网络用户的路由器，或通过搭建恶意的无线路由器等手法，控制路由基础设施，将网络流量重定向到攻击者控制的主机；③发动DNSPharming(域欺骗)攻击，通过DNS缓存中毒、DNS应答欺骗、或修改用户端的本地域名解析文件等方法攻击DNS系统，导致用户对合法网站的访问请求被重定向到恶意网站等等，同样可能窃取Cookie。对于捕获到的认证Cookie，攻击者往往会猜测其中的访问令牌，试图获取会话ID、用户名与口令、用户角色、时间戳等敏感信息；或者直接重放该Cookie，假冒受害者的身份发动攻击。

3.1.2 恶意 Cookies

Cookies 是文本文件， 一般情况下认为它不会造成安全威胁。 但是，如果在 Cookies 中通过特殊标记语言，引入可执行代码，就很可能给用户造成严重的安全隐患。HTML 为区别普通文本和标记语言，用符号“<>”来指示HTML 代码。 这些 HTML 代码或者定义 Web 网页格式，或者引入 Web 浏览器可执行代码段。 Web 服务 器可以使用Cookies 信息创建动态网页。假使 Cookies 包含可执行恶意代码段，那么在显示合成有该 Cookies 的网页时，就会自动执行这段恶意代码。当然，恶意代码能否真正造成危害，还取决于Web 站点的安全配置策略。

3.1.3 会话定置

会话定置(Session Fixation)攻击是指，攻击者向受害者主机注入自己控制的认证Cookie等信息，使得受害者以攻击者的身份登录网站，从而窃取受害者的会话信息。注入Cookie的方法包括：使用跨站脚本或木马等恶意程序；或伪造与合法网站同域的站点，并利用各种方法欺骗用户访问该仿冒网站，从而通过HTTP响应中的Set-Cookie头将攻击者拥有的该域Cookie发送给用户等。

3.1.4 CSRF攻击

跨站请求伪造（Cross-Site Request Forgery，简称CSRF）是指，攻击者可能利用网页中的恶意代码强迫受害者浏览器向被攻击的Web站点发送伪造的请求，篡夺受害者的认证Cookie等身份信息，从而假冒受害者对目标站点执行指定的操作。Firefox、Opera等浏览器使用单进程机制，多个窗口或标签使用同一个进程，共享Cookie等会话数据。IE则混合使用单进程与多进程模式，一个窗口中的多个标签，以及使用“CTRL+N” 或单击网页中的链接打开的新窗口使用同一进程，共享会话数据；只有直接运行IE可执行程序打开窗口时，才会创建新的进程。Chrome虽然使用多进程机制，然而经测试发现，其不同的窗口或标签之间仍会共享会话数据，除非使用隐身访问方式。因而，用户同时打开多个浏览器窗口或标签访问互联网资源时，就为CSRF攻击篡夺用户的会话Cookie创造了条件。另外，如果一个Web站点提供持久化Cookie，则CSRF攻击将更直接、更容易。

3.2 Cookie防护

3.2.1 Web服务器端防护

（1）加入MAC以进行完整性校验;
（2）防止非法用户非法截获后的重放，可以让用户对相关信息进行数字签名，加强有效性验证;
（3）对Cookie本身进行随机密钥加密，保证Cookie本身的信息安全。

3.2.2 客户端浏览器防护

客户端浏览器为了保证本地的Cookie安全，采取了对不同访问网站的统一Cookie加密，在相应的系统目录下，只可看见一个与Cookie相关的加密文件，而且其中的Cookie文件，已被浏览器加密，用户不可见，在用户访问特定站点的时候，可由浏览器对cookies文件进行调用并进行解密，将特定站点的Cookie发送到指定的站点服务器中，实现对用户的Cookie的认证。

3.2.3 主机的安全防护

在原有的服务器端以及客户端对Cookie的安全性控制下，鉴于不同的客户端浏览器对站点的Cookie控制相互独立，可以采取在客户端浏览器对产生的Cookie文件进行基于主机特征的安全性认证，即在浏览器产生Cookie加密文件时，在Cookie文件中加入一段主机的特征，生成一个双层加密的新的Cookie文件；在调用Cookie的时候，通过对Cookie文件进行主机特征的匹配，选择对内层的文件进行解密调用 。
然后，对嵌套了主机序列号的内层密文进行二次加密；内层加密保证对源Cookie内容的加密，保证Cookie信息的不可见，外层加密保证对主机特征的保护，以避免对主机特征的替换，通过对Cookie加入主机特征，以及两次对Cookie加密，可以在原有的防护机制下，为Cookie提供更加安全的保护。

4 归纳

（1）掌握什么是Cookie及Cookie的认证过程；
（2）掌握Cookie的相关属性及各属性的作用；
（3）掌握Cookie身份认证的应用案例；
（4）了解Cookie威胁与防护手段，后续学习如何攻击与如何防护。
（5）结合视频《Cookie、Session、Token究竟区别在哪？如何进行身份认证，保持用户登录状态？》，加深对cookie、Session和token三者的理解。

参考文章

[1]《Cookie （储存在用户本地终端上的数据）》
[2] 《官方手册setcookie》
[3] 《【PHP基础】Cookie基础知识、应用案例代码及攻防》