Question

As a bug bounty hunter, I find open redirects in almost all the web targets I attack. Why are open redirects still so prevalent in web applications today? Sites prevent open redirects by validating the URL used to redirect the user, making the root cause of open redirects failed URL validation. And, unfortunately, URL validation is extremely difficult to get right.

作为一名漏洞赏金猎人，我发现几乎所有我攻击的网络目标都存在开放式重定向。为什么开放式重定向今天在网络应用程序中仍然如此普遍？站点通过验证用于重定向用户的 URL 来防止开放式重定向，使开放式重定向的根本原因是 URL 验证失败。不幸的是，URL 验证非常难以正确完成。

Here, you can see the components of a URL. The way the browser redirects the user depends on how the browser differentiates between these components:

这里，您可以看到 URL 的组成部分。浏览器重定向用户的方式取决于浏览器如何区分这些组件：

scheme://userinfo@hostname:port/path?query#fragment

The URL validator needs to predict how the browser will redirect the user and reject URLs that will result in a redirect offsite. Browsers redirect users to the location indicated by the hostname section of the URL. However, URLs don’t always follow the strict format shown in this example. They can be malformed, have their components out of order, contain characters that the browser does not know how to decode, or have extra or missing components. For example, how would the browser redirect this URL?

URL 验证器需要预测浏览器将如何重定向用户，并拒绝会导致重定向到站外的 URL。浏览器将用户重定向到 URL 的主机名部分指示的位置。然而，URL 并不总是遵循本示例中显示的严格格式。它们可能格式错误，组件排序不当，包含浏览器不知道如何解码的字符，或者有额外或缺失的组件。例如，浏览器将如何重定向此 URL？

https://user:password:8080/example.com@attacker.com

请帮我翻译`https://user:password:8080/example.com@attacker.com`为简体中文，只需返回翻译内容，不包括原始文本。 用户：密码：8080/example.com@attacker.com

When you visit this link in different browsers, you will see that different browsers handle this URL differently. Sometimes validators don’t account for all the edge cases that can cause the browser to behave unexpectedly. In this case, you could try to bypass the protection by using a few strategies, which I’ll go over in this section.

当您在不同的浏览器中访问此链接时，您会发现不同的浏览器会以不同的方式处理此 URL。有时，验证器无法考虑到所有可能导致浏览器表现异常的边缘案例。在这种情况下，您可以尝试使用一些策略来绕过保护，我将在本节中介绍。

Using Browser Autocorrect

First, you can use browser autocorrect features to construct alternative URLs that redirect offsite. Modern browsers often autocorrect URLs that don’t have the correct components, in order to correct mangled URLs caused by user typos. For example, Chrome will interpret all of these URLs as pointing to https://attacker.com :

首先，您可以使用浏览器自动更正功能来构造可重定向到外部网站的替代 URL。现代浏览器通常会自动更正没有正确组件的 URL，以纠正用户打字错误等导致的 URL 混淆问题。例如，Chrome 将将所有这些 URL 解释为指向 https://attacker.com。

https:attacker.com
https;attacker.com
https:\/\/attacker.com
https:/\/\attacker.com

These quirks can help you bypass URL validation based on a blocklist. For example, if the validator rejects any redirect URL that contains the strings https:// or http:// , you can use an alternative string, like https; , to achieve the same results.

这些小技巧可以帮助您绕过基于黑名单的 URL 验证。例如，如果验证器拒绝包含字符串 https://或 http://的任何重定向 URL，您可以使用另一种字符串（如 https;），以达到相同的效果。

Most modern browsers also automatically correct backslashes (\) to forward slashes (/), meaning they’ll treat these URLs as the same:

大多数现代浏览器还会自动将反斜杠符号（\）校正为正斜杠符号（/），这意味着它们将视这些 URL 为相同的内容：

https:\\example.com
https://example.com

If the validator doesn’t recognize this behavior, the inconsistency could lead to bugs. For example, the following URL is potentially problematic:

如果验证器无法识别这种行为，不一致性可能会导致错误。例如，以下 URL 可能存在问题：

https://attacker.com\@example.com

