同时拥有 mod_security 和 htmlpurifier 是不是太过分了？
我们之前已将 htmlpurifier 集成到基于 LAMP 的产品中，但速度有点慢。最近，我们开启了 mod_security。这两个都是 OWASP 项目的一部分（我上次检查时 owasp 在内部使用了 htmlpurifer），所以我认为安全性是多余的。
你有什么建议？关闭 htmpurifier 是一个可行的选择吗？感谢您的任何答复。
We had htmlpurifier integrated into our LAMP based product earlier, but it was a bit slow. Recently, we have turned on mod_security. Both of these are part of the OWASP project (owasp used htmlpurifer internally last I checked) so I am thinking the security is redundant.
What would you suggest? Is turning off htmpurifier a viable option? Thanks for any answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
他们都做不同的事情。
mod_security是黑名单。它涵盖了一些通用漏洞（其中包括 XSS、SQL 注入、目录遍历、URL 注入等）和过去的应用程序错误，但可能更容易通过更复杂的编码和特定于应用程序的方法来规避过滤器。 （它通常只是探测某些网址参数。）HTMLPurifier实际上只涉及 HTML 清理，但它做得相当好。它是一个白名单过滤器，因此根据定义更安全。当然很慢。这就是为什么您应该只将其应用于传入数据，而不是作为所有内容和任何地方的通用过滤器。如果它减慢了你的应用程序的速度，你可能会在错误的地方使用它。They both do different things.
mod_securityis a blacklist. It covers some generic exploits (among them XSS, SQL injection, directory traversals, url injection, and others) and past application bugs, but is likely easier to foil with more elaborate encodings and application-specific ways to circumvent the filters. (It often just probes for some URL parameters.)HTMLPurifierreally only coveres HTML sanitization, but that it does quite well. It's a whitelist filter, so by definition more secure. It's of course slow. Which is why you should only apply it to incoming data, not as generic filter for everything and everywhere. If it slows down your application you are potentially using it in the wrong spots.