【问题标题】:Prevent HTML form action from being changed防止更改 HTML 表单操作
【发布时间】:2011-11-20 12:21:57
【问题描述】:

我的页面上有一个表单,用户可以在其中输入他们的信用卡数据。是否可以在 HTML 中将表单的操作标记为常量以防止恶意 JavaScript 更改表单的操作属性?我可以想象一个 XSS 攻击,它会更改表单 URL,使用户将他们的秘密数据发布到攻击者的站点。

有可能吗?或者,网络浏览器中是否有其他功能可以防止此类攻击的发生?

【问题讨论】:

  • 恶意 JavaScript 首先是如何进入表单的?支付表单是否允许显示用户提交的内容(XSS)?那将是一种不寻常的付款方式。

标签: javascript html forms xss action


【解决方案1】:

这种攻击是可能的,但这是防止它的错误方法。如果黑客可以更改表单的详细信息,他们可以通过 AJAX GET 轻松发送秘密数据,而无需提交表单。防止 XSS 攻击的正确方法是确保对页面上所有不受信任的内容进行编码,以使黑客一开始就没有能力执行自己的 JavaScript。


更多关于编码...

StackOverflow 上的示例代码是一个很好的编码示例。想象一下,如果每次有人发布一些示例 JavaScript 时,它实际上是在浏览器中执行的,那将是多么混乱。例如,

<script type="text/javascript">alert('foo');</script>

如果不是因为 SO 对上面的 sn-p 进行了编码,你就会看到一个警告框。这当然是一个相当无害的脚本——我本可以编写一些 JavaScript 来劫持您的会话 cookie 并将其发送到 evil.com/hacked-sessions。然而,幸运的是,SO 并不假定每个人都是善意的,而是实际上对内容进行了编码。例如,如果您要查看源代码,您会看到 SO 已将我完全有效的 HTML 和 JavaScript 编码为:

<script type="text/javascript">alert('foo');</script>

因此,与其在我使用它们的地方嵌入实际的 <> 字符,它们已被替换为它们的 HTML 编码等效项(<>),这意味着我的代码不再代表一个脚本标签。

无论如何,这就是编码背后的总体思路。有关如何您应该编码的更多信息,这取决于您在服务器端使用的内容,但大多数 Web 框架都包含某种“开箱即用”的 HTML 编码实用程序.您的责任是确保用户提供的(或其他不受信任的)内容在呈现之前始终进行编码。

【讨论】:

  • “编码”到底是什么意思?听起来不错,但我不确定这会涉及哪些技术。
  • 我知道防止 XSS 攻击的最佳方法是对所有内容进行编码。但这很难,你总是可以忘记一个领域。由于同源策略,使用 AJAX 发送秘密数据并不容易。我仍然可以看到拥有这样的功能的一些优势。
  • @Michal - 将数据发送到跨域服务器非常容易。您所要做的就是插入一个脚本标签,将脚本 src=xxx" 指向其他服务器,并将数据作为查询参数放入脚本标签 URL。这就是 JSONP 的工作方式,尽管此处不需要 JSONP 来仅发送数据到其他服务器。
  • @Michał - 实际上使用GET 请求通过 AJAX 发送秘密数据非常容易。就 RESTful 语义而言,这不是很“正确”,但我认为黑客不会在这一点上失眠。尝试按照您要求的方式阻止 XSS 是非常不明智的。这有点像问“我如何防止我偷来的车被开到维加斯?”一旦你解决了这个问题,你必须阻止他们把它带到西雅图,然后是洛杉矶,等等。你最好简单地学习如何正确锁定门(即完全防止 XSS):p
  • @jmar777 - 你是对的。我同意防止 XSS 是最好的方法。我并不是说我提出的功能应该用于防止这种攻击。我想到的是,这可能是一个很好的功能,可以防止在您不小心忘记对 JS 进行编码时发生这种攻击。只是一个双重检查。顺便提一句。如果调用其他域的 URL 仍然那么容易,为什么我们需要同源策略:)
【解决方案2】:

网络浏览器中是否有不同的功能? 防止此类攻击发生?

更新的浏览器版本通过新的Content-Security-Policy 标头解决了您的问题。

通过配置script-src,您可以彻底禁止内联javascript。请注意,这种保护不一定会扩展到使用旧版浏览器的用户(请参阅CanIUse)。

只允许白标脚本可以抵御大多数 javascript XSS 攻击,但可能需要对您的内容进行重大修改。此外,如果您使用的 Web 框架严重依赖内联 javascript,则阻止内联 javascript 可能是不切实际的。

【讨论】:

    【解决方案3】:

    没有什么可以真正阻止它。

    我建议做的唯一事情是对从用户表单传入服务器的任何信息进行一些服务器端验证。

    俗话说:永远不要相信用户

    【讨论】:

    • 我觉得这个问题更多是为了保护用户。
    • 保护用户?从什么开始?
    • 不知不觉中。他们可以认为他们将数据发布到同一个站点,但数据是发送到其他地方的。
    • @MichałFronczyk 我知道你无法阻止这种情况发生。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-05-14
    相关资源
    最近更新 更多