Cookie指某些网站为了辨别用户身份而储存在用户本地客户端上的数据。
因为HTTP协议是不保存用户状态的，这使得用户在交互式的web应用中体验非常差。
在一个网上购物的场景中，用户向购物车添加了一些商品，最后结账时，由于HTTP的无状态性，不通过额外参数，服务器并不知道哪位用户购买了哪些商品。在这种场景下，服务端可通过设置或读取Cookie中包含的信息，维护用户的会话状态。
在这篇文章中，我们将列出各种攻击场景，如果web应用使用Cookie进行认证或其它个性化的功能，那它就可能成为黑客眼中的一个攻击手段。文中提到的场景，少部分可能需要结合其它漏洞才能实现攻击效果，例如中间人攻击篡改数据等，由于利用场景复杂，实现难度较大，漏洞描述相对少一些，如有兴趣，文章末尾会给出相关链接。
跨站脚本攻击（XSS）是最常见的web漏洞之一，攻击者通常会利用XSS来窃取Cookie，但Cookie也可能会成为攻击者payload中的一部分。
网站开发者在某些情况下会将Cookie作为网页的一部分内容，写入html中。例如许多开发者喜欢将用户的昵称等看似无关紧要的信息存储再Cookie中。此时大家可能有些疑问，为什么Cookie不是服务端返回设置的吗，那攻击者如何修改用户的Cookie呢？
其实并不然，许多开发者在不经意间会将一些统计信息写入Cookie，例如referer、url参数、邀请链接中的邀请码等等，一旦有写入cookie的动作，就会让攻击者有机可趁，构造恶意的Cookie使其出现在HTML中型成XSS。
会话管理不当通常指会话退出后没有注销、会话有效时间过长、重置或修改密码后未清除旧会话和会话能够被异地重放等情况，攻击者通过信息泄漏或其它方式，得到某用户的会话信息后，可以在不同环境下使用相同的会话，调用Api或在web应用中使用相同的功能。
越权漏洞顾名思义，就是绕过普通用户的权限，可以访问或修改其它用户的数据，甚至有可能是管理员用户数据的漏洞。在Cookie中如果用户的特征过于明显，例如user_id=1 ,那么攻击者就会尝试修改Cookie中的id探测是否存在越权漏洞。
具有Secure属性值的Cookie只应通过被 HTTPS 协议加密过的请求发送给服务端，因此可以预防 中间人攻击。但即便给Cookie设置了Secure属性，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其与生俱来的不安全性，Secure 标记也无法提供确实的安全保障。
从 Chrome 52 和 Firefox 52 开始，仅使用http协议的站点无法对Cookie赋予 Secure 属性。
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这个概念很早就被提出，但是全面推广应用的时间线大概在Chrome83版本之后。
-
Cookie允许与top页面一起发送，并将与第三方网站发起的GET请求一起发送。如果服务端没有强行设置Same-Site的值，那么Lax就会作为默认的Same-Site值。
-
Strict
Cookie只会在当前域名下发送，第三方网站不允许使用当前Cookie值
-
Cookie将在所有上下文中发送，即允许跨域发送。
没有 SameSite 属性的Cookies默认为 SameSite=Lax；
此属性只能由HTTP服务端进行设置，常见的形式如下：
Set-Cookie: flavor=choco; SameSite=None
简而言之，只要你使用了最新版本83版本之后的Chrome，就不用担心被溯源脚本抓取到个人信息了，攻击队大佬们可以放心上网冲浪了。
当然，如果网站强行将Same-Site属性值设置为None，也就是不使用Same-Site，第三方的Cookie仍然会被发送至服务端，依然有可能被溯源脚本抓取到。
这里所说的Cookie，指的是在服务端创建完成并返回到前端的Cookie。如果一个较为重要的Cookie值，仅通过简单的算法（例如Base64）生成，而不是随机或使用单向函数（例如md5）生成的，那么就存在一定被破解的风险。
假定攻击者可以通过此方法生成一个新的有效的Cookie，那么理论上可以获得任何属于该站点的用户凭证，认证机制形同虚设，在discuz的某登录插件中就存在此类问题。
文件包含漏洞产生的根本原因是服务端没有对用户是输入判断，传入了require、require_once、include，include_once方法中导致的。此漏洞的输入点通常不会在Cookie中，但也有例外。国外安全研究员Ismayil Tahmazov在测试漏洞的过程中发现，键值为lang的Cookie值发送到服务端后，没有经过过滤并且抛出了异常，产生了文件包含漏洞，漏洞详情可见本文参考链接【2】。
用户的个人信息或部分个人信息，如收货地址、手机号码、购物车记录、真实姓名，甚至是身份证信息，都可能被粗心的开发者写入Cookie中，无论是加密还是非加密的方式。
许多开发者喜欢将对象序列化存储在Cookie中，但并未意识到这样情况下会产生极大的安全风险。无论服务端使用的开发语言Python还是Java，都逃不开反序列化的风险。
大家熟知的Shiro-550漏洞（CVE-2016-4437），就是非常典型的反序列化导致远程命令执行漏洞例子，该漏洞的利用代码是经过序列化后的数据存放在Cookie中，特征难以识别，网络防护设备防护效果差，即便到了今天，互联网上仍然有一部分web系统可能遭受此漏洞影响。漏洞详情可见本文参考链接【3】
SQL注入是最为常见的web漏洞之一，Cookie和url中的参数没有区别，都是作为常规字符串或数字传入服务端代码中，此处不再赘述。
参数污染也可以理解为参数覆盖。常见的后端框架在处理Cookie数据时，不会判断Cookie中是否包含重名的值。攻击者构造出大量的重名Cookie，以此干扰后端程序的正常运行，可能会导致权限绕过等问题。
未授权访问漏洞也可以理解为服务端配置不当。例如某敏感业务需要用户登录或管理员登录后才可以访问，但路由上并没有覆盖到，或在配置文件中，允许不使用Cookie就允许访问此页面，就可能产生未授权访问漏洞。像Tomcat任意文件上传漏洞、Jenkins未授权访问漏洞都是由于配置不当导致的。
零信任网关在攻击者访问到对应资源前，就要求每位用户主动认证。所以像SQL注入、反序列化漏洞、文件包含等漏洞，如果想要在零信任防御体系下完成常规web漏洞的利用，门槛较高
对于参数污染和敏感信息存储漏洞等，零信任平台可以通过威胁感知、数据防泄漏等安全能力，对返回数据中已有的敏感数据做脱敏处理，同时也可以在平台进行告警，由IT/安全人员评估后告知研发人员是否存在风险及如何处理风险
基于Cookie的攻击方法远不止以上方法，更多的攻击手法可见本文参考链接【4】。
无论是远程代码执行还是权限绕过漏洞，其根本原因都是开发者在处理数据时，认为用户“不可能”修改，因此过分相信用户的输入并使用了该数据。
网络安全的本质是人与人、数据与数据之间的对抗，我们在了解已有漏洞场景的同时，会持续探索和研究新型的攻击方式。如对此类漏洞或其它安全问题存在疑问，可联系持安科技7*24小时应急响应团队：[email protected]
-
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cookies
-
https://medium.com/@tehmezovismayil/cookie-based-php-local-file-inclusion-bug-bounty-553f8b38d4dc
-
https://xz.aliyun.com/t/7793
-
https://book.hacktricks.xyz/pentesting-web/hacking-with-cookies
关于我们：
北京持安科技是一家新兴网络安全公司。聚焦零信任前沿技术研究，面向企业级市场提供基于零信任架构的网络安全产品和零信任安全解决方案。中国产业互联网发展联盟、零信任实验室、云安全联盟（CSA）GCR会员单位。目前已获得IDG、金沙江、完美世界等多家知名创投机构数千万元投资。公司致力于将近 20 年的甲乙方安全经验，6 年持续积累的零信任实际落地经验，转化为高质量的零信任产品和服务，为客户输出安全价值，真实解决客户安全问题，持续助力客户发展。
原文始发于微信公众号（持安科技）：科普：使用Cookie会导致哪些安全问题?
