13

通过简单地转换以下（“大 5”）：

& -> &
< -> &lt;
> -> &gt;
" -> &#034;
' -> &#039;

你会阻止 XSS 攻击吗？

我认为您也需要在字符级别上列入白名单，以防止某些攻击，但以下答案表明它使事情变得过于复杂。

编辑此页面详细信息it does not prevent more elaborate injections, does not help with "out of range characters = question marks" when outputting Strings to Writers with single byte encodings, nor prevents character reinterpretation when user switches browser encoding over displayed page.本质上只是转义这些字符似乎是一种非常幼稚的方法。

4

3 回答 3

13

你会阻止 XSS 攻击吗？

如果您在正确的时间(*) 进行此转义，那么是的，您将阻止 HTML 注入。这是最常见的 XSS 攻击形式。这不仅仅是安全问题，无论如何您都需要进行转义，以便包含这些字符的字符串无论如何都能正确显示。安全问题是正确性问题的一个子集。

我认为您也需要在角色级别上列入白名单，以防止某些攻击

不会。HTML 转义会将这些攻击中的每一个都呈现为页面上的非活动纯文本，这正是您想要的。该页面上的攻击范围展示了进行 HTML 注入的不同方法，这可以绕过一些服务器部署的更愚蠢的“XSS 过滤器”，以试图阻止常见的 HTML 注入攻击。这表明“XSS 过滤器”本质上是泄漏和无效的。

还有其他形式的 XSS 攻击可能会或可能不会影响您，例如用户提交的 URI 上的错误方案（javascript:等），将代码注入回显到 JavaScript 块中的数据（您需要 JSON 样式的转义）或样式表或 HTTP 响应标头（同样，当您将文本放入另一个上下文时，您总是需要适当的编码形式；如果您看到任何像 PHP 的非转义插值，您应该始终保持怀疑"string $var string"）。

然后是文件上传处理、Flash 源策略、旧版浏览器中的 UTF-8 超长序列以及应用程序级内容生成问题；所有这些都可能导致跨站点脚本。但是 HTML 注入是每个 Web 应用程序都将面临的主要问题，而且当今大多数 PHP 应用程序都会出错。

（*：这是在将文本内容插入 HTML 时，而不是其他时间。不要在脚本开头的$_POST/中对表单提交数据进行 HTML 转义$_GET；这是一个常见的错误。）

于 2010-02-25T15:25:48.363 回答
6

OWASP 有一个很棒的备忘单。

  1. 黄金法则
  2. 策略
  3. 等等。

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

于 2013-04-29T04:37:31.130 回答
4

对策取决于插入数据的上下文。如果将数据插入 HTML，用转义序列（即字符引用）替换 HTML 元字符会阻止插入 HTML 代码。

但是，如果您在另一个上下文中（例如，被解释为 URL 的 HTML 属性值），您必须处理具有不同转义序列的其他元字符。

于 2010-02-25T14:58:50.993 回答