HTML编码是否会阻止XSS安全漏洞？

通过简单地转换以下("大5"):

& -> &
< -> <
> -> >
" -> "
' -> '

你会阻止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.实质上只是逃避这些字符似乎是一个非常天真的方法.

你会阻止XSS攻击吗？

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

我认为你也需要在角色级别上列出白名单,以防止某些攻击

否.HTML-escaping会将每个攻击都呈现为页面上不活动的纯文本,这就是您想要的.该页面上的攻击范围展示了进行HTML注入的不同方法,这可以解决一些服务器部署的愚蠢的"XSS过滤器",以防止常见的HTML注入攻击.这表明"XSS过滤器"本质上是漏洞和无效的.

还有其他形式的XSS攻击的可能或可能不会影响你,对用户提交的URI的例子坏方案(javascript:等人),注入代码到数据呼应成一个JavaScript块(在您需要的JSON风格的转义)或成样式表或HTTP响应标题(同样,当您将文本拖放到另一个上下文时,您总是需要适当的编码形式;如果您看到任何非转义插值(如PHP "string $var string"),您应该始终怀疑).

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

(*:将文本内容插入到HTML中,而不是在其他时间.在脚本开头的$_POST/ $_GET开头不要使用HTML表单提交数据;这是一个常见的错误的错误.)

OWASP有一个很好的备忘单.

黄金法则

策略

等等.

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