Question

在我的应用程序中，攻击者可以传递这样的URI：

http://domain/someapi?entryId=d2rf<script>alert("gotcha")</script>f334&param2=....

我需要采取哪些措施来防止它。即使在OWASP网站上，我似乎无法找到一个好的答案。根据OWASP，ascii值小于256的每个字符都可以。

我也不想要一些非常通用的解决方案，例如通过剥离它的＆lt;＆gt;来清理每个参数。迹象。

Answer 1

好的，我们来看一个例子吧。您有一个搜索页面，它为搜索查询提供了一个GET参数。

http://example.com?search=test+search

在搜索页面上，您可以执行以下操作。

<p>your search results for "{search}":</p>

这很容易被reflected XSS攻击。以下查询：

http://example.com?search=<script>alert(1);</script>

会产生以下HTML：

<p>your search results for "<script>alert(1);</script>":</p>

显然，这不好，因为它会执行脚本（好吧，XSS Auditor 可能会阻止它，但我们不依赖于它。我们可以做的第一件事就是逃避这个字符串，因为它不受信任并来自客户端。

<p>your search results for "{HTML.Escape(search)}":</p>

当然，这种语法取决于您的服务器端语言。一般来说，您正在寻找HTMLEncode / Escape /等。我确信有人可以指向一个函数或库，以便在PHP中执行此操作。

现在我们转义字符串，我们的输出看起来像这样：

<p>your search results for "&lt;script&gt;alert(1)&lt;/script&gt;":</p>

这将在浏览器中显示为<，但源代码将被编码（<）。

这是预防大多数XSS的一般概述。手动逃避每一个输入可能有点冒险，因为你可能会忘记一个。所以你想使用某种模板系统。您为HTML属性/ javascript字符串/ html实体等做了不同的事情。

Google为此提供了很好的介绍性资源：

Answer 2

根据OWASP，ascii值小于256的每个字符都可以。

什么？不，XSS prevention depends on context！我也非常确定OWASP不会将每个小于256的ASCII值视为可以，因为ASCII仅定义为0到127个字符。

我也不想要一些非常通用的解决方案，例如通过剥离它来清理每个参数＆lt;＆gt;＆lt;＆gt;标志

如果攻击者在URL参数中提供恶意Javascript代码，则无法阻止他们这样做。您可以做的是确保您的应用程序不会盲目地将此值反映给用户，否则您已经打开了通向反思的跨站点脚本漏洞的大门。 / p>

您是否需要接受并反映（显示）任意HTML代码？

是：使用HTML Purifier。
否：以下其中一项应该可以安全使用：
- htmlentities($yourStringVariable, ENT_QUOTES | ENT_HTML5, 'UTF-8');
- 仅限网址：http_build_query($yourArrayOfKeysAndValues);或urlencode($string);