安全科普：使用Cookie会导致哪些安全问题?

0x01 Cookie的前世今身

Cookie指某些网站为了辨别用户身份而储存在用户本地客户端上的数据。

因为HTTP协议是不保存用户状态的，这使得用户在交互式的web应用中体验非常差。

 

在一个网上购物的场景中，用户向购物车添加了一些商品，最后结账时，由于HTTP的无状态性，不通过额外参数，服务器并不知道哪位用户购买了哪些商品。在这种场景下，服务端可通过设置或读取Cookie中包含的信息，维护用户的会话状态。

0x02 由Cookie延伸出的漏洞

在这篇文章中，我们将列出各种攻击场景，如果web应用使用Cookie进行认证或其它个性化的功能，那它就可能成为黑客眼中的一个攻击手段。文中提到的场景，少部分可能需要结合其它漏洞才能实现攻击效果，例如中间人攻击篡改数据等，由于利用场景复杂，实现难度较大，漏洞描述相对少一些，如有兴趣，文章末尾会给出相关链接。

 

1. 跨站脚本攻击

   跨站脚本攻击（XSS）是最常见的web漏洞之一，攻击者通常会利用XSS来窃取Cookie，但Cookie也可能会成为攻击者payload中的一部分。

   网站开发者在某些情况下会将Cookie作为网页的一部分内容，写入html中。例如许多开发者喜欢将用户的昵称等看似无关紧要的信息存储再Cookie中。此时大家可能有些疑问，为什么Cookie不是服务端返回设置的吗，那攻击者如何修改用户的Cookie呢？

   其实并不然，许多开发者在不经意间会将一些统计信息写入Cookie，例如referer、url参数、邀请链接中的邀请码等等，一旦有写入cookie的动作，就会让攻击者有机可趁，构造恶意的Cookie使其出现在HTML中型成XSS。

2. 会话管理不当

   会话管理不当通常指会话退出后没有注销、会话有效时间过长、重置或修改密码后未清除旧会话和会话能够被异地重放等情况，攻击者通过信息泄漏或其它方式，得到某用户的会话信息后，可以在不同环境下使用相同的会话，调用Api或在web应用中使用相同的功能。

3. 越权漏洞

   越权漏洞顾名思义，就是绕过普通用户的权限，可以访问或修改其它用户的数据，甚至有可能是管理员用户数据的漏洞。在Cookie中如果用户的特征过于明显，例如user_id=1 ,那么攻击者就会尝试修改Cookie中的id探测是否存在越权漏洞。

4. Cookie缺少安全属性

   Cookie中最常见的安全属性有以下三种

   Secure

   具有Secure属性值的Cookie只应通过被 HTTPS 协议加密过的请求发送给服务端，因此可以预防 中间人攻击。但即便给Cookie设置了Secure属性，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其与生俱来的不安全性，Secure 标记也无法提供确实的安全保障。

   从 Chrome 52 和 Firefox 52 开始，仅使用http协议的站点无法对Cookie赋予 Secure 属性。

   HttpOnly

   Cookie一旦被添加了HttpOnly属性，JavaScript就无法访问带有此属性的Cookie值。不可读取，也无法通过JavaScript对某些Cookie设置HttpOnly属性。

   此属性只能由HTTP服务端进行设置，常见的形式如下：

   Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

   Same-Site

   Same-Site这个概念很早就被提出，但是全面推广应用的时间线大概在Chrome83版本之后。

   Same-Site有以下三种值可选：

   • Lax Cookie允许与top页面一起发送，并将与第三方网站发起的GET请求一起发送。如果服务端没有强行设置Same-Site的值，那么Lax就会作为默认的Same-Site值。

   • Strict Cookie只会在当前域名下发送，第三方网站不允许使用当前Cookie值。

   • None Cookie将在所有上下文中发送，即允许跨域发送。

     没有 SameSite 属性的Cookies默认为 SameSite=Lax；

     此属性只能由HTTP服务端进行设置，常见的形式如下：

     Set-Cookie: flavor=choco; SameSite=None

     简而言之，只要你使用了最新版本83版本之后的Chrome，就不用担心被溯源脚本抓取到个人信息了，攻击队大佬们可以放心上网冲浪了。

     （当然，如果网站强行将Same-Site属性值设置为None，也就是不使用Same-Site，第三方的Cookie仍然会被发送至服务端，依然有可能被溯源脚本抓取到。）

