【问题标题】:Is it safe to redirect to an url like so: "https://example.com/" + userData?重定向到这样的网址是否安全:“https://example.com/”+ userData?
【发布时间】:2019-07-22 14:48:54
【问题描述】:

重定向到我自己域中的 url 时,我可以安全地使用用户数据吗?

假设我拥有example.com。如果我的应用程序的正常使用有时需要我将用户重定向到这样的网址,可以吗?

https://example.com/ + userData

无论如何这可以用来进行漏洞利用,例如运行 javascript 吗?或重定向到一些完全不同的域?

出于本次讨论的目的,我想:

  • 忽略目录遍历攻击
  • 只考虑影响浏览器(而不是 example.com 服务器)的攻击

您可以假设我根本没有对从用户那里收到的参数进行编码。

编辑:澄清 - userData 无论如何都不会添加到页面中 - 它只驻留在网址本身中。

【问题讨论】:

  • 除了使用伪协议javascript: 的URL 开始,我不知道有任何其他方法可以让JavaScript 代码直接从地址栏执行。
  • 我同意,并且我自己还没有看到任何可能发生这种情况的方法。我问这个问题是因为前几天我正在和一个非常聪明的安全人员交谈,他认为这可能是 javascript 的一个漏洞利用点,但我从未得到具体细节,并认为我会尝试在这里询问以了解更多信息。希望这里没有漏洞!

标签: http-redirect exploit


【解决方案1】:

正如comments 中提到的,这种情况似乎无法使用javascript:(或data:,也可用于执行JavaScript)伪协议进行利用。但是,如果example.com 在自定义 404 页面上输出 userData,则可能会执行反射型 XSS 攻击。让我们假设此页面显示一条错误消息:

<h1>Page 'userData' not found.</h1>

在这种情况下,如果攻击者提交了一个 JavaScript 有效载荷(例如:&lt;script&gt;alert('xss');&lt;/script&gt;),它将在页面上呈现,

<h1>Page '<script>alert('xss');</script>' not found.</h1>  

并且代码可以由访问者执行。通过过滤用户数据可以防止这种攻击——无论如何,用户输入都应该被清理。

开放重定向漏洞利用似乎不太可能,因为用户输入附加到域,并且利用尝试应该导致 404 响应。当然,如果还有其他允许任何重定向的本地页面,那么攻击者可以在其有效负载中使用它们,例如:

vulnerable/page?url=http://attacker.com

请注意,仅仅因为我无法确认漏洞利用并不意味着代码没有漏洞,具体取决于服务器配置。我们可以通过基于有效和受信任位置列表过滤用户数据来防止开放重定向攻击。这也可能有助于针对服务器的其他几种攻击,例如目录遍历、文件包含和服务器端请求伪造攻击。

【讨论】:

  • 感谢您的反馈-您是正确的,如果将内容呈现到页面上,将会受到注入攻击,但它实际上并没有在页面中使用-我会在上面的编辑中澄清这一点。至于重定向,我们的应用程序中没有任何地方允许从查询字符串参数进行重定向,但我担心的是 https://example.com/http://www.badsite.comhttps://example.com/javascript:alert(1) 之类的东西 - 尽管我也不相信这可以用来进行漏洞利用,我想知道是否存在我不知道的情况。
  • 我也看不出有什么方法可以利用它,但这并不意味着拥有更多经验或信息的黑客无法利用它。您可以使用 this list 中的项目进行测试,以消除最常见的 Open Redirect 负载。
  • 嗨@t.m.adam,这是我为寻找任何解决方案而创建的latest post。谢谢。
【解决方案2】:
  1. 这可能是网络钓鱼攻击的重点

攻击者可能会伪装成来自您网站的邮件发送电子邮件并注入类似的链接(我假设“jumper.php”是一个带有目标 url 的单个 url 参数的页面,可能包含用户数据):

要验证您的帐户,请点击此链接: http://example.com/jumper.php?url=http%3A%2F%2Fexample-my.com

在这种情况下,用户将在邮件中看到以http://example.com 开头的链接,并可能认为这是指向您网站的有效链接,但实际上他将被重定向到可能被攻击者控制的http://example-my.com(看起来很像您的网站)。

  1. 在某些情况下,人们使用 javascript 进行重定向

如果页面包含这样的代码(php 示例):

<script>location.replace(<?= json_encode($userData) ?>);</script>

然后,即使变量被正确清理,攻击者也可以在http://example.com 的上下文中执行任意javascript 代码,并重定向到javascript:...。例如:

要验证您的帐户,请点击此链接: 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 代码来做更多的事情。

【讨论】:

  • 我认为唯一可行的方法是如果我的服务器 http://example.com 重定向到它在域之后的任何内容,对吗?在服务器上,我的意思是?如果是这样,我不会接受这个漏洞利用,因为我们不支持这样的重定向......
  • 这取决于重定向是如何完成的。如果是类似的东西(php 示例):header("Location: ".$userData); 该站点可以被列为第 1 点的漏洞利用(因为userData 可能包含绝对 URL)。
  • 了解 - 但我们的重定向确实确保不允许任何绝对值,因此在 userData 参数的开头没有 httpjavascript://。当我说假设我们不编码时,我并不是说我们不进行消毒/健全性检查......好点
【解决方案3】:

假设重定向代码是通过添加看起来像这样(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 库(包括从 5.1.4 AFAIK 开始的 php)可以防止这种header injection 攻击并会产生错误,但一些旧工具可能容易受到攻击。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-06-21
    • 2015-09-25
    • 1970-01-01
    • 2020-09-24
    • 1970-01-01
    • 2021-01-01
    • 2015-05-21
    相关资源
    最近更新 更多