Unless the validator treats the backslash as a path separator, it will interpret the hostname to be example.com , and treat attacker.com\ as the username portion of the URL. But if the browser autocorrects the backslash to a forward slash, it will redirect the user to attacker.com , and treat @example.com as the path portion of the URL, forming the following valid URL:

如果验证器不把反斜杠当作路径分隔符，它将把主机名解释为 example.com，将 attacker.com\视为 URL 的用户名部分。但是如果浏览器自动纠正反斜杠为正斜杠，它将重定向用户到 attacker.com，并将 @example.com 视为 URL 的路径部分，形成以下有效的 URL：

https://attacker.com/@example.com

Exploiting Flawed Validator Logic

Another way you can bypass the open-redirect validator is by exploiting loopholes in the validator’s logic. For example, as a common defense against open redirects, the URL validator often checks if the redirect URL starts with, contains, or ends with the site’s domain name. You can bypass this type of protection by creating a subdomain or directory with the target’s domain name:

你可以通过利用验证器逻辑中的漏洞来绕过开放重定向验证器。例如，作为针对开放重定向的常见防御策略，URL 验证器经常检查重定向 URL 是否以、包含或以站点的域名结尾。你可以通过创建带有目标域名的子域或目录来绕过这种保护：

https://example.com/login?redir=    http://example.com.attacker.com 
https://example.com/login?redir=    http://attacker.com/example.com

To prevent attacks like these from succeeding, the validator might accept only URLs that both start and end with a domain listed on the allowlist. However, it’s possible to construct a URL that satisfies both of these rules. Take a look at this one:

为了防止这样的攻击成功，验证器可能只接受以白名单中列出的域名开头和结尾的 URL。然而，有可能构造出一条同时满足这两个规则的 URL。看看这个例子：

https://example.com/login?redir=    https://example.com.attacker.com/example.com

This URL redirects to attacker.com , despite beginning and ending with the target domain. The browser will interpret the first example.com as the subdomain name and the second one as the filepath.

这个 URL 重定向到 attacker.com，尽管它以目标域名开头和结尾。浏览器会将第一个 example.com 解释为子域名，第二个 example.com 解释为文件路径。

Or you could use the at symbol ( @ ) to make the first example.com the username portion of the URL:

或者你可以使用“ @ ”符号将第一个 example.com 作为 URL 的用户名部分：

https://example.com/login?redir=    https://example.com@attacker.com/example.com

Custom-built URL validators are prone to attacks like these, because developers often don’t consider all edge cases.

自定义的 URL 验证器容易受到此类攻击，因为开发人员通常无法考虑所有边缘情况。

Using Data URLs

You can also manipulate the scheme portion of the URL to fool the validator. As mentioned in Chapter 6 , data URLs use the data: scheme to embed small files in a URL. They are constructed in this format:

你也可以操纵 URL 的 scheme 部分以愚弄验证器。如第 6 章所述，数据 URL 使用 data: scheme 将小文件嵌入 URL 中。它们采用以下格式构建：

data:MEDIA_TYPE[;base64],DATA

For example, you can send a plaintext message with the data scheme like this:

例如，你可以通过类似以下的数据方案发送纯文本消息：

data:text/plain,hello!

The optional base64 specification allows you to send base64-encoded messages. For example, this is the base64-encoded version of the preceding message:

可选的 base64 规范允许您发送 base64 编码的消息。例如，这是前面信息的 base64 编码版本：

data:text/plain;base64,aGVsbG8h

You can use the data: scheme to construct a base64-encoded redirect URL that evades the validator. For example, this URL will redirect to example.com :

你可以使用 data：方案构造一个 base64 编码的重定向 URL，这样就可以回避验证器。例如，此 URL 将重定向到 example.com：

data:text/html;base64,
PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9leGFtcGxlLmNvbSI8L3NjcmlwdD4=

The data encoded in this URL, PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9leGFtcGxlLmNvbSI8L3NjcmlwdD4= , is the base64-encoded version of this script:

该 URL 中编码的数据 PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9leGFtcGxlLmNvbSI8L3NjcmlwdD4=，是这个脚本的 base64 编码版本：

