像这样重定向到 url 是否安全："https://example.com/" + userData？
Is it safe to redirect to an url like so: "https://example.com/" + userData?
重定向到我自己域中的 url 时，我可以安全地使用用户数据吗？
假设我拥有 example.com。如果我的应用程序的正常使用有时需要我像这样将用户重定向到 urls，这样可以吗？
https://example.com/ + userData
有没有这可以用来做漏洞利用，例如运行 javascript？或重定向到一些完全不同的域？
出于本次讨论的目的，我想：
- 忽略目录遍历攻击
- 只考虑影响浏览器（不是 example.com 服务器）的攻击
你可以假设我根本没有对从用户那里收到的参数进行编码。
编辑：澄清 - userData 无论如何都没有添加到页面 - 它只存在于 url 本身。
如 中所述，此方案似乎无法通过 javascript:（或 data:，也可用于执行 JavaScript ) 伪协议。但是，如果 example.com 在自定义 404 页面上输出 userData，则可能会执行反射 XSS 攻击。假设此页面显示一条错误消息：
<h1>Page 'userData' not found.</h1>
在这种情况下，如果攻击者提交了一个JavaScript有效载荷（例如：<script>alert('xss');</script>），它将在页面上呈现，
<h1>Page '<script>alert('xss');</script>' not found.</h1>
代码可能会被访问者执行。这种攻击可以通过过滤用户数据来防止——用户输入无论如何都应该被清理。
开放重定向攻击似乎不太可能，因为用户输入附加到域，攻击尝试应该导致 404 响应。当然，如果有其他本地页面允许任何重定向，则攻击者可以在其有效负载中使用它们，例如：
vulnerable/page?url=http://attacker.com
请注意，我无法确认漏洞利用并不意味着代码不易受攻击，具体取决于服务器配置。我们可以根据有效且受信任的位置列表过滤用户数据，从而防止开放重定向攻击。这也可能有助于针对服务器的其他几种攻击，例如目录遍历、文件包含和服务器端请求伪造攻击。
- 这可能是网络钓鱼攻击的点
攻击者可能会伪装成来自您站点的邮件发送电子邮件并注入 link 类似内容（我假设“jumper.php”是一个具有单个 url 参数且目标为 url，可能包含用户数据）：
要验证您的帐户，请按照此 link:
http://example.com/jumper.php?url=http%3A%2F%2Fexample-my.com
在这种情况下，用户将在邮件中看到 link 以 http://example.com 开头，并可能认为这对您的站点有效 link，但实际上他将被重定向到http://example-my.com 可能被攻击者控制（看起来很像您的网站）。
- 在某些情况下，人们使用 javascript 进行重定向
如果页面包含这样的代码（php 示例）：
<script>location.replace(<?= json_encode($userData) ?>);</script>
然后，即使变量被正确清理，攻击者也可以在 http://example.com 的上下文中执行任意 javascript 代码并重定向到 javascript:...。例如：
要验证您的帐户，请按照此 link:
http://example.com/jumper.php?url=javascript%3Aalert%28document.cookie%29
在这种情况下，重定向将转换为
<script>location.replace("javascript:alert(document.cookie)");</script>
和代码 javascript:alert(document.cookie)（例如）将在 http://example.com 的上下文中执行。当然，攻击者可能会通过注入任意 javascript code 代码来做更糟糕的事情。
假设重定向代码是通过添加如下所示（php 示例）完成的：header("Location: http://example.com/".$userData);
由于$userData没有以任何方式编码，实际上攻击者可能获得对服务器生成的http响应的访问权。例如 $userData 可能包含类似的内容：
"somepage.php\r\nattacker-header:some value\r\n\r\nattacker page body with JavaScript"
虽然大多数 http 库（包括 php 从 5.1.4 AFAIK 开始）防止这种 header injection 攻击并会产生错误，但一些旧工具可能容易受到攻击。
重定向到我自己域中的 url 时，我可以安全地使用用户数据吗？
假设我拥有 example.com。如果我的应用程序的正常使用有时需要我像这样将用户重定向到 urls，这样可以吗？
https://example.com/ + userData
有没有这可以用来做漏洞利用，例如运行 javascript？或重定向到一些完全不同的域？
出于本次讨论的目的，我想：
- 忽略目录遍历攻击
- 只考虑影响浏览器（不是 example.com 服务器）的攻击
你可以假设我根本没有对从用户那里收到的参数进行编码。
编辑：澄清 - userData 无论如何都没有添加到页面 - 它只存在于 url 本身。
如 javascript:（或 data:，也可用于执行 JavaScript ) 伪协议。但是，如果 example.com 在自定义 404 页面上输出 userData，则可能会执行反射 XSS 攻击。假设此页面显示一条错误消息：
<h1>Page 'userData' not found.</h1>
在这种情况下，如果攻击者提交了一个JavaScript有效载荷（例如：<script>alert('xss');</script>），它将在页面上呈现，
<h1>Page '<script>alert('xss');</script>' not found.</h1>
代码可能会被访问者执行。这种攻击可以通过过滤用户数据来防止——用户输入无论如何都应该被清理。
开放重定向攻击似乎不太可能，因为用户输入附加到域，攻击尝试应该导致 404 响应。当然，如果有其他本地页面允许任何重定向，则攻击者可以在其有效负载中使用它们，例如：
vulnerable/page?url=http://attacker.com
请注意，我无法确认漏洞利用并不意味着代码不易受攻击，具体取决于服务器配置。我们可以根据有效且受信任的位置列表过滤用户数据，从而防止开放重定向攻击。这也可能有助于针对服务器的其他几种攻击，例如目录遍历、文件包含和服务器端请求伪造攻击。
- 这可能是网络钓鱼攻击的点
攻击者可能会伪装成来自您站点的邮件发送电子邮件并注入 link 类似内容（我假设“jumper.php”是一个具有单个 url 参数且目标为 url，可能包含用户数据）：
要验证您的帐户，请按照此 link:
http://example.com/jumper.php?url=http%3A%2F%2Fexample-my.com
在这种情况下，用户将在邮件中看到 link 以 http://example.com 开头，并可能认为这对您的站点有效 link，但实际上他将被重定向到http://example-my.com 可能被攻击者控制（看起来很像您的网站）。
- 在某些情况下，人们使用 javascript 进行重定向
如果页面包含这样的代码（php 示例）：
<script>location.replace(<?= json_encode($userData) ?>);</script>
然后，即使变量被正确清理，攻击者也可以在 http://example.com 的上下文中执行任意 javascript 代码并重定向到 javascript:...。例如：
要验证您的帐户，请按照此 link:
http://example.com/jumper.php?url=javascript%3Aalert%28document.cookie%29
在这种情况下，重定向将转换为
<script>location.replace("javascript:alert(document.cookie)");</script>
和代码 javascript:alert(document.cookie)（例如）将在 http://example.com 的上下文中执行。当然，攻击者可能会通过注入任意 javascript code 代码来做更糟糕的事情。
假设重定向代码是通过添加如下所示（php 示例）完成的：header("Location: http://example.com/".$userData);
由于$userData没有以任何方式编码，实际上攻击者可能获得对服务器生成的http响应的访问权。例如 $userData 可能包含类似的内容：
"somepage.php\r\nattacker-header:some value\r\n\r\nattacker page body with JavaScript"
虽然大多数 http 库（包括 php 从 5.1.4 AFAIK 开始）防止这种 header injection 攻击并会产生错误，但一些旧工具可能容易受到攻击。