问题标签 [xss]

在 Rails 中清理输出 HTML（以避免 XSS 攻击）的最佳解决方案是什么？

我有两个选择：来自 Sanitize Helper http://api.rubyonrails.com/classes/ActionView/Helpers/SanitizeHelper.html的 white_list 插件或 sanitize 方法。直到今天对我来说，white_list 插件工作得更好，在过去，Sanitize 有很多错误，但作为核心的一部分，它可能正在开发中并得到支持一段时间。

如果我在重新显示网站用户输入的任何数据时对其进行 HTML 编码，这会防止 CSS 漏洞吗？

此外，是否有可用的工具/产品可以为我清理我的用户输入，这样我就不必编写自己的例程了。

简单的问题一直困扰着我。

我应该立即对用户输入进行 HTML 编码并将编码的内容存储在数据库中，还是应该在显示时存储原始值和 HTML 编码？

存储编码数据大大降低了开发人员在显示数据时忘记编码数据的风险。但是，存储编码数据会使数据挖掘更加麻烦，并且会占用更多空间，即使这通常不是问题。

阅读这篇关于 HttpOnly cookie 的博文让我开始思考，是否有可能通过任何形式的 XSS 获得 HttpOnly cookie？Jeff 提到它“大大提高了标准”，但听起来好像它并不能完全防止 XSS。

除了并非所有浏览器都正确支持此功能这一事实之外，如果它们是 HttpOnly，黑客如何获取用户的 cookie？

我想不出任何办法让 HttpOnly cookie 将自己发送到另一个站点或被脚本读取，所以这似乎是一个安全的安全功能，但我总是惊讶于有些人可以轻松地解决许多问题安全层。

在我工作的环境中，我们只使用 IE，所以其他浏览器不是问题。我正在专门寻找其他可能成为不依赖于浏览器特定缺陷的问题的方法。

有这么多攻击站点的方法，如果有一个指南或资源，列出所有已知的漏洞和可能的预防措施，那将很有用。有人知道吗？

另外，是否有可以处理这种事情的库或框架？

我正在更新一个经典的 ASP 网页，该网页由我工作的公司维护的许多子站点使用。

该页面的目的是通知用户他们将离开“我们的”网站并前往另一个网站。它基本上是免责声明，但由于资源限制和时间限制，我无法将免责声明添加到我们管理的每个站点。

这是问题的症结所在。当前代码从查询字符串中提取一个变量以在新窗口中创建“继续”链接。这显然会以跨站点脚本的形式产生许多问题。

如何处理此更新以消除大多数（如果不是全部）使用 vbScript/ASP 的跨站点脚本问题。

我正在使用的代码如下。

有人可以用简单的英语解释 XSS 是如何工作的吗？也许举个例子。谷歌搜索没有多大帮助。

我的网站上有一个富文本编辑器，我试图保护它免受 XSS 攻击。我想我已经处理了几乎所有事情，但我仍然不确定如何处理图像。现在我正在使用以下正则表达式来验证图像 URL，我假设它会阻止内联 javascript XSS 攻击：

我不确定这对来自远程图像的 XSS 攻击有多开放。链接到外部图像是否构成严重的安全威胁？

我唯一能想到的是，输入的 URL 引用了一个资源，该资源返回“ text/javascript”作为其 MIME 类型而不是某种图像，然后执行 javascript。

那可能吗？我还应该考虑其他安全威胁吗？

我正在寻找编写一个 html 清理程序，显然为了测试/证明它可以正常工作，我需要一组 XSS 示例来反对它，看看它是如何执行的。这是来自 Coding Horror 的一个很好的例子

我知道有一个Mime Torture Test，其中包含几个嵌套的电子邮件，其中包含用于测试 Mime 解码器的附件（如果它们可以正确解码，那么它们已被证明有效）。我基本上是在寻找 XSS 的等价物，即我可以扔给我的消毒剂的狡猾 html 的示例列表，以确保它可以正常工作。

如果有人也有任何关于如何编写消毒剂的好资源（即人们尝试使用的常见漏洞等），他们也会受到感激。

提前致谢 ：-）

编辑：抱歉，如果之前不清楚，但我经过了一系列折磨测试，所以我可以为消毒剂编写单元测试，而不是在浏览器中测试它等等。理论上源数据可能来自任何地方 -不仅仅是一个浏览器。

我最近遇到了几个流行的 PHP 相关答案，建议使用 superglobal $_REQUEST，我认为这是代码异味，因为它让我想起了register_globals.

您能否提供一个很好的解释/证据来说明为什么$_REQUEST是不好的做法？我将抛出一些我已经挖掘出来的示例，并且希望获得有关理论攻击向量和现实世界漏洞的更多信息/观点，以及系统管理员可以采取的合理步骤以降低风险的建议（缺少重写应用程序......或者，我们是否需要去管理层并坚持重写？）。

漏洞示例：默认GPC数组合并顺序意味着 COOKIE 值覆盖 GET 和 POST，因此$_REQUEST可用于 XSS 和 HTTP 攻击。PHP 让 cookie 变量覆盖超全局数组。本演讲的前 10 张幻灯片给出了示例（整个演讲很棒）。phpMyAdmin 利用CSRF 攻击示例。

对策示例：重新配置$_REQUEST数组合并顺序 from GPC以CGP使 GET/POST 覆盖 COOKIE，而不是相反。使用Suhosin阻止覆盖超全局变量。

（另外，不会问我是否认为我的问题是骗人的，但令人高兴的是，对于“何时以及为什么应该使用 $_REQUEST 而不是 $_GET / $_POST / $_COOKIE？”的压倒性 SO 答案是“从不”。 )