<script>location="https://example.com"</script>

This is a piece of JavaScript code wrapped between HTML <script> tags. It sets the location of the browser to https://example.com , forcing the browser to redirect there. You can insert this data URL into the redirection parameter to bypass blocklists:

这是被包裹在 HTML 的 <script> 标签之间的 JavaScript 代码。它将浏览器的位置设置为 https://example.com，强制浏览器进行重定向到该网址。你可以将这个数据 URL 插入到重定向参数中，以绕过阻止列表。

https://example.com/login?redir=data:text/html;base64,
PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9leGFtcGxlLmNvbSI8L3NjcmlwdD4=

Exploiting URL Decoding

URLs sent over the internet can contain only ASCII characters , which include a set of characters commonly used in the English language and a few special characters. But since URLs often need to contain special characters or characters from other languages, people encode characters by using URL encoding. URL encoding converts a character into a percentage sign, followed by two hex digits; for example, %2f . This is the URL-encoded version of the slash character ( / ).

通过互联网发送的 URL 只能包含 ASCII 字符，其中包括英语中常用的一组字符和一些特殊字符。但是由于 URL 通常需要包含特殊字符或其他语言的字符，人们通过使用 URL 编码来对字符进行编码。URL 编码将字符转换为百分号，后跟两个十六进制数字；例如，% 2f。这是斜杠字符（/）的 URL 编码版本。

When validators validate URLs, or when browsers redirect users, they have to first find out what is contained in the URL by decoding any characters that are URL encoded. If there is any inconsistency between how the validator and browsers decode URLs, you could exploit that to your advantage.

当验证程序验证 URL 或浏览器重定向用户时，它们必须首先解码 URL 编码的任何字符以了解 URL 中包含的内容。如果验证程序和浏览器如何解码 URL 存在任何不一致之处，您可以利用这一点为自己谋取利益。

Double Encoding

First, try to double- or triple-URL-encode certain special characters in your payload. For example, you could URL-encode the slash character in https://example.com/@attacker.com . Here is the URL with a URL-encoded slash:

首先，尝试将负载中的某些特殊字符进行双倍或三倍 URL 编码。例如，您可以对 https://example.com/@attacker.com 中的斜杠字符进行 URL 编码。这是具有 URL 编码斜杠的 URL：

https://example.com%2f@attacker.com

And here is the URL with a double-URL-encoded slash:

这是一个使用双 URL 编码斜杠的 URL 地址：

https://example.com%252f@attacker.com

Finally, here is the URL with a triple-URL-encoded slash:

最后，这是一个经过三次 URL 编码的斜线的 URL：

https://example.com%25252f@attacker.com

Whenever a mismatch exists between how the validator and the browser decode these special characters, you can exploit the mismatch to induce an open redirect. For example, some validators might decode these URLs completely, then assume the URL redirects to example.com , since @attacker.com is in the path portion of the URL. However, the browsers might decode the URL incompletely, and instead treat example.com%25252f as the username portion of the URL.

每当验证器和浏览器在解码这些特殊字符方面存在不匹配时，您就可以利用不匹配来引导一个开放重定向。例如，某些验证器可能会完全解码这些 URL，然后假定该 URL 重定向到 example.com，因为 @attacker.com 在 URL 的路径部分。但是，浏览器可能会不完全解码 URL，而是将 example.com%25252f 作为 URL 的用户名部分处理。

On the other hand, if the validator doesn’t double-decode URLs, but the browser does, you can use a payload like this one:

另一方面，如果验证器不会双重解码 URL，但浏览器会，您可以使用像这样的有效载荷：

https://attacker.com%252f@example.com

The validator would see example.com as the hostname. But the browser would redirect to attacker.com , because @example.com becomes the path portion of the URL, like this:

验证器会将 example.com 视为主机名。但是浏览器会重定向到 attacker.com，因为 @example.com 变成了 URL 的路径部分，就像这样：

https://attacker.com/@example.com

Non-ASCII Characters

You can sometimes exploit inconsistencies in the way the validator and browsers decode non-ASCII characters. For example, let’s say that this URL has passed URL validation:

