URL注入在URL缩短服务中的含义

Question

我认为，由于对我的问题的严重误解，已经有上升的选票被撤回或否决了。在下面的文章中，我不关心指向包含恶意软件或漏洞的站点的URL (这不是什么问题:这根本不是这个问题的问题)：我关心URL字符串本身的注入。我不想要的是一个海盗能够逃避“任何框架”的安全，并能够注入，比如说，JavaScript代码在一个网址，然后我会显示给其他用户。换句话说:我正在寻找一个额外的措施来降低流氓JavaScript运行的风险，就像它来自我的was应用程序一样。

为了加强一个yet应用程序，我想永远不要显示用户输入的URL，但允许他们输入URL，但始终使用URL缩短服务。这并不是为了取代其他良好的安全做法，而是用于除其他安全做法之外的其他做法。

下面是一个非常简单的场景：

1. 唯一一个用户可以输入到网站的东西就是一个URL
2. 用户发送的URL被发送到外部URL缩短器服务
3. 缩短的网址然后从我的网站送达

如果在第一步中，我们认为解析器在解析用户发送的POST参数时没有缺陷，那么如果URL中有一个成功的漏洞会影响URL缩短器服务，那么以后会发生什么错误呢？

基本上，我的想法是提供一个硬编码的：

http://bit.ly/

接着是一条非常严格的规则，上面写着：“最多插入9个字符，这些字符必须是字母数字”。

为了简化用户可以发送和不能发送哪些字符的规则，我会这样做: bit.ly URL的输出比合法URL允许的要简单得多(我以bit.ly为例，在它返回的缩短URL中使用非常严格的字符子集的任何bit.ly简写服务)。

那么，最坏的情况是，如果我们认为流氓用户无法利用我的网站，但仍然设法利用URL缩短服务的缺陷？

我想更好地理解的是，当涉及到相同的来源策略/ XSS和CSRF以及其他类型的漏洞时，它意味着什么。

而且，我想，我的问题可以这样继续下去：“如果我的网站上的安全性做得正确，那么XSS利用影响URL缩短服务的漏洞是否仍然是我关心的问题？”

整个想法将是增加防御深度，并考虑到URL缩短服务可能知道如何维护自己的URL注入。

Answer 1

这取决于URL速记服务所做的工作。据推测，它接受一个输入(完整URL)并生成一个输出(较小的URL)，将从较小URL到完整URL的映射存储在数据库中。它还可以存储较小URL的散列，以提高查找效率并加快查找速度。我只是猜测，因为它的工作方式将真正取决于您的实现。但是，就组件而言，SQL可能会使用数据库来存储映射。此外，服务本身可能有权访问该数据库，以确保不会发生重复映射。如果URL服务直接使用数据库，并且执行得很差，就有可能产生SQL注入。可以通过使用参数化查询来防止SQL注入。

其次，您的URL缩短服务很容易受到DOS攻击，在这种情况下，执行的请求比它所能处理的更多。这尤其适用于写得不好并且不能快速生成唯一URL的情况。不过，我不太担心这一点，DDoS攻击可以对任何人发起。

我想你编辑你的帖子是为了表明这是一项外部速记服务。这确实改变了一些事情，因为这意味着数据库不容易受到SQL注入的攻击，而是其他人的。实际上，这种服务没有太多的风险。如果有人能够设法注入数据库或以其他方式对其进行黑客攻击，他们可能会导致用户重定向到错误的URL，这是他们用恶意代码设置的URL。此外部服务也可能对您构成威胁，因为它可以返回它想返回的任何旧URL。没有什么能迫使他们真诚地实现映射。它们可以轻松地将99%的好URL和1%的恶意URL发送到缩短服务的作者已经设置的恶意站点。或者缩短服务本身可能被破坏，这将间接影响您的网站。基本上，外部托管的URL缩短服务为您节省了很多麻烦，因为您需要担心的攻击较少。但是，如果外部服务被破坏，最严重的攻击是您的用户将被提供不正确或恶意的URL。根据web服务从URL服务检索这些URL映射的方式进行身份验证，您可以执行MITM攻击，以便为您提供假URL。您的web服务也有可能被黑客攻击。同样，所有这些都取决于url缩短器服务以及web服务和身份验证的实现.有很多因素你还没有给我们提供信息。

Answer 2

您的服务器如何知道URL是否来自缩短服务？攻击者不能简单地把它们当作URL缩短服务，并以一种破坏系统的方式提交信息吗？

我看不出这与接受URL有什么不同，但随后进行URL重写以确保它们在URL上传递的信息不会显示出来，除非我遗漏了一些关于您建议的场景的内容。

如果您只是使用URL缩短服务为您的站点提供特定页面的随机标记，那么为什么不直接在DB内部存储一个书签呢？这样，您就可以控制用于防止滥用的输入。即使您正在直接调用缩短服务，如何防止恶意用户为您的域创建自己的短URL？(除非您有一个只返回帐户结果的缩短服务。)