我们最近在基于 Web 的应用程序中实现了 htmlpurifier。早些时候，我们使用正则表达式来匹配常见的 XSS 注入（脚本、img 等）。我们意识到这还不够好，因此转向了 htmlpurifier。现在考虑到 htmlpurifier 的工作速度很慢（与我们之前使用的正则表达式方法相比非常慢），真的值得拥有 htmlpurifier 吗？或者继续增加正则表达式过滤直到我们达到令人满意的水平是否有意义（可能会认为到那时速度优势将被抵消）。是否有其他人在其 Web 应用程序的安全性方面遇到过类似问题，您最后做了什么？
如果有任何不清楚的地方，请告知；我很乐意提供更多细节。
正则表达式的问题在于过滤 HTML 是一项过于复杂的任务，无法使用正则表达式轻松或优雅地完成，而不会造成大麻烦。
你需要构建一个真正理解 HTML 并且可以像 HTML 一样对其进行操作的东西，并且知道浏览器将如何解释某些东西。正则表达式对其进行操作，就好像它只是一个大长字符串一样。它们在以有状态的方式解析 HTML 方面并不出色或优雅，例如识别当前匹配在评论内、属性内或元素内等。在正则表达式中模拟它真的很复杂。
另一个问题是“匹配众所周知的 XSS 注入”比听起来要复杂得多。如果不是，那么你做的不对。您的过滤器需要知道 HTML，它需要知道有效的 URL 方案是什么以及空字节如何在 HTML 的不同部分中工作等。基本上，例如，XSS 备忘单上的大多数注入都是基于绕过过滤由基于正则表达式的过滤器完成。
还有一件事是，HTML 净化器由知道自己在做什么的人维护。你可以相信它，你可以相信，如果它有新的缺陷，它会被修补。这可以为您节省大量尝试自己做同样事情的工作，并确保您与所有不同的补丁保持同步。
对 html/javascript 使用正则表达式？也许您还没有看过Bobice 先生的这个史诗般的回答。简而言之，如果您使用正则表达式，那么您有两个问题。事实上，HTML Purifier 之所以这么慢，是因为它使用了数百次调用preg_match()来preg_repalce()清理消息。你绝不能重新发明小麦，毫无疑问会降低安全性。
真正的问题是htmlspeicalchars($var,ENT_QUOTES);vs HTML Purifier。HTML Purifer 不仅速度慢，而且已经被黑客入侵了很多次。除非没有其他选择，否则不要使用 HTML Purifier，htmlspeicalchars 解决了大多数问题，并且以无法绕过的方式解决。
安全总比后悔好。您的正则表达式可能找不到大量攻击。例如，这里只是几个. 如果 HTML Purifier 太慢，请查看缓存纯化的 HTML 是否有帮助。