我发现了一个我正在维护的软件中的漏洞，用户可以在该漏洞中将javascript:和data:链接放到其他人可以看到的内容中。
但是，有一种机制可以将http://附加到不是以[a-z0-9]+://开头的任何链接href，这基本上使得仅添加以{{ 1}}或javascript://。我想弄清楚这有多大的安全问题，所以我的问题是，单击这些链接是否可以利用这些链接来执行JavaScript代码？
我的理解是data://链接只能包含JavaScript单行注释，因此无法执行任何代码。我想单行注释只能以换行符（javascript://）结尾，但是我不确定是否有办法将这样的换行符添加到链接href中。我尝试了诸如\n，href="javascript://
alert('test')"，href="javascript:// alert('test')"之类的不同方法，以及一个带有href="javascript://%0aalert('test')"字符的方法，但它们似乎都没有执行任何代码。
对于\0 URI，我猜不可能组成任何以data:开头的有效URI，但是也许仍然有一些浏览器可以通过某种方式加以利用？
答案 0 :(得分：1)
我在这里提出了一些可能的问题，因为这是一个有趣的挑战。即使这些都不起作用，我认为您可以很轻松地使此安全性提高，值得您放心。无论如何，这是我想出的一些有效载荷。
您说这对您不起作用，但在Chrome（Windows 10/69.0.3497.100）中对我有用。这是最明显的工作，也是我能想到的唯一工作。尝试时可能打错了字？尽管HTML实体编码无法实现，但是简单的URL编码应该...如果您的源最终看起来像这样，那么它应该可以工作：
<a href="javascript://%0aalert(document.location)">xss test</a> (jsfiddle PoC)
您说过它必须“以[a-z0-9]+://开头，但是该正则表达式不包含“开始”部分，因此类似这样的内容可能是这样的：
javascript:alert(1);//abc://foo.bar
您可能有类似^[a-z0-9]:\/\/之类的东西，或者正在使用包装“ startsWith（）”或类似内容的语言。值得一提。
我认为这里没有很多东西，但是值得一看。这是您可能没有考虑的攻击媒介。
view-source://data:text/html,<script>alert(1);</script>
对于一个，这是view-source，因此不应执行任何操作。对于两个，它应该给出CORS错误（我认为）。最后，即使它确实执行了，它也会在与您的页面不同的上下文中执行（如果这是他们的目标，则它们可以链接到恶意网站）。所以周围的一切都比较薄弱。话虽如此，也许还有其他嵌套协议可能会出现问题。
并非完全是XSS，但仍然是潜在的问题。攻击者可能可以链接到您网站上的现有页面，例如https://example.com/account/delete。如果他们可以控制链接的显示名称，则可能会令人信服。即使他们不控制显示名称，您也可以创建一些非常令人困惑的uri，以掩盖其实际位置（各种编码技术）。您的网站上可能没有这样的URL（很好！），但它确实经常发生。
这可能很明显，但是请务必注意，用户可以链接到复制您网站（或其他网站）外观的网站。这只是允许任意超链接附带的一般问题。如果您的用户群特别容易受到此攻击，则许多站点会将外部链接重定向到警告页面（这可以像一个小js一样简单完成，例如：onclick="return confirm('you sure you want to do that?')"。尽管如此，我不知道这些事情真的有效吗？是-这只是您看到的东西。
我们可能会抱怨上百万种可能会或可能不会导致安全问题的东西。最后，可能有必要对要允许的协议强制执行白名单。您是否希望人们能够包含诸如mailto:，ssh:，slack:，file:等的链接？我会做一个以http（s）开头的客户端正则表达式，然后在后端使用URI解析器来确认该方案确实是http（s），如果不是，则发出警告。这更多的是用户体验方面的内容，但是如果您担心大多数用户会键入“ www.example.com”之类的内容，则可以向他们发出客户端警告，提示它应该以http（s）开头（或者只是默认情况下在此放置）。对于奖励积分，可以考虑使用信誉检查API，并在网址旁边显示结果，拒绝信誉不好的任何域。