> For the complete documentation index, see [llms.txt](https://hacktricks.xsx.tw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacktricks.xsx.tw/pentesting-web/hacking-with-cookies.md). # Cookies Hacking
从零开始学习AWS黑客技术，成为专家 htARTE（HackTricks AWS红队专家）！ 支持HackTricks的其他方式： * 如果您想看到您的**公司在HackTricks中做广告**或**下载PDF格式的HackTricks**，请查看[**订阅计划**](https://github.com/sponsors/carlospolop)! * 获取[**官方PEASS & HackTricks周边产品**](https://peass.creator-spring.com) * 探索[**PEASS家族**](https://opensea.io/collection/the-peass-family)，我们的独家[**NFTs**](https://opensea.io/collection/the-peass-family) * **加入** 💬 [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或在**Twitter**上关注我们 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**。** * 通过向[**HackTricks**](https://github.com/carlospolop/hacktricks)和[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github仓库提交PR来分享您的黑客技巧。
**Try Hard Security Group**
{% embed url="" %} *** ## Cookie属性 Cookie带有几个属性，控制它们在用户浏览器中的行为。以下是这些属性的概述，使用更加被动的语气： ### 过期时间和Max-Age Cookie的过期日期由`Expires`属性确定。相反，`Max-age`属性定义了直到删除Cookie的时间（以秒为单位）。**选择`Max-age`，因为它反映了更现代的实践。** ### 域 `Domain`属性指定接收Cookie的主机。默认情况下，这设置为发出Cookie的主机，不包括其子域。但是，当显式设置`Domain`属性时，它也包括子域。这使得指定`Domain`属性成为一个不太限制的选项，适用于需要在子域之间共享Cookie的情况。例如，设置`Domain=mozilla.org`使得Cookie可以在其子域（如`developer.mozilla.org`）上访问。 ### 路径 `Path`属性指示必须在请求的URL中存在的特定URL路径，以便发送`Cookie`头。该属性将`/`字符视为目录分隔符，允许在子目录中进行匹配。 ### 排序规则 当两个Cookie具有相同的名称时，选择发送的Cookie基于： * 请求URL中匹配最长路径的Cookie。 * 如果路径相同，则选择最近设置的Cookie。 ### SameSite * `SameSite`属性规定了是否在来自第三方域的请求上发送Cookie。它提供三种设置： * **Strict**：限制Cookie在第三方请求上发送。 * **Lax**：允许Cookie随第三方网站发起的GET请求发送。 * **None**：允许从任何第三方域发送Cookie。 请记住，在配置Cookie时，了解这些属性可以帮助确保它们在不同情况下的行为符合预期。 | **请求类型** | **示例代码** | **发送Cookie的情况** | | -------- | ---------------------------------- | ------------------- | | 链接 | \\ | NotSet\*, Lax, None | | 预渲染 | \ | NotSet\*, Lax, None | | 表单 GET | \
| NotSet\*, Lax, None | | 表单 POST | \ | NotSet\*, None | | iframe | \ | NotSet\*, None | | AJAX | $.get("...") | NotSet\*, None | | 图片 | \ | NetSet\*, None | 表格来源于[Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/)，稍作修改。带有**SameSite**属性的Cookie将**减轻需要登录会话的CSRF攻击**。 **\*请注意，从Chrome80（2019年2月）开始，没有Cookie SameSite属性的Cookie的默认行为将是lax** ()。\ 请注意，临时地，在应用此更改后，Chrome中**没有SameSite策略的Cookie**在**前2分钟内将被视为None**，然后对于顶级跨站点POST请求将被视为Lax。 ## Cookies标志 ### HttpOnly 这可以防止**客户端**访问Cookie（例如通过**Javascript**：`document.cookie`） #### **绕过方式** * 如果页面**将Cookie作为响应发送**（例如在**PHPinfo**页面中），可以滥用XSS发送请求到此页面并从响应中**窃取Cookie**（在中查看示例）。 * 可以通过**TRACE** **HTTP**请求绕过此限制，因为服务器的响应将反映发送的Cookie。这种技术称为**跨站点跟踪**。 * 现代浏览器通过不允许从JS发送TRACE请求来避免此技术。然而，已经在特定软件中找到了对此的一些绕过方法，例如向IE6.0 SP2发送`\r\nTRACE`而不是`TRACE`。 * 另一种方法是利用浏览器的零/日漏洞。 * 可以通过执行Cookie Jar溢出攻击来**覆盖HttpOnly Cookie**： {% content-ref url="/pages/8KILehT5r0wEYH2ZY8OH" %} [Cookie Jar Overflow](/pentesting-web/hacking-with-cookies/cookie-jar-overflow.md) {% endcontent-ref %} * 可以使用[**Cookie Smuggling**](#cookie-smuggling)攻击来外泄这些Cookie ### Secure 只有在通过安全通道传输请求时（通常是**HTTPS**），请求才会发送Cookie。 ## Cookies前缀 以`__Secure-`为前缀的Cookie需要与通过HTTPS保护的页面一起设置`secure`标志。 对于以`__Host-`为前缀的Cookie，必须满足几个条件： * 必须使用`secure`标志设置。 * 必须来自通过HTTPS保护的页面。 * 不能指定域，防止将其传输到子域。 * 这些Cookie的路径必须设置为`/`。 重要的是要注意，以`__Host-`为前缀的Cookie不允许发送到超级域或子域。此限制有助于隔离应用程序Cookie。因此，考虑将`__Host-`前缀用于所有应用程序Cookie可以被视为增强安全性和隔离的良好实践。 ### 覆盖 cookies 因此，`__Host-` 前缀的 cookie 之一的保护措施是防止它们被子域覆盖。例如，防止 [**Cookie Tossing 攻击**](/pentesting-web/hacking-with-cookies/cookie-tossing.md)。在讲座 [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) 中提到，通过欺骗解析器，例如，在 cookie 名称的开头或开头和结尾添加 "="，可以从子域设置 `__HOST-` 前缀的 cookie：
或者在 PHP 中，可以在 cookie 名称的开头添加**其他字符**，这些字符将被**替换为下划线**字符，从而允许覆盖 `__HOST-` cookies：
## Cookies 攻击 如果自定义 cookie 包含敏感数据，请检查它（特别是在参加 CTF 时），因为它可能存在漏洞。 ### 解码和操纵 Cookies 应始终审查嵌入在 cookie 中的敏感数据。经过 Base64 或类似格式编码的 cookie 通常可以解码。这种漏洞允许攻击者更改 cookie 的内容，并通过将修改后的数据重新编码到 cookie 中来冒充其他用户。 ### 会话劫持 此攻击涉及窃取用户的 cookie 以未经授权地访问其应用程序中的帐户。通过使用窃取的 cookie，攻击者可以冒充合法用户。 ### 会话固定 在这种情况下，攻击者欺骗受害者使用特定的 cookie 登录。如果应用程序在登录时不分配新的 cookie，则拥有原始 cookie 的攻击者可以冒充受害者。此技术依赖于受害者使用攻击者提供的 cookie 登录。 如果在**子域中发现 XSS** 或者**控制子域**，请阅读： {% content-ref url="/pages/Jquw9fOADP68cSod1fr8" %} [Cookie Tossing](/pentesting-web/hacking-with-cookies/cookie-tossing.md) {% endcontent-ref %} ### 会话捐赠 在这里，攻击者说服受害者使用攻击者的会话 cookie。受害者认为他们已登录到自己的帐户中，将无意中在攻击者的帐户上执行操作。 如果在**子域中发现 XSS** 或者**控制子域**，请阅读： {% content-ref url="/pages/Jquw9fOADP68cSod1fr8" %} [Cookie Tossing](/pentesting-web/hacking-with-cookies/cookie-tossing.md) {% endcontent-ref %} ### [JWT Cookies](/pentesting-web/hacking-jwt-json-web-tokens.md) 单击上面的链接以访问解释 JWT 中可能存在缺陷的页面。 在 cookie 中使用的 JSON Web Tokens (JWT) 也可能存在漏洞。建议访问有关如何利用潜在缺陷的详细信息，访问有关黑客 JWT 的链接文档。 ### 跨站请求伪造 (CSRF) 此攻击强制已登录用户在当前已认证的 Web 应用程序上执行不需要的操作。攻击者可以利用自动发送到易受攻击站点的每个请求的 cookie。 ### 空 cookie （在[原始研究](https://blog.ankursundara.com/cookie-bugs/)中查看更多详细信息）浏览器允许创建没有名称的 cookie，可以通过 JavaScript 示例如下： ```js document.cookie = "a=v1" document.cookie = "=test value;" // Setting an empty named cookie document.cookie = "b=v2" ``` 发送的cookie头中的结果是 `a=v1; test value; b=v2;`。有趣的是，如果设置了一个空名称cookie，就可以操纵cookie，通过将空cookie设置为特定值，潜在地控制其他cookie： ```js function setCookie(name, value) { document.cookie = `${name}=${value}`; } setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value ``` 这会导致浏览器发送一个名为`a`值为`b`的cookie头，被每个Web服务器解释为一个名为`a`值为`b`的cookie。 #### Chrome Bug: Unicode Surrogate Codepoint Issue 在Chrome中，如果一个Unicode代理码点是一个设置的cookie的一部分，`document.cookie`会变得损坏，随后返回一个空字符串： ```js document.cookie = "\ud800=meep"; ``` 这导致 `document.cookie` 输出一个空字符串，表明永久性损坏。 #### 由于解析问题导致的Cookie走私 （请查看[原始研究](https://blog.ankursundara.com/cookie-bugs/)中的更多细节）一些Web服务器，包括Java（Jetty，TomCat，Undertow）和Python（Zope，cherrypy，web.py，aiohttp，bottle，webob）等，由于过时的RFC2965支持而错误处理Cookie字符串。它们将双引号括起的Cookie值视为单个值，即使其中包含分号，分号通常应该分隔键值对： ``` RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` #### Cookie注入漏洞 （查看[原始研究](https://blog.ankursundara.com/cookie-bugs/)中的更多细节）服务器对cookie的不正确解析，特别是Undertow、Zope以及使用Python的`http.cookie.SimpleCookie`和`http.cookie.BaseCookie`，为进行cookie注入攻击创造了机会。这些服务器未能正确界定新cookie的开始，允许攻击者伪造cookie： * Undertow期望在带引号的值后立即出现新cookie，而无需分号。 * Zope寻找逗号以开始解析下一个cookie。 * Python的cookie类在空格字符上开始解析。 这种漏洞在依赖基于cookie的CSRF保护的Web应用程序中尤为危险，因为它允许攻击者注入伪造的CSRF令牌cookie，可能绕过安全措施。Python处理重复cookie名称的方式进一步加剧了这个问题，最后出现的覆盖了先前的。在不安全的环境中，`__Secure-`和`__Host-` cookie也引发了担忧，当cookie传递给容易伪造的后端服务器时，可能导致授权绕过。 ### 额外易受攻击的Cookie检查 #### **基本检查** * **cookie** 每次**登录**都是**相同**的。 * 注销然后尝试使用相同的cookie。 * 尝试使用相同的cookie在2台设备（或浏览器）上登录到同一个帐户。 * 检查cookie中是否有任何信息，并尝试修改它。 * 尝试创建几个几乎相同用户名的帐户，并检查是否存在相似之处。 * 检查是否存在“**记住我**”选项，看看它是如何工作的。如果存在且可能存在漏洞，始终只使用“记住我”cookie，而不使用其他cookie。 * 检查即使更改密码后，先前的cookie是否仍然有效。 #### **高级cookie攻击** 如果在登录时cookie保持不变（或几乎不变），这可能意味着cookie与您帐户的某个字段相关（可能是用户名）。然后您可以： * 尝试创建许多非常相似的用户名的**帐户**，并尝试**猜测**算法的工作原理。 * 尝试**暴力破解用户名**。如果cookie仅将您的用户名保存为身份验证方法之一，那么您可以创建一个用户名为“**Bmin**”的帐户，并**暴力破解**您cookie的每一位，因为您尝试的cookie之一将属于“**admin**”。 * 尝试**填充\*\*\*\*Oracle**（您可以解密cookie的内容）。使用**padbuster**。 **填充Oracle - Padbuster示例** ```bash padbuster # When cookies and regular Base64 padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf # If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example: padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2 ``` Padbuster将尝试多次，并询问您哪个条件是错误条件（即无效条件）。 然后它将开始解密cookie（可能需要几分钟） 如果攻击成功执行，那么您可以尝试加密您选择的字符串。例如，如果您想要**加密** **user=administrator** ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` 这个执行将给出正确加密和编码的 cookie，其中包含字符串 **user=administrator**。 **CBC-MAC** 也许一个 cookie 可能会有一些值，并且可以使用 CBC 进行签名。然后，值的完整性是使用相同值使用 CBC 创建的签名。由于建议使用一个空向量作为 IV，这种完整性检查可能会有漏洞。 **攻击** 1. 获取用户名 **administ** 的签名 = **t** 2. 获取用户名 **rator\x00\x00\x00 XOR t** 的签名 = **t'** 3. 在 cookie 中设置值 **administrator+t'**（**t'** 将是 **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00** 的有效签名） **ECB** 如果使用 ECB 加密 cookie，可能会有漏洞。\ 当您登录时，收到的 cookie 必须始终相同。 **如何检测和攻击:** 创建两个几乎相同数据的用户（用户名、密码、电子邮件等），并尝试发现给定 cookie 中的某种模式 创建一个名为例如 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" 的用户，并检查 cookie 中是否有任何模式（由于 ECB 使用相同的密钥加密每个块，如果用户名被加密，则相同的加密字节可能会出现）。 应该有一个模式（与使用的块大小相同）。因此，知道一堆 "a" 是如何加密的，您可以创建一个用户名："a"\*(块的大小)+"admin"。然后，您可以从 cookie 中删除一个块的加密模式 "a"，然后您将得到用户名 "admin" 的 cookie。 ## 参考资料 * * **Try Hard Security Group**
{% embed url="" %}
从零开始学习 AWS 黑客技术，成为专家 htARTE（HackTricks AWS 红队专家）！ 支持 HackTricks 的其他方式： * 如果您想看到您的 **公司在 HackTricks 中做广告** 或 **下载 PDF 版本的 HackTricks**，请查看 [**订阅计划**](https://github.com/sponsors/carlospolop)! * 获取 [**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com) * 发现 [**PEASS 家族**](https://opensea.io/collection/the-peass-family)，我们独家的 [**NFT**](https://opensea.io/collection/the-peass-family) 收藏品 * **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注** 我们的 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**。** * 通过向 [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享您的黑客技巧。