有时候，你可以利用验证器和浏览器解码非 ASCII 字符时出现的不一致性。例如，假设这个 URL 通过了 URL 验证：

https://attacker.com%ff.example.com

%ff is the character ÿ , which is a non-ASCII character. The validator has determined that example.com is the domain name, and attacker.comÿ is the subdomain name. Several scenarios could happen. Sometimes browsers decode non-ASCII characters into question marks. In this case, example.com would become part of the URL query, not the hostname, and the browser would navigate to attacker.com instead:

%ff 是字符ÿ，它是一个非 ASCII 字符。验证器已确定 example.com 是域名，attacker.comÿ是子域名。可能会发生几种情况。有时浏览器会将非 ASCII 字符解码为问号。在这种情况下，example.com 将成为 URL 查询的一部分，而不是主机名，浏览器将导航到 attacker.com。

https://attacker.com?.example.com

Another common scenario is that browsers will attempt to find a “most alike” character. For example, if the character ╱ ( %E2%95%B1 ) appears in a URL like this, the validator might determine that the hostname is example.com :

另一个常见的情景是浏览器会尝试找到“最相似”的字符。例如，如果像这样的字符╱(%E2%95%B1) 出现在 URL 中，验证器可能会确定主机名为 example.com。

https://attacker.com╱.example.com

But the browser converts the slash look-alike character into an actual slash, making attacker.com the hostname instead:

但是，浏览器将类似斜杠的字符转换为实际的斜杠，使攻击者.com 成为主机名。

https://attacker.com/.example.com

Browsers normalize URLs this way often in an attempt to be user-friendly. In addition to similar symbols, you can use character sets in other languages to bypass filters. The Unicode standard is a set of codes developed to represent all of the world’s languages on the computer. You can find a list of Unicode characters at http://www.unicode.org/charts/ . Use the Unicode chart to find look-alike characters and insert them in URLs to bypass filters. The Cyrillic character set is especially useful since it contains many characters similar to ASCII characters.

浏览器经常以这种方式规范化 URL，试图使其更加用户友好。除了类似的符号外，您还可以使用其他语言的字符集来绕过过滤器。 Unicode 标准是一组代码，旨在在计算机上表示世界上所有的语言。您可以在 http://www.unicode.org/charts/上找到 Unicode 字符的列表。使用 Unicode 图表查找类似的字符并将它们插入 URL 以绕过过滤器。 Cyrillic 字符集特别有用，因为它包含许多与 ASCII 字符相似的字符。

Combining Exploit Techniques

To defeat more-sophisticated URL validators, combine multiple strategies to bypass layered defenses. I’ve found the following payload to be useful:

为了击败更复杂的 URL 验证器，结合多种策略绕过分层防御。我发现以下有效负载非常有用：

https://example.com%252f@attacker.com/example.com

This URL bypasses protection that checks only that a URL contains, starts with, or ends with an allowlisted hostname by making the URL both start and end with example.com . Most browsers will interpret example.com%252f as the username portion of the URL. But if the validator over-decodes the URL, it will confuse example.com as the hostname portion:

该 URL 绕过保护，只检查 URL 是包含、以、或以白名单主机名结尾，方法是使 URL 同时以 example.com 开头和结尾。大多数浏览器将解释 example.com%252f 作为 URL 的用户名部分。但如果验证器过度解码 URL，则会将 example.com 混淆为主机名部分：

https://example.com/@attacker.com/example.com

You can use many more methods to defeat URL validators. In this section, I’ve provided an overview of the most common ones. Try each of them to check for weaknesses in the validator you are testing. If you have time, experiment with URLs to invent new ways of bypassing URL validators. For example, try inserting random non-ASCII characters into a URL, or intentionally messing up its different components, and see how browsers interpret it.

你可以使用更多方法来打败 URL 验证器。在本节中，我提供了最常见的综述。尝试每种方法以检查您正在测试的验证器中的弱点。如果您有时间，请尝试使用 URL 来发明绕过 URL 验证器的新方法。例如，尝试在 URL 中插入随机的非 ASCII 字符，或故意弄乱其不同的组件， 看看浏览器如何解析它。