我试图理解为什么CORS正在以它的工作方式工作.
正如我从this post那里了解到,当www.a.com的页面向www.b.com发出AJAX请求时,那么www.b.com决定是否允许请求.
但是在这种模型中客户端的确切安全性是什么？
例如,如果黑客成功向我的页面注入XSS脚本,那么它会向其域发出一个AJAX请求来存储用户数据.因此,黑客的域名将允许这样的请求.
我认为www.a.com应决定允许请求的域名.因此理论上,在头文件Access-Control-Allow-Origin中,我想放置允许AJAX CORS请求的域的完整列表.
有人可以解释当前CORS实现处理的安全问题吗？
解决方法:
As I learned from this post, when page from
www.a.commakes AJAX request towww.b.com, then it’s thewww.b.comthat decides if request should be allowed or not.
不完全的.请求未被阻止.
默认情况下,www.a.com上运行的JavaScript禁止访问www.b.com的响应.
CORS允许www.b.com从www.a.com获得JavaScript的访问权限以访问响应.
But what is exactly secured on client in such model?
它阻止www.a.com的作者使用访问过这两个站点的用户的浏览器从www.b.com上读取数据,并且已经在www.b.com上进行了身份验证(因此可以访问不是’公共).
例如,Alice已登录Google. Alice访问使用XMLHttpRequest从gmail.com访问数据的malicIoUs.example. Alice拥有GMail帐户,因此回复中包含收件箱中最新电子邮件的列表.相同的源策略可防止恶意.example读取它.
For example, hacker success to make XSS script injection to my page, then it makes AJAX request to his domain to store user data. So hackers domain will allow such request for sure.
正确. XSS是一个不同的安全问题,需要在源头处解决(即在www.a.com而不是在浏览器中).
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