5. 易被猜解的Cookie

   这里所说的Cookie，指的是在服务端创建完成并返回到前端的Cookie。如果一个较为重要的Cookie值，仅通过简单的算法（例如Base64）生成，而不是随机或使用单向函数（例如md5）生成的，那么就存在一定被破解的风险。

   假定攻击者可以通过此方法生成一个新的有效的Cookie，那么理论上可以获得任何属于该站点的用户凭证，认证机制形同虚设，在discuz的某登录插件中就存在此类问题。

6. 文件包含

   文件包含漏洞产生的根本原因是服务端没有对用户是输入判断，传入了require、require_once、include，include_once方法中导致的。此漏洞的输入点通常不会在Cookie中，但也有例外。国外安全研究员Ismayil Tahmazov在测试漏洞的过程中发现，键值为lang的Cookie值发送到服务端后，没有经过过滤并且抛出了异常，产生了文件包含漏洞，漏洞详情可见本文参考链接【2】。

7. 敏感信息存储

   用户的个人信息或部分个人信息，如收货地址、手机号码、购物车记录、真实姓名，甚至是身份证信息，都可能被粗心的开发者写入Cookie中，无论是加密还是非加密的方式。

8. 不安全的反序列化

   许多开发者喜欢将对象序列化存储在Cookie中，但并未意识到这样情况下会产生极大的安全风险。无论服务端使用的开发语言Python还是Java，都逃不开反序列化的风险。

   大家熟知的Shiro-550漏洞（CVE-2016-4437），就是非常典型的反序列化导致远程命令执行漏洞例子，该漏洞的利用代码是经过序列化后的数据存放在Cookie中，特征难以识别，网络防护设备防护效果差，即便到了今天，互联网上仍然有一部分web系统可能遭受此漏洞影响。

   漏洞详情可见本文参考链接【3】

9. SQL Injection

   SQL注入是最为常见的web漏洞之一，Cookie和url中的参数没有区别，都是作为常规字符串或数字传入服务端代码中，此处不再赘述。

10. 参数污染

    参数污染也可以理解为参数覆盖。常见的后端框架在处理Cookie数据时，不会判断Cookie中是否包含重名的值。攻击者构造出大量的重名Cookie，以此干扰后端程序的正常运行，可能会导致权限绕过等问题。

11. 未授权访问

    未授权访问漏洞也可以理解为服务端配置不当。例如某敏感业务需要用户登录或管理员登录后才可以访问，但路由上并没有覆盖到，或在配置文件中，允许不使用Cookie就允许访问此页面，就可能产生未授权访问漏洞。像Tomcat任意文件上传漏洞、Jenkins未授权访问漏洞都是由于配置不当导致的。

0x03 零信任系统如何防御

1. 零信任网关在攻击者访问到对应资源前，就要求每位用户主动认证。所以像SQL注入、反序列化漏洞、文件包含等漏洞，如果想要在零信任防御体系下完成常规web漏洞的利用，门槛较高
2. 对于参数污染和敏感信息存储漏洞等，零信任平台可以通过威胁感知、数据防泄漏等安全能力，对返回数据中已有的敏感数据做脱敏处理，同时也可以在平台进行告警，由IT/安全人员评估后告知研发人员是否存在风险及如何处理风险

 

0x04 总结

基于Cookie的攻击方法远不止以上方法，更多的攻击手法可见本文参考链接【4】。

无论是远程代码执行还是权限绕过漏洞，其根本原因都是开发者在处理数据时，认为用户“不可能”修改，因此过分相信用户的输入并使用了该数据。

网络安全的本质是人与人、数据与数据之间的对抗，我们在了解已有漏洞场景的同时，会持续探索和研究新型的攻击方式。如对此类漏洞或其它安全问题存在疑问，可联系持安科技7*24小时应急响应团队：service@chiansec.com

0x05 参考资料

1. HTTP cookies - HTTP | MDN
2. https://medium.com/@tehmezovismayil/cookie-based-php-local-file-inclusion-bug-bounty-553f8b38d4dc
3. https://xz.aliyun.com/t/7793
4. Cookies Hacking - HackTricks