ALLOWED_HOSTS 防御的漏洞是什么? [英] What is the vulnerability ALLOWED_HOSTS is defending against?

问题描述

该示例来自 Python Django 框架，但适用于所有 Web 应用程序.ALLOWED_HOSTS 设置保护您的站点和用户，即如果 ALLOWED_HOSTS 设置为 "*" 恶意用户将如何使用指向恶意主机的链接来毒害缓存和密码重置电子邮件"?

The example is from the Python Django framework but is applicable to all web applications. How does the ALLOWED_HOSTS setting protect your site and users, i.e. if ALLOWED_HOSTS was set to "*" how would a malicious user go about "poisoning caches and password reset emails with links to malicious hosts"?

ALLOWED_HOSTS 默认值:[](空列表)

ALLOWED_HOSTS Default: [] (Empty list)

代表这个 Django 的主机/域名的字符串列表网站可以服务.这是一种安全措施，可防止攻击者中毒缓存和密码重置电子邮件与恶意链接通过使用虚假的 HTTP Host 标头提交请求，即即使在许多看似安全的网络服务器配置下也是可能的.

A list of strings representing the host/domain names that this Django site can serve. This is a security measure to prevent an attacker from poisoning caches and password reset emails with links to malicious hosts by submitting requests with a fake HTTP Host header, which is possible even under many seemingly-safe web server configurations.

此列表中的值可以是完全限定名称(例如'www.example.com')，在这种情况下，它们将与请求的主机头完全一致(不区分大小写，不包括端口).以句点开头的值可以用作子域通配符:'.example.com' 将匹配 example.com、www.example.com 和任何其他example.com 的子域.'*' 值将匹配任何内容；在这如果您有责任提供您自己的主机验证标头(可能在中间件中；如果是这样，则必须列出该中间件第一个在 MIDDLEWARE_CLASSES 中).

Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).

推荐答案

恶意用户将如何使用指向恶意主机的链接毒害缓存和密码重置电子邮件"?

how would a malicious user go about "poisoning caches and password reset emails with links to malicious hosts"?

缓存系统应该缓存来自使用特定host header 以识别 URL.例如，如果有一个对 /foo 的 GET 请求，缓存将只知道它实际上是一个对 www.example.com/foo 的请求，如果它检查主机标头(而不是简单的目标 IP).通过将 ALLOWED_HOSTS 设置保留为 "*"，如果输出页面包含反映的主机名和主机，则您允许此缓存填充垃圾(即中毒)缓存层或服务器不检查头.

A caching system should cache responses from requests sent with a particular host header in order to identify the URL. For example, if there was a GET request to /foo the cache will only know that it was in fact a request to www.example.com/foo if it checks the host header (rather than simply destination IP). By leaving the ALLOWED_HOSTS setting to "*" you are allowing this cache to be filled up with rubbish (i.e. poisoned) if the output page contains the reflected host name and the host header is not checked by the caching layer or server.

例如如果您网站上的页面输出

e.g. if a page on your site outputs

<script src="//[hostname]/script.js"></script>

如果攻击者将 attacker-site.co.uk 指向您的服务器并请求该页面，您的服务器将响应:

And if an attacker points attacker-site.co.uk to your server and requests the page, your server will respond with:

<script src="//attacker-site.co.uk/script.js"></script>

因此，用户和您的站点 (example.com) 之间的任何缓存层(例如 CDN)都会对被先前注入的主机标头污染的页面发出合法请求:

Therefore, any caching layers (e.g. CDNs) between a user and your site (example.com) will have legitimate requests for the page poisoned with the previously injected host header:

<script src="//attacker-site.co.uk/script.js"></script>

这让攻击者可以在您的域上运行他们的恶意 JavaScript，从而破坏同源策略.例如，他们可能安装了一个 JavaScript 键盘记录器来获取密码，或者安装了一个脚本来发送 DOM 的内容.

This lets the attacker run their malicious JavaScript on your domain, breaking the Same Origin Policy. For example, they may have installed a JavaScript keylogger to get passwords, or a script to send the contents of the DOM.

此外，如果主机名没有正确编码输出，那么它可以直接用于注入脚本，即使页面上不存在外部 JavaScript 标记.

In addition, if the host name is not output encoded correctly then it could be directly used to inject script, even if no external JavaScript tags exist on the page.

" /><script>alert('xss')</script>

将呈现:

<img src="//[hostname]/img.jpg" />

作为

<img src="//" /><script>alert('xss')</script>/img.jpg" />

密码重置电子邮件是一个类似的概念.假设密码重置电子邮件的模板是:

The password reset email is a similar concept. Say the template for the password reset email is:

您请求重置密码.请前往 https://[HOST]/reset?token=[TOKEN] 进行重置.

并且攻击者将他们的域 www.evil.com 指向您的服务器并请求重置用户.他们的 DNS 设置可以简单地为自己设置，使用主机文件.

and the attacker points their domain www.evil.com at your server and requests a reset for a user. Their DNS setting can simply be for themselves, using a hosts file.

然后用户将收到一封电子邮件，内容为

The user will then get an email saying

您请求重置密码.请访问 https://www.evil.com/reset?token=XYZ 以重置它.

点击链接后，由于 www.evil.com 的公共 DNS 指向攻击者的站点，攻击者将获得密码重置令牌并可以访问该帐户.

Once the link is clicked, as the public DNS for www.evil.com points at the attacker's site, the attacker gets the password reset token and can gain access to the account.

查看此链接了解更多信息有关此类攻击的详细信息.

See this link for some more detail on these type of attacks.

这篇关于ALLOWED_HOSTS 防御的漏洞是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！