PHP含trim()与stripslashes()的输入过滤器是否可被XSS攻击绕过？

你的这个输入过滤器在标准HTML文本上下文（比如直接输出到页面的段落、div内容里）的防护是比较可靠的，但结合实际应用场景，仍存在几个可能的XSS风险点：

• 输出上下文不匹配：htmlspecialchars只针对HTML文本内容做转义，如果你的过滤后内容输出到其他上下文，防护就会失效：

  • 无引号的HTML属性：比如输出到<div class=<?= $filteredData ?>>，输入onmouseover=alert(1)，htmlspecialchars不会转义=、()等字符，直接触发事件型XSS；
  • JavaScript代码块：比如输出到var userInput = '<?= $filteredData ?>';，默认htmlspecialchars不转义单引号，输入';alert(1);//会直接闭合字符串并执行恶意代码；
  • CSS样式块：输入expression(alert(1))（旧浏览器支持）或者其他CSS注入语法，过滤器无法拦截。

• htmlspecialchars参数配置不全：你调用htmlspecialchars时没指定字符集和转义标志：

  • 字符集问题：如果服务器默认字符集不是UTF-8，攻击者可利用宽字节编码绕过转义（比如GBK编码下的特殊字符组合，让<等字符不被正确识别转义）；
  • 转义标志缺失：默认ENT_COMPAT仅转义双引号，若输出到单引号包裹的属性（如<input value='<?= $filteredData ?>'>），输入' onfocus='alert(1)会直接闭合属性触发XSS，必须添加ENT_QUOTES标志才能同时转义单双引号。

• 过滤器未全局覆盖：如果部分用户可控输入漏用了这个过滤器（比如某些接口参数、数据库取出的旧数据未二次过滤），或者输入被后续代码篡改（比如误用stripslashes导致转义字符被移除，不过PHP7+已废弃magic_quotes，这个风险现在较低），都会直接暴露XSS漏洞。

• DOM型XSS绕过后端过滤：如果前端JavaScript直接处理用户输入（比如从URL参数、Cookie读取内容插入DOM），即使后端做了过滤，前端若未做二次处理（比如用innerHTML插入转义后的HTML、或用eval执行相关内容），攻击者仍可构造前端可解析的恶意代码触发XSS。

内容的提问来源于stack exchange，提问作者EVL9qpMx