首页 文章

CORS是一种安全的跨域AJAX请求方式吗？

提问于
浏览 次
70

在阅读了CORS（跨源资源共享）之后，我不明白它是如何提高安全性的 . 如果发送了正确的ORIGIN标头，则允许跨域AJAX通信 . 举个例子，如果我发送

起源：http://example.com

服务器检查此域是否在白名单中，如果是，则标头：

Access-Control-Allow-Origin：[收到此处的网址]

被送回，连同响应（这是简单的情况，也有预见的请求，但问题是一样的） .

这真的很安全吗？如果有人想要收到这些信息，假冒ORIGIN Headers 似乎是一项非常简单的任务 . 此外，该标准表示该策略在浏览器中强制执行，如果Access-Control-Allow-Origin不正确，则阻止响应 . 显然，如果有人试图获取该信息，他将不会使用标准浏览器来阻止它 .

javascript ajax cross-domain cors

6 回答

  • 45

    它不是为了阻止人们获取数据 . 没有人得到它你就无法暴露它 .

    它被设计成给定：

    • Alice，提供API的人，可以通过Ajax访问

    • Bob，一个有网络浏览器的人

    • 查理，第三方经营自己的网站

    如果Bob访问Charlie的网站，那么Charlie无法将JS发送到Bob的浏览器，以便从Alice的网站获取数据并将其发送给Charlie .

    如果Bob在Alice的网站上有一个用户帐户，允许他做帖子评论或删除数据，上述情况就变得更加重要 - 因为没有保护，Charlie可以告诉Bob的浏览器在Bob的背后做这件事 .

    如果您想阻止未经授权的人员查看数据，则需要使用密码，SSL客户端证书或其他基于身份的身份验证/授权方法进行保护 .

    回复于
  • 3

    目的是防止这种情况 -

    • 你去X网站

    • 网站X的作者写了一个邪恶的脚本，然后发送到您的浏览器

    • 在您的浏览器上运行的脚本会登录到您的银行网站并执行恶意内容，并且因为它在您的浏览器中正在运行，因此它有权这样做 .

    我们的想法是，您的银行网站需要某种方式告诉您的浏览器是否应该信任网站X上的脚本来访问您银行的页面 .

    回复于
  • 1

    只是为了补充@jcoder的答案， Origin Headers 的重点不在于保护服务器上请求的资源，该任务通过其他方式由服务器本身决定，正是因为攻击者确实能够欺骗这个 Headers 带有适当的工具 .

    Origin Headers 的要点是保护用户 . 方案如下：

    • 攻击者创建恶意网站M.

    • 用户Alice被欺骗连接到M，其中包含一个脚本，该脚本试图通过CORS在实际支持CORS的服务器B上执行某些操作

    • B可能在其 Access-Control-Allow-Origin Headers 中没有M，原因为什么呢？

    • 关键点是，M无法欺骗或覆盖 Origin 标头，因为请求是由Alice的浏览器启动的 . 所以她的浏览器会将（正确的） Origin 设置为M，这不在B的 Access-Control-Allow-Origin 中，因此请求将失败 .

    现在，爱丽丝可以自己改变 Headers ，但为什么她会这样，因为这意味着她会伤害自己？

    TL; DR： Origin 标头保护无辜的用户 . 它不保护资源 . 攻击者可以在自己的机器上进行欺骗，但不能在不受他控制的机器上进行欺骗 .

    服务器仍应保护其资源，因为匹配的 Origin 标头并不意味着授权访问 . 但是， Origin 标头不匹配，表示未经授权的访问 .

    回复于
  • 43

    同一起源政策的目的是甚至不需要浏览器 . 关键是要停止 client scripts 访问另一个域上的内容而没有必要的访问权限 . 请参阅Same Origin Policy的维基百科条目 .

    回复于
  • 130

    After reading about CORS, I don't understand how it improves security.

    CORS不会提高安全性 . CORS为服务器提供了一种机制，告诉浏览器外部域应该如何访问它们，并且它尝试以与CORS之前存在的浏览器安全模型（即Same Origin Policy）一致的方式执行此操作 .

    但同源策略和CORS的范围有限 . 具体来说，CORS specification本身没有拒绝请求的机制 . 它可以使用标头告诉浏览器不要让来自外部的页面域读取响应 . 并且，在预检请求的情况下，它可以要求浏览器不发送来自外部域的某些请求 . 但是CORS没有指定服务器拒绝（即不执行）实际请求的任何方法 .

    我们来举个例子吧 . 用户通过cookie登录到站点 A . 用户加载恶意网站 M ，该网站尝试提交执行 POST 到 A 的表单 . 会发生什么？好吧，有或没有CORS，并且有或没有 M 是允许的域，浏览器将使用用户的授权cookie将请求发送到 A ，并且服务器将执行恶意 POST ，就像用户启动它一样 .

    这种攻击被称为Cross-Site Request Forgery，而CORS本身并没有什么可以缓解它 . 这就是为什么如果您允许代表用户更改数据请求，CSRF保护如此重要 .

    现在，使用 Origin 标头可以成为CSRF保护的重要组成部分 . 确实，检查它是current recommendation for multi-pronged CSRF defense的一部分 . 但是 Origin 标头的使用超出了CORS规范 .

    总之，CORS是一个有用的规范，用于将现有的同源策略安全模型扩展到其他接受域 . 它不会增加安全性，站点需要与CORS之前相同的防御机制 .

    回复于
  • 14

    我迟到了，但我认为这里的任何帖子都没有提供所寻求的答案 . 最大的问题应该是浏览器是写入 origin 标头值的代理 . 恶意脚本无法写入 origin 标头值 . 当服务器使用 Access-Control-Allow-Origin 标头进行响应时，浏览器会尝试确保此标头包含之前发送的 origin 值 . 如果不是，则会触发错误，并且不会将值返回给请求脚本 . 这个问题的其他答案提供了一个很好的场景，当你想拒绝回答邪恶的剧本 .

    @daniel f也提供了一个很好的答案

    回复于

相关问题