mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent
This commit is contained in:
Translator
parent
d7e54cd05e
commit
9d75c19f85
@ -1,15 +1,15 @@
|
||||
# 域名/子域名接管
|
||||
# Domain/Subdomain takeover
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## 域名接管
|
||||
## Domain takeover
|
||||
|
||||
如果你发现某个域名 (domain.tld) **被某个服务使用在范围内**，但该 **公司** 已经 **失去** 了对它的 **所有权**，你可以尝试 **注册** 它（如果价格足够便宜）并通知公司。如果这个域名接收一些 **敏感信息**，比如通过 **GET** 参数或 **Referer** 头部的会话 cookie，这肯定是一个 **漏洞**。
|
||||
如果你发现某个域名 (domain.tld) **被某个服务使用在范围内**，但该 **公司** 已经 **失去** 了对它的 **所有权**，你可以尝试 **注册** 它（如果价格足够便宜）并通知公司。如果这个域名接收一些 **敏感信息**，比如通过 **GET** 参数或在 **Referer** 头中的会话 cookie，这肯定是一个 **漏洞**。
|
||||
|
||||
### 子域名接管
|
||||
### Subdomain takeover
|
||||
|
||||
公司的一个子域名指向一个 **未注册名称的第三方服务**。如果你可以在这个 **第三方服务** 中 **创建** 一个 **账户** 并 **注册** 正在使用的 **名称**，你就可以执行子域名接管。
|
||||
公司的一个子域名指向一个 **未注册名称的第三方服务**。如果你可以在这个 **第三方服务** 中 **创建** 一个 **账户** 并 **注册** 正在使用的 **名称**，你可以执行子域名接管。
|
||||
|
||||
有几个工具带有字典来检查可能的接管：
|
||||
|
||||
@ -27,55 +27,72 @@
|
||||
- [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
|
||||
- [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)
|
||||
|
||||
### 通过 DNS 通配符生成子域名接管
|
||||
### Subdomain Takeover Generation via DNS Wildcard
|
||||
|
||||
当在一个域名中使用 DNS 通配符时，任何请求的子域名如果没有明确的不同地址，将会 **解析为相同的信息**。这可以是 A IP 地址，CNAME...
|
||||
当域名使用 DNS 通配符时，任何请求的子域名如果没有明确的不同地址，将会 **解析为相同的信息**。这可以是 A IP 地址，CNAME...
|
||||
|
||||
例如，如果 `*.testing.com` 被通配符指向 `1.1.1.1`。那么，`not-existent.testing.com` 将指向 `1.1.1.1`。
|
||||
|
||||
然而，如果系统管理员不是指向一个 IP 地址，而是通过 CNAME 指向一个 **第三方服务**，比如一个 G**ithub 子域名**（例如 `sohomdatta1.github.io`）。攻击者可以 **创建他自己的第三方页面**（在 Gihub 中）并声称 `something.testing.com` 指向那里。因为，**CNAME 通配符** 将允许攻击者 **为受害者的域名生成任意子域名指向他的页面**。
|
||||
然而，如果系统管理员不是指向一个 IP 地址，而是通过 CNAME 指向一个 **第三方服务**，例如一个 G**ithub 子域名**（`sohomdatta1.github.io`）。攻击者可以 **创建他自己的第三方页面**（在这种情况下是在 Gihub 上）并声称 `something.testing.com` 指向那里。因为，**CNAME 通配符** 将允许攻击者 **为受害者的域名生成任意子域名指向他的页面**。
|
||||
|
||||
你可以在 CTF 文章中找到这个漏洞的例子：[https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
|
||||
|
||||
## 利用子域名接管
|
||||
## Exploiting a subdomain takeover
|
||||
|
||||
子域名接管本质上是在互联网上对特定域名的 DNS 欺骗，允许攻击者为一个域名设置 A 记录，使浏览器显示来自攻击者服务器的内容。这种浏览器中的 **透明性** 使域名容易受到网络钓鱼攻击。攻击者可能会使用 [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) 或 [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) 来实现这一目的。特别容易受到攻击的是那些在网络钓鱼邮件中看似合法的 URL，欺骗用户并由于域名的固有信任而逃避垃圾邮件过滤器。
|
||||
子域名接管本质上是针对特定域名的 DNS 欺骗，允许攻击者为一个域名设置 A 记录，使浏览器显示来自攻击者服务器的内容。这种 **透明性** 使得域名容易受到网络钓鱼攻击。攻击者可能会使用 [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) 或 [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) 来实现这一目的。特别容易受到攻击的是那些在网络钓鱼邮件中看似合法的 URL，欺骗用户并因域名的固有信任而逃避垃圾邮件过滤器。
|
||||
|
||||
查看这个 [帖子以获取更多细节](https://0xpatrik.com/subdomain-takeover/)
|
||||
查看这个 [post for further details](https://0xpatrik.com/subdomain-takeover/)
|
||||
|
||||
### **SSL 证书**
|
||||
### **SSL Certificates**
|
||||
|
||||
如果攻击者通过像 [_Let's Encrypt_](https://letsencrypt.org/) 这样的服务生成 SSL 证书，会增加这些假域名的合法性，使网络钓鱼攻击更具说服力。
|
||||
如果攻击者通过像 [_Let's Encrypt_](https://letsencrypt.org/) 这样的服务生成 SSL 证书，将增加这些假域名的合法性，使网络钓鱼攻击更具说服力。
|
||||
|
||||
### **Cookie 安全性和浏览器透明性**
|
||||
### **Cookie Security and Browser Transparency**
|
||||
|
||||
浏览器透明性还扩展到 cookie 安全性，受 [同源策略](https://en.wikipedia.org/wiki/Same-origin_policy) 的管理。Cookie 通常用于管理会话和存储登录令牌，可以通过子域名接管进行利用。攻击者可以 **收集会话 cookie**，只需将用户引导到一个被攻陷的子域名，危及用户数据和隐私。
|
||||
浏览器的透明性也扩展到 cookie 安全，由像 [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) 这样的政策管理。cookie 通常用于管理会话和存储登录令牌，可以通过子域名接管进行利用。攻击者可以 **收集会话 cookie**，只需将用户引导到一个被攻陷的子域名，危及用户数据和隐私。
|
||||
|
||||
### **电子邮件和子域名接管**
|
||||
### CORS Bypass
|
||||
|
||||
子域名接管的另一个方面涉及电子邮件服务。攻击者可以操纵 **MX 记录** 从合法子域名接收或发送电子邮件，从而增强网络钓鱼攻击的有效性。
|
||||
可能每个子域名都被允许访问来自主域或其他子域的 CORS 资源。攻击者可以利用这一点 **访问敏感信息**，滥用 CORS 请求。
|
||||
|
||||
### **更高的风险**
|
||||
### CSRF - Same-Site Cookies bypass
|
||||
|
||||
进一步的风险包括 **NS 记录接管**。如果攻击者控制了一个域名的 NS 记录，他们可以将部分流量引导到他们控制的服务器。如果攻击者为 DNS 记录设置了高 **TTL（生存时间）**，则这种风险会加剧，延长攻击的持续时间。
|
||||
可能子域名被允许向主域或其他子域发送 cookie，而这被 cookie 的 `Same-Site` 属性所阻止。然而，请注意，如果反 CSRF 令牌得到了正确的实施，仍然会阻止此攻击。
|
||||
|
||||
### CNAME 记录漏洞
|
||||
### OAuth tokens redirect
|
||||
|
||||
攻击者可能会利用指向不再使用或已停用的外部服务的未声明 CNAME 记录。这使他们能够在受信任的域名下创建一个页面，进一步促进网络钓鱼或恶意软件分发。
|
||||
可能被攻陷的子域名被允许在 OAuth 流程的 `redirect_uri` URL 中使用。攻击者可以利用这一点 **窃取 OAuth 令牌**。
|
||||
|
||||
### **缓解策略**
|
||||
### CSP Bypass
|
||||
|
||||
可能被攻陷的子域名（或每个子域名）被允许用于 CSP 的 `script-src`。攻击者可以利用这一点 **注入恶意脚本** 并滥用潜在的 XSS 漏洞。
|
||||
|
||||
### **Emails and Subdomain Takeover**
|
||||
|
||||
子域名接管的另一个方面涉及电子邮件服务。攻击者可以操纵 **MX 记录** 从合法子域接收或发送电子邮件，从而增强网络钓鱼攻击的有效性。
|
||||
|
||||
### **Higher Order Risks**
|
||||
|
||||
进一步的风险包括 **NS 记录接管**。如果攻击者控制了一个域名的 NS 记录，他们可以将一部分流量引导到他们控制的服务器上。如果攻击者为 DNS 记录设置了高 **TTL（生存时间）**，则这一风险会加大，延长攻击的持续时间。
|
||||
|
||||
### CNAME Record Vulnerability
|
||||
|
||||
攻击者可能会利用指向不再使用或已停用的外部服务的未声明 CNAME 记录。这使他们能够在受信域名下创建页面，进一步促进网络钓鱼或恶意软件分发。
|
||||
|
||||
### **Mitigation Strategies**
|
||||
|
||||
缓解策略包括：
|
||||
|
||||
1. **删除易受攻击的 DNS 记录** - 如果子域名不再需要，这种方法有效。
|
||||
1. **删除易受攻击的 DNS 记录** - 如果子域名不再需要，这种方法是有效的。
|
||||
2. **声明域名** - 在相应的云提供商处注册资源或重新购买过期域名。
|
||||
3. **定期监控漏洞** - 像 [aquatone](https://github.com/michenriksen/aquatone) 这样的工具可以帮助识别易受攻击的域名。组织还应修订其基础设施管理流程，确保 DNS 记录的创建是资源创建的最后一步，而资源销毁的第一步。
|
||||
|
||||
对于云提供商，验证域名所有权对于防止子域名接管至关重要。一些提供商，如 [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)，已经认识到这个问题并实施了域名验证机制。
|
||||
|
||||
## 参考文献
|
||||
## References
|
||||
|
||||
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
|
||||
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
|
||||
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Cookie Attributes
|
||||
|
||||
Cookies 具有几个属性，控制它们在用户浏览器中的行为。以下是这些属性的简要说明：
|
||||
Cookies 具有几个属性，控制它们在用户浏览器中的行为。以下是这些属性的概述：
|
||||
|
||||
### Expires and Max-Age
|
||||
|
||||
@ -27,7 +27,7 @@ Cookie 的过期日期由 `Expires` 属性决定。相反，`Max-age` 属性定
|
||||
|
||||
### SameSite
|
||||
|
||||
- `SameSite` 属性决定是否在来自第三方域的请求中发送 cookie。它提供三种设置：
|
||||
- `SameSite` 属性决定 cookie 是否在来自第三方域的请求中发送。它提供三种设置：
|
||||
- **Strict**：限制 cookie 在第三方请求中发送。
|
||||
- **Lax**：允许 cookie 与由第三方网站发起的 GET 请求一起发送。
|
||||
- **None**：允许 cookie 从任何第三方域发送。
|
||||
@ -47,8 +47,8 @@ Cookie 的过期日期由 `Expires` 属性决定。相反，`Max-age` 属性定
|
||||
表格来自 [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 属性的默认行为将为 lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
||||
请注意，临时情况下，在应用此更改后，**没有 SameSite** **策略的 cookie 在 Chrome 中将被 **视为 None**，在 **前 2 分钟内，然后在顶级跨站点 POST 请求中视为 Lax**。
|
||||
**\*请注意，从 Chrome80（2019年2月）开始，未设置 cookie samesite 属性的 cookie 的默认行为将是 lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
||||
请注意，临时情况下，在应用此更改后，Chrome 中 **没有 SameSite** **策略的 cookie 将在 **前 2 分钟内被 **视为 None**，然后在顶级跨站点 POST 请求中视为 Lax。**
|
||||
|
||||
## Cookies Flags
|
||||
|
||||
@ -85,7 +85,7 @@ cookie-jar-overflow.md
|
||||
- 禁止指定域，防止其传输到子域。
|
||||
- 这些 cookie 的路径必须设置为 `/`。
|
||||
|
||||
重要的是要注意，以 `__Host-` 开头的 cookie 不允许发送到超级域或子域。此限制有助于隔离应用程序 cookie。因此，使用 `__Host-` 前缀为所有应用程序 cookie 被视为增强安全性和隔离的良好做法。
|
||||
重要的是要注意，以 `__Host-` 开头的 cookie 不允许发送到超级域或子域。此限制有助于隔离应用程序 cookie。因此，使用 `__Host-` 前缀为所有应用程序 cookie 被视为增强安全性和隔离性的良好做法。
|
||||
|
||||
### Overwriting cookies
|
||||
|
||||
@ -107,13 +107,13 @@ cookie-jar-overflow.md
|
||||
|
||||
### Session Hijacking
|
||||
|
||||
此攻击涉及窃取用户的 cookie，以获得对其在应用程序中的帐户的未授权访问。通过使用被盗的 cookie，攻击者可以冒充合法用户。
|
||||
此攻击涉及窃取用户的 cookie，以获得对其在应用程序中的帐户的未经授权访问。通过使用被盗的 cookie，攻击者可以冒充合法用户。
|
||||
|
||||
### Session Fixation
|
||||
|
||||
在这种情况下，攻击者诱使受害者使用特定的 cookie 登录。如果应用程序在登录时不分配新的 cookie，攻击者就可以使用原始 cookie 冒充受害者。此技术依赖于受害者使用攻击者提供的 cookie 登录。
|
||||
在这种情况下，攻击者诱使受害者使用特定的 cookie 登录。如果应用程序在登录时不分配新 cookie，攻击者持有原始 cookie，可以冒充受害者。此技术依赖于受害者使用攻击者提供的 cookie 登录。
|
||||
|
||||
如果您在 **子域中发现了 XSS** 或您 **控制一个子域**，请阅读：
|
||||
如果您在子域中发现 **XSS** 或您 **控制一个子域**，请阅读：
|
||||
|
||||
{{#ref}}
|
||||
cookie-tossing.md
|
||||
@ -123,7 +123,7 @@ cookie-tossing.md
|
||||
|
||||
在这里，攻击者说服受害者使用攻击者的会话 cookie。受害者相信他们已登录自己的帐户，将无意中在攻击者的帐户上下文中执行操作。
|
||||
|
||||
如果您在 **子域中发现了 XSS** 或您 **控制一个子域**，请阅读：
|
||||
如果您在子域中发现 **XSS** 或您 **控制一个子域**，请阅读：
|
||||
|
||||
{{#ref}}
|
||||
cookie-tossing.md
|
||||
@ -133,7 +133,7 @@ cookie-tossing.md
|
||||
|
||||
点击上面的链接访问解释 JWT 可能存在缺陷的页面。
|
||||
|
||||
用于 cookie 的 JSON Web Tokens (JWT) 也可能存在漏洞。有关潜在缺陷及其利用方法的深入信息，建议访问有关黑客 JWT 的链接文档。
|
||||
用于 cookie 的 JSON Web Tokens (JWT) 也可能存在漏洞。有关潜在缺陷及其利用方式的深入信息，建议访问有关黑客 JWT 的链接文档。
|
||||
|
||||
### Cross-Site Request Forgery (CSRF)
|
||||
|
||||
@ -147,7 +147,7 @@ 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，这允许对 cookies 进行操控，通过将空 cookie 设置为特定值，可能控制其他 cookies：
|
||||
在发送的 cookie 头中的结果是 `a=v1; test value; b=v2;`。有趣的是，如果设置了一个空名称的 cookie，这允许对 cookies 进行操控，通过将空 cookie 设置为特定值，可能控制其他 cookies：
|
||||
```js
|
||||
function setCookie(name, value) {
|
||||
document.cookie = `${name}=${value}`
|
||||
@ -159,7 +159,7 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
|
||||
|
||||
#### Chrome Bug: Unicode Surrogate Codepoint Issue
|
||||
|
||||
在 Chrome 中，如果 Unicode 代理代码点是设置的 cookie 的一部分，`document.cookie` 会变得损坏，随后返回一个空字符串：
|
||||
在 Chrome 中，如果 Unicode 代理代码点是设置的 cookie 的一部分，`document.cookie` 将变得损坏，随后返回一个空字符串：
|
||||
```js
|
||||
document.cookie = "\ud800=meep"
|
||||
```
|
||||
@ -167,7 +167,7 @@ document.cookie = "\ud800=meep"
|
||||
|
||||
#### 由于解析问题导致的 Cookie 走私
|
||||
|
||||
（查看[原始研究](https://blog.ankursundara.com/cookie-bugs/)的更多细节）包括 Java（Jetty, TomCat, Undertow）和 Python（Zope, cherrypy, web.py, aiohttp, bottle, webob）在内的多个网络服务器，由于对过时的 RFC2965 支持，错误处理 cookie 字符串。它们将带有双引号的 cookie 值视为单个值，即使它包含分号，而分号通常应分隔键值对：
|
||||
(查看[原始研究](https://blog.ankursundara.com/cookie-bugs/)的更多细节) 一些网络服务器，包括 Java（Jetty, TomCat, Undertow）和 Python（Zope, cherrypy, web.py, aiohttp, bottle, webob），由于对过时的 RFC2965 支持，错误处理 cookie 字符串。它们将双引号括起来的 cookie 值视为单个值，即使它包含分号，而分号通常应分隔键值对：
|
||||
```
|
||||
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
```
|
||||
@ -175,30 +175,56 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
|
||||
(查看[原始研究](https://blog.ankursundara.com/cookie-bugs/)的更多细节) 服务器对 cookies 的错误解析，特别是 Undertow、Zope 以及使用 Python 的 `http.cookie.SimpleCookie` 和 `http.cookie.BaseCookie` 的服务器，创造了 cookie 注入攻击的机会。这些服务器未能正确分隔新 cookie 的开始，允许攻击者伪造 cookies：
|
||||
|
||||
- Undertow 期望在带引号的值后面立即出现一个新 cookie，而没有分号。
|
||||
- Undertow 期望在带引号的值后立即出现新 cookie，而不需要分号。
|
||||
- Zope 寻找逗号以开始解析下一个 cookie。
|
||||
- Python 的 cookie 类在空格字符上开始解析。
|
||||
|
||||
这种漏洞在依赖基于 cookie 的 CSRF 保护的 web 应用程序中尤其危险，因为它允许攻击者注入伪造的 CSRF-token cookies，可能绕过安全措施。这个问题因 Python 对重复 cookie 名称的处理而加剧，最后一个出现的名称会覆盖之前的名称。它还引发了对不安全上下文中 `__Secure-` 和 `__Host-` cookies 的担忧，并可能导致在将 cookies 传递给易受伪造影响的后端服务器时绕过授权。
|
||||
这种漏洞在依赖基于 cookie 的 CSRF 保护的 web 应用程序中尤其危险，因为它允许攻击者注入伪造的 CSRF-token cookies，可能绕过安全措施。这个问题因 Python 对重复 cookie 名称的处理而加剧，最后一个出现的名称会覆盖之前的名称。它还引发了对不安全上下文中 `__Secure-` 和 `__Host-` cookies 的担忧，并可能导致在将 cookies 传递给易受伪造影响的后端服务器时发生授权绕过。
|
||||
|
||||
### Cookies $version and WAF bypasses
|
||||
### Cookies $version
|
||||
|
||||
#### WAF Bypass
|
||||
|
||||
根据[**这篇博客**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)，可能可以使用 cookie 属性 **`$Version=1`** 使后端使用旧逻辑解析 cookie，原因是 **RFC2109**。此外，其他值如 **`$Domain`** 和 **`$Path`** 可以用来修改后端对 cookie 的行为。
|
||||
|
||||
#### Bypassing value analysis with quoted-string encoding
|
||||
#### Cookie Sandwich Attack
|
||||
|
||||
这种解析指示在 cookies 内部取消转义的值，因此 "\a" 变为 "a"。这对于绕过 WAFS 很有用，因为：
|
||||
根据[**这篇博客**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique)，可以使用 cookie 三明治技术来窃取 HttpOnly cookies。以下是要求和步骤：
|
||||
|
||||
- 找到一个明显无用的 **cookie 在响应中被反射** 的地方
|
||||
- **创建一个名为 `$Version`** 的 cookie，值为 `1`（你可以在 JS 的 XSS 攻击中做到这一点），并使用更具体的路径以获取初始位置（一些框架如 Python 不需要这一步）
|
||||
- **创建被反射的 cookie**，其值留有 **开放的双引号**，并使用特定路径以便在 cookie 数据库中位于前一个 cookie (`$Version`) 之后
|
||||
- 然后，合法的 cookie 将按顺序排在后面
|
||||
- **创建一个虚拟 cookie 来关闭双引号** 在其值中
|
||||
|
||||
这样，受害者的 cookie 就会被困在新的 cookie 版本 1 中，并将在每次反射时被反射。
|
||||
例如，来自帖子：
|
||||
```javascript
|
||||
document.cookie = `$Version=1;`;
|
||||
document.cookie = `param1="start`;
|
||||
// any cookies inside the sandwich will be placed into param1 value server-side
|
||||
document.cookie = `param2=end";`;
|
||||
```
|
||||
### WAF 绕过
|
||||
|
||||
#### Cookies $version
|
||||
|
||||
查看上一节。
|
||||
|
||||
#### 使用引号字符串编码绕过值分析
|
||||
|
||||
此解析指示在 cookies 内部取消转义已转义的值，因此 "\a" 变为 "a"。这对于绕过 WAFS 很有用，例如：
|
||||
|
||||
- `eval('test') => forbidden`
|
||||
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`
|
||||
|
||||
#### Bypassing cookie-name blocklists
|
||||
#### 绕过 cookie 名称黑名单
|
||||
|
||||
在 RFC2109 中指出 **逗号可以用作 cookie 值之间的分隔符**。而且在等号前后也可以添加 **空格和制表符**。因此，像 `$Version=1; foo=bar, abc = qux` 的 cookie 不会生成 cookie `"foo":"bar, admin = qux"`，而是生成 cookies `foo":"bar"` 和 `"admin":"qux"`。注意生成了 2 个 cookies，以及 admin 在等号前后去掉了空格。
|
||||
在 RFC2109 中指出 **逗号可以用作 cookie 值之间的分隔符**。并且在等号前后也可以添加 **空格和制表符**。因此，像 `$Version=1; foo=bar, abc = qux` 的 cookie 不会生成 cookie `"foo":"bar, admin = qux"`，而是生成 cookies `foo":"bar"` 和 `"admin":"qux"`。注意生成了 2 个 cookies，以及 admin 在等号前后去掉了空格。
|
||||
|
||||
#### Bypassing value analysis with cookie splitting
|
||||
#### 使用 cookie 拆分绕过值分析
|
||||
|
||||
最后，不同的后门会将不同的 cookies 连接成一个字符串，传递在不同的 cookie 头中，如：
|
||||
最后，不同的后门会将不同的 cookie 头中传递的不同 cookies 连接成一个字符串，如下所示：
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
@ -212,7 +238,7 @@ Cookie: comment')
|
||||
|
||||
Resulting cookie: name=eval('test//, comment') => allowed
|
||||
```
|
||||
### 额外脆弱的 Cookie 检查
|
||||
### 额外的易受攻击的 Cookie 检查
|
||||
|
||||
#### **基本检查**
|
||||
|
||||
@ -221,18 +247,18 @@ Resulting cookie: name=eval('test//, comment') => allowed
|
||||
- 尝试在 2 个设备（或浏览器）上使用相同的 cookie 登录同一账户。
|
||||
- 检查 cookie 中是否有任何信息并尝试修改它。
|
||||
- 尝试创建多个几乎相同用户名的账户，并检查是否可以看到相似之处。
|
||||
- 检查是否存在 "**记住我**" 选项以了解其工作原理。如果存在且可能存在漏洞，请始终使用 "**记住我**" 的 cookie，而不使用其他 cookie。
|
||||
- 检查是否存在 "**记住我**" 选项以查看其工作原理。如果存在且可能存在漏洞，请始终使用 "**记住我**" 的 cookie，而不使用其他 cookie。
|
||||
- 检查即使在更改密码后，之前的 cookie 是否仍然有效。
|
||||
|
||||
#### **高级 cookie 攻击**
|
||||
|
||||
如果在登录时 cookie 保持不变（或几乎不变），这可能意味着该 cookie 与您账户的某个字段相关（可能是用户名）。然后您可以：
|
||||
|
||||
- 尝试创建许多用户名非常 **相似** 的 **账户**，并尝试 **猜测** 算法的工作原理。
|
||||
- 尝试创建许多非常 **相似** 的用户名的 **账户**，并尝试 **猜测** 算法的工作原理。
|
||||
- 尝试 **暴力破解用户名**。如果 cookie 仅作为您用户名的身份验证方法保存，那么您可以创建一个用户名为 "**Bmin**" 的账户，并 **暴力破解** 您的 cookie 的每一个 **位**，因为您尝试的其中一个 cookie 将是属于 "**admin**" 的。
|
||||
- 尝试 **填充** **Oracle**（您可以解密 cookie 的内容）。使用 **padbuster**。
|
||||
- 尝试 **Padding** **Oracle**（您可以解密 cookie 的内容）。使用 **padbuster**。
|
||||
|
||||
**填充 Oracle - Padbuster 示例**
|
||||
**Padding Oracle - Padbuster 示例**
|
||||
```bash
|
||||
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
|
||||
# When cookies and regular Base64
|
||||
@ -254,26 +280,26 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB
|
||||
|
||||
**CBC-MAC**
|
||||
|
||||
也许一个 cookie 可能有某个值，并且可以使用 CBC 签名。然后，值的完整性是通过使用相同值的 CBC 创建的签名。由于建议使用空向量作为 IV，这种完整性检查可能会存在漏洞。
|
||||
也许一个 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** 的有效签名)
|
||||
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**
|
||||
|
||||
如果 cookie 使用 ECB 加密，则可能存在漏洞。\
|
||||
当你登录时，接收到的 cookie 必须始终相同。
|
||||
如果 cookie 使用 ECB 加密，则可能会受到攻击。\
|
||||
当您登录时，您收到的 cookie 必须始终相同。
|
||||
|
||||
**如何检测和攻击：**
|
||||
|
||||
创建 2 个几乎相同数据的用户（用户名、密码、电子邮件等），并尝试发现给定 cookie 中的某些模式。
|
||||
|
||||
创建一个名为 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" 的用户，并检查 cookie 中是否存在任何模式（由于 ECB 使用相同的密钥加密每个块，如果用户名被加密，则相同的加密字节可能会出现）。
|
||||
创建一个名为 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" 的用户，并检查 cookie 中是否有任何模式（由于 ECB 使用相同的密钥加密每个块，如果用户名被加密，则相同的加密字节可能会出现）。
|
||||
|
||||
应该有一个模式（与使用的块的大小相同）。因此，知道一堆 "a" 是如何加密的，你可以创建一个用户名："a"*(块的大小)+"admin"。然后，你可以从 cookie 中删除一个块的 "a" 的加密模式。你将拥有用户名 "admin" 的 cookie。
|
||||
应该有一个模式（与使用的块的大小相同）。因此，知道一堆 "a" 是如何加密的，您可以创建一个用户名： "a"*(块的大小)+"admin"。然后，您可以从 cookie 中删除一个块的 "a" 的加密模式。您将拥有用户名 "admin" 的 cookie。
|
||||
|
||||
## 参考
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user