当恶意用户被允许使用 HTML 标签(即在 textarea 元素中)时，我应该如何防止他/她执行 XSS 攻击？我不会删除所有标签或转义它们，因此我无法使用 {{ }} 。
顺便说一句:还有另一种危险的情况，即使 {{ }} 也不是一个好主意。请考虑this link 。有没有什么方法可以让用户使用html标签但阻止他执行XSS攻击？
最佳答案
客户端 html 编辑器可能是尝试防止 XSS 时面临的最大挑战。实际上，许多第 3 方编辑器组件都无法做到这一点。
在许多情况下，一种实际上可以相当有效地工作的方法是清理。您可以使用一个以 html 作为输入并以几乎相同的 html 作为输出的 sanitizer 程序库，除了它(应该)删除所有 javascript。一个例子是 HTML Purifier ，它在服务器端执行此操作。
许多人可能会认为执行此操作的唯一正确位置是服务器端。但是，有时需要注意一点，这可能适用于您的用例，也可能不适用于您的用例。如果客户端 html 编辑器有预览，则还必须对其进行清理以防止 DOM XSS，并且预览通常不会发送到服务器(编辑的内容会立即显示在客户端上，无需服务器往返)。虽然这是一种风险较低的 XSS，但它绝对是您需要预防的一种，而且服务器端清理在这里起不了多大作用。
因此，除了服务器端 sanitizer 之外，您可能还想使用客户端 sanitizer ，或者代替服务器端 sanitizer 。一个例子是 Google Caja 中的客户端 sanitizer 程序。 (这是一个更大的项目，我只谈论他们的 sanitizer in Javascript )，或者还有 DOMPurify客户端的另一个例子。这些可以挂接到任何客户端 html 编辑器组件中，以便在实际显示代码之前对其进行清理，从而有效地消除 XSS。
任何清理的风险在于清理程序会遗漏某些内容，并且允许 XSS 攻击向量通过。这基本上是一个信任的事情，例如很多人使用 Caja，它是由 Google 开发的，所以你可能有一些保证它相当好。这对您来说是否足够好取决于您的具体情况、风险偏好等。
可能还有其他方法(从不同来源提供 HTML 内容并接受该来源上的 XSS 风险，或者使用自定义标记小心地将其转换为无 XSS 的 html 等)，但清理可能最适合大多数用例。
关于javascript - Laravel:在允许 HTML 标签时，针对 XSS 清理用户输入，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40979036/