Gib*_*001 76 javascript ajax cross-domain cors
在阅读了CORS(跨源资源共享)之后,我不明白它是如何提高安全性的.如果发送了正确的ORIGIN标头,则允许跨域AJAX通信.举个例子,如果我发送
服务器检查此域是否在白名单中,如果是,则标头:
Access-Control-Allow-Origin:[收到此处的网址]
被送回,连同响应(这是简单的情况,也有预见的请求,但问题是一样的).
这真的很安全吗？如果有人想要收到这些信息,假冒ORIGIN标题似乎是一项非常简单的任务.此外,该标准表示该策略在浏览器中强制执行,如果Access-Control-Allow-Origin不正确,则阻止响应.显然,如果有人试图获取该信息,他将不会使用标准浏览器来阻止它.
jco*_*der 145
目的是防止这种情况 -
我们的想法是,您的银行网站需要某种方式告诉您的浏览器是否应该信任网站X上的脚本来访问您银行的页面.
dan*_* f. 57
只是添加@jcoder的答案,Origin标题的全部内容,不是为了保护服务器上请求的资源,该任务是通过其他方式由服务器本身决定的,完全是因为攻击者确实可以欺骗这个标头与适当的工具.
Origin标题的要点是保护用户.方案如下:
攻击者创建恶意网站M.
一个用户Alice被欺骗连接到M,其中包含一个脚本,该脚本试图通过CORS在实际支持CORS的服务器B上执行某些操作
B可能在其Access-Control-Allow-Origin标题中没有M ,因为它为什么会这样？
关键的一点是,M无法欺骗或覆盖Origin标头,导致请求由Alice的浏览器启动.所以她的浏览器会将(正确)设置Origin为M,这不在Access-Control-Allow-OriginB中,因此请求将失败.
现在,爱丽丝可以Origin自己改变头部,但她为什么会这样,因为这意味着她会伤害自己？
TL; DR:Origin标题保护无辜的用户.它不保护资源.攻击者可以在自己的机器上进行欺骗,但不能在不受他控制的机器上进行欺骗.
服务器仍应保护其资源,因为匹配的Origin标头并不意味着授权访问.但是,Origin不匹配的标头意味着未经授权的访问.
Que*_*tin 47
它不是为了阻止人们获取数据.没有人得到它你就无法暴露它.
它被设计成给定:
如果Bob访问Charlie的网站,那么Charlie无法将JS发送到Bob的浏览器,以便从Alice的网站获取数据并将其发送给Charlie.
如果Bob在Alice的网站上有一个用户帐户,允许他做帖子评论或删除数据,上述情况就变得更加重要 - 因为没有保护,Charlie可以告诉Bob的浏览器在Bob的背后做这件事.
如果您想阻止未经授权的人员查看数据,则需要使用密码,SSL客户端证书或其他基于身份的身份验证/授权方法进行保护.
And*_*y E 15
同一原产地政策的目的不是阻止人们普遍访问网站内容; 如果有人想这样做,他们甚至不需要浏览器.关键是要停止客户端脚本访问另一个域上的内容而没有必要的访问权限.请参阅Wikipedia条目的Same Origin Policy.
在阅读了CORS之后,我不明白它是如何提高安全性的.
CORS不会提高安全性.CORS为服务器提供了一种机制,告诉浏览器外部域应该如何访问它们,并且它尝试以与CORS之前存在的浏览器安全模型(即同源策略)一致的方式这样做.
但同源策略和CORS的范围有限.具体来说,CORS规范本身没有拒绝请求的机制.它可以使用标头告诉浏览器不要让来自外部域的页面读取响应.并且,在预检请求的情况下,它可以要求浏览器不发送来自外部域的某些请求.但是CORS没有指定服务器拒绝(即不执行)实际请求的任何方法.
我们来举个例子吧.用户A通过cookie 登录到站点.用户加载恶意网站M,它试图提交,做了一个表格POST来A.会发生什么？好吧,无论是否有CORS,无论M是否允许域,浏览器都会A使用用户的授权cookie 发送请求,服务器将执行恶意操作POST,就像用户启动它一样.
这种攻击称为跨站点请求伪造,而CORS本身没有任何缓解它.这就是为什么如果您允许代表用户更改数据请求,CSRF保护如此重要.
现在,Origin标头的使用可以成为CSRF保护的重要组成部分.实际上,检查它是目前多管齐下的CSRF防御建议的一部分.但是Origin头部的使用超出了CORS规范.
总之,CORS是一个有用的规范,用于将现有的同源策略安全模型扩展到其他接受域.它不会增加安全性,站点需要与CORS之前相同的防御机制.