AntiSamy 允许编码脚本警报通过？怎么屏蔽？
我将 AntiSamy 与可用的 antisamy-1.4.1.xml 策略一起使用。该策略可以很好地阻止大多数 XSS 攻击，但以下内容未被阻止。关于如何阻止以下内容以防止 XSS 攻击，您有什么建议吗？
1234%27%2Balert%2873918%29%2B%27
谢谢
I'm using AntiSamy with the available antisamy-1.4.1.xml policy. The policy is working nicely to block most XSS attacked but the following below is not being blocked. Any suggestions on how to block the following below to prevent XSS attacks?
1234%27%2Balert%2873918%29%2B%27
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Antisamy 是一种 HTML 内容过滤器，旨在允许不受信任的用户输入“安全”HTML 的有限子集。它不是一个通用的输入过滤器，可以让您不必考虑字符串转义和 XSS 问题。
您应该仅使用 antisamy 来清理包含您希望在页面上逐字输出的 HTML 的内容。大多数用户输入通常不是 HTML：当用户输入
ad时，他们通常应该得到小于和大于的文字字符，而不是粗体标记。为了确保这种情况正确发生，您必须对输出阶段插入页面的所有文本内容进行 HTML 转义，而不是与反同义相关的任何内容。这看起来一点都不像典型的 HTML 注入攻击。它包含的唯一“特殊”字符是撇号，它在 HTML 中通常并不特殊，并且实际上无法从输入中过滤掉，因为用户通常需要使用撇号来书写英语。
如果这导致您的应用程序发生脚本注入，那么您遇到的问题比任何 antisamy 都无法解决的问题更大。如果这导致您的页面弹出
alert()对话框，则您可能正在使用 JavaScript 字符串文字中未转义的值，例如：将文本内容作为字符串文字放入 JavaScript 代码中需要另一种形式的转义；将
'字符（URL 编码输入中的%27）转换为反斜杠转义的\'和\本身变成\\（以及一些其他替换）。将服务器端脚本语言中的值（字符串或其他形式）转换为 JavaScript 文本的简单方法是使用标准 JSON 编码器。
但是，在上述情况下，JavaScript 字符串文字本身包含在 HTML 属性内，因此您必须对 JSON 编码器的结果进行 HTML 编码。这有点难看；最好避免内联事件处理程序属性。请改用外部脚本和
即使在通常不需要 HTML 编码的
（或者，一般来说，任何以开头的内容都可以结束该块）。为了避免这种顺序，您应该将<字符替换为其他字符，例如。 <代码>\x3C。某些 JSON 编码器可能有一个选项可以为您省去麻烦。在许多其他地方，将内容插入到包含语言中需要特殊类型的编码。每个都有自己的规则。使用通用输入过滤器无法避免字符串编码的困难。一些“反 XSS”过滤器尝试过，但它们总是惨败。
Antisamy is an HTML content filter meant for allowing an untrusted user to input a limited subset of ‘safe’ HTML. It is not an all-purpose input filter that can save you from having to think about string escaping and XSS issues.
You should use antisamy only to clean up content that will contain HTML that you wish to output verbatim on a page. Most user input is generally not HTML: when a user types
a<b or c>d, they should usually get the literal less-than and greater-than characters and not a bold tag. To ensure this happens correctly, you must HTML-escape all text content that gets inserted into your page at the output stage, instead of anything to do with antisamy.This looks nothing like a typical HTML injection attack. The only ‘special’ character it contains is an apostrophe, which isn't usually special in HTML, and can't practically be filtered out of input because users do generally need to use apostrophes for writing in English.
If this is causing script injection for your application, you've got bigger problems than anything antisamy can solve. If this is causing your page to pop up an
alert()dialogue, you are probably using the value unescaped in a JavaScript string literal, for example something like:Putting text content into JavaScript code as a string literal requires another form of escaping; one that turns the
'character (the%27in the URL-encoded input) into a backslash-escaped\', and\itself into\\(as well as a few other replacements).The easy way to get values (strings or otherwise) from a server-side scripting language into a JavaScript literal is to use a standard JSON encoder.
However, in the above case, the JavaScript string literal is itself contained inside an HTML attribute, so you would have to HTML-encode the results of the JSON encoder. This is a bit ugly; it's best to avoid inline event handler attributes. Use external scripts and
<script>elements instead, binding events from JS instead of HTML.Even in a
<script>block, where you don't generally need to HTML-encode, you have to beware of a string</script>(or, generally, anything beginning</, which can end the block). To avoid that sequence you should replace the<character with something else, eg.\x3C. Some JSON encoders may have an option to do this for you to save the trouble.There are many other places where inserting content into a containing language requires special sorts of encoding. Each has its own rules. You can't avoid the difficulty of string encoding by using a general-purpose input filter. Some “anti-XSS” filters try, but they invariably fail miserably.