如果使用正确，htmlspecialchars是否足以抵御所有XSS？ [英] When used correctly, is htmlspecialchars sufficient for protection against all XSS?

问题描述

如果以下声明为真，那么所有文档都以HTTP标头 Content-Type的形式提供： 为text / html; charset = UTF-8 。

所有HTML属性都包含在单引号或双引号中。 < script> 标签。

htmlspecialchars（$ input，ENT_QUOTES，'UTF-8'）（转换& ， ，'， ，> 到相应的命名HTML实体）不足以防止在Web服务器上生成HTML时出现跨站点脚本？

解决方案

div> htmlspecialchars（）足以阻止文档创建时的HTML注入，并具有您所声明的限制（即不会注入标记内容/未引用的属性）。

然而，还有其他类型的注入会导致XSS和：

lockquote

文档中没有< script>标记。

这种情况不会涵盖了JS注射的所有情况。例如，您可能有一个事件处理程序属性（需要在HTML转义内部进行JS转义）：

 < div onmouseover = alert（'<？php echo htmlspecialchars（$ xss）？>'）> //不好！ 
  

更糟糕的是，一个javascript：link（需要JS内部转义 -

 < a href =javascript：alert（'<？php echo htmlspecialchars（$ xss）？> ;'）> //不好！ 
  

无论如何，通常最好避免使用这些构造，但特别是在模板化时。写作<？php echo htmlspecialchars（urlencode（json_encode（$ something）））？>> 非常单调乏味。

<注入问题也可能发生在客户端（DOM XSS）; htmlspecialchars（）不会保护您免遭一段JavaScript写入 innerHTML （通常 .html（）在糟糕的jQuery脚本中）而不显式转义。

和...... XSS的原因不仅仅是注入。其他常见原因包括：

$ ul

允许用户创建链接，而不检查已知的URL方案（ javascript：是最有名的有害方案，但还有更多）

故意允许用户创建标记，可以直接或通过光标记方案（如bbcode，这是总是可以利用的）

允许用户上传文件（可以通过各种方式重新解释为HTML或XML）

If the following statements are true,

• All documents are served with the HTTP header Content-Type: text/html; charset=UTF-8.
• All HTML attributes are enclosed in either single or double quotes.
• There are no <script> tags in the document.

are there any cases where htmlspecialchars($input, ENT_QUOTES, 'UTF-8') (converting &, ", ', <, > to the corresponding named HTML entities) is not enough to protect against cross-site scripting when generating HTML on a web server?

解决方案

htmlspecialchars() is enough to prevent document-creation-time HTML injection with the limitations you state (ie no injection into tag content/unquoted attribute).

However there are other kinds of injection that can lead to XSS and:

There are no <script> tags in the document.

this condition doesn't cover all cases of JS injection. You might for example have an event handler attribute (requires JS-escaping inside HTML-escaping):

<div onmouseover="alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!

or, even worse, a javascript: link (requires JS-escaping inside URL-escaping inside HTML-escaping):

<a href="javascript:alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!

It is usually best to avoid these constructs anyway, but especially when templating. Writing <?php echo htmlspecialchars(urlencode(json_encode($something))) ?> is quite tedious.

And... injection issues can happen on the client-side as well (DOM XSS); htmlspecialchars() won't protect you against a piece of JavaScript writing to innerHTML (commonly .html() in poor jQuery scripts) without explicit escaping.

And... XSS has a wider range of causes than just injections. Other common causes are:

• allowing the user to create links, without checking for known-good URL schemes (javascript: is the most well-known harmful scheme but there are more)

• deliberately allowing the user to create markup, either directly or through light-markup schemes (like bbcode which is invariably exploitable)

• allowing the user to upload files (which can through various means be reinterpreted as HTML or XML)

这篇关于如果使用正确，htmlspecialchars是否足以抵御所有XSS？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！