【问题标题】:Secure Implementation of Asynchronous XHRs异步 XHR 的安全实现
【发布时间】:2011-07-14 16:53:35
【问题描述】:

我通过 Google 找到了这个 great tip,并且我非常熟悉通过 Javascript 填充 div 的技术。我想知道的是,这是一种请求异步页面内容的安全方式吗?如果不是,那么部分页面加载的“安全”解决方案是什么?

非常感谢:)

【问题讨论】:

  • 这个问题令人困惑。 “更好(更安全)”比什么?异步性与安全性有什么关系?
  • 我也不确定 XSS 预防与任何事情有什么关系;这可能是任何类型的 HTTP 事务的问题。此外,“背后的代码”将变得“晦涩难懂”,因为它存在于服务器上。只要有一个 URL 可以发布到,它是否是 XHR 真的没有什么区别(可能除了一些反 CSRF 方案)。
  • 请注意,我问是否有更安全的方法。根据我在 ASP.NET 安全性上的 Wrox 恩惠,可以将代码注入到 Javascript http 请求中,这对我来说很有意义,因为所有客户端脚本对用户都是可见的。我不明白为什么我的问题如此令人困惑。
  • 再次:比什么“更安全的方式”?当然,这个问题不会让你感到困惑。 ;-) 这证明不了,因为这是你的问题。
  • 我必须同意其他人的观点。很难理解你在这里真正问的是什么。首先,“大提示”链接似乎与您的安全问题无关。其次,你问“这个”是否真的是一种安全的方法,我不知道你在说什么“这个”方法,因为你没有描述它或包含代码示例,只有一个让我感到困惑的参考关于您正在讨论的方法。您可以保持防御并坚持您的问题很明确,但如果没有澄清,您不太可能找到帮助。请尝试澄清您的问题。

标签: javascript asp.net security web-applications


【解决方案1】:

Ajax 调用是一个 HTTP 请求。

用于普通发布和获取的相同安全实践适用于 Ajax 发布和获取。

人们吓坏了,因为我可以在 Firebug 中看到我的 Ajax 调用,而且人们可以看到调用的 url。任何人都可以通过简单的代理查看您对后端的调用。

唯一不同的是,Ajax 调用更容易受到 XSS 的攻击,因为人们倾向于使用 innerHTML 将响应中的任何内容推送出去。真正发生这种情况的唯一方法是服务器被入侵并发送错误信息或发生中间人攻击。

但是当你看它的时候,同样的东西可以用一个普通的get来注入。

您应该确保您仍然在服务器上使用身份验证来进行 Ajax 后端调用,您应该验证服务器上的数据,并在客户端添加基本安全检查,并避免使用 eval() [使用 JSON.parse 或JSON.js]

OWASP 有一些Ajax Security Guidelines

【讨论】:

  • 太棒了!非常感谢。你准确地回答了我的问题,并谈到了我熟悉的问题。在收到别人如此粗鲁的态度后,我非常感谢。 :)
  • @Chiramisu:冷静点。没有人对你粗鲁过。
  • @Chiramisu:你觉得很受什么的攻击?要求澄清?对您的第一个 SO 问题投了反对票?我想,是时候进行现实检查了。再读一遍你得到的 cmets,告诉我有人在哪里攻击过你。
  • @Tomalak:算了,伙计,这不值得。干杯;)
  • @Chiramisu 无论如何你都很难回答这个问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-04-23
  • 2017-05-13
  • 2020-01-18
  • 1970-01-01
  • 2012-07-22
  • 2017-12-28
相关资源
最近更新 更多