我读过很多文章，描述了使用 htmlspecialchars 和正则表达式、白名单/黑名单等功能以及使用 HTML 过滤脚本(如 HTML Purifier、HTMLawed 等)防止用户提交的 HTML 内容中的 XSS 攻击的方法。
不幸的是，这些都无法解释像 eBay 这样的网站如何能够允许如此大量的潜在恶意 HTML 标签，例如 <link> , <script> , <object>以及 CSS 样式和 HTML 属性，例如 background: url() 等。似乎它们允许用户将几乎所有内容提交到他们的元素描述中。我在元素描述中看到了一些最精致的 HTML、Javascript 和 Flash 模板。
eBay 有何不同之处？是否有我遗漏的另一种技术或层，允许他们阻止 XSS 攻击，同时仍然允许在用户的元素描述中包含几乎所有内容？
任何想法或对此的见解将不胜感激!
最佳答案
当你有一群程序员和一大笔钱时，这很容易。
这不是火箭科学。他们确定了一个漏洞案例，并可能通过前端的 Regex 和 Javascript 以及大量的后端验证来围绕它进行编码，以确保数据在插入之前不会受到损害。这与我们所有人都应该做的一样，只是对于 Ebay，它比我们大多数人所做的要成熟得多，而且规模也大得多。
如果它像我以前工作的银行一样，他们有一个 PAS 团队，致力于发现产品中的微小错误、与工程师开票，并优先跟踪流程。在开发人员、测试人员、质量管理人员和 PAS 之间，没有理由应该泄露漏洞，但如果它碰巧漏掉了，就应该迅速使用react。
如果您打算走这条路，您应该考虑采用“渐进增强”的方法来应对这一挑战。首先首先完全阻止 javascript。然后，通过您认为安全的方法增强以允许 --some-- 并且只允许在您继续时安全的内容。继续这个过程允许越来越多，同时捕捉在测试或生产中出现的边缘案例。逐渐地，您将从允许允许的内容迁移到阻止不允许的内容。虽然这应该是显而易见的，但即使是最先进的公司也会在生命周期管理和改进的基本概念上错失良机。
也就是说，在尝试净化输入时，最好结合使用前端和后端验证方法。前端向客户提供更直观的快速反馈，但与任何客户端语言一样，精明的用户可以克服。后端验证是您的防火墙，确保任何通过前端的内容都得到适当处理。您的数据库是您的生命线，因此请不惜一切代价保护它!
除非您有一支军队和巨额预算，否则尝试在像 CMS 这样允许近乎全权输入的内容管理系统这样广泛的东西上为每个边缘案例编写代码几乎总是以失败告终。
关于php - 防止对用户在 PHP 中提交的 HTML 内容进行 XSS 攻击，eBay 方式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6284620/