为什么“相同来源策略"不阻止POST请求? [英] Why does the Same Origin Policy not block POST requests?

查看:278
本文介绍了为什么“相同来源策略"不阻止POST请求?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我了解跨域,简单"始终允许GET和POST之类的请求(但您只是无法查看响应),并且PUT/DELETE被阻止,或者如果您的浏览器支持CORS,则该请求已预检.

I understand that cross-origin, "simple" requests, like GET and POST have always been allowed (but you just can't view the response), and that PUT/DELETE are blocked, or preflighted if your browser supports CORS.

我了解,只要响应被阻止,允许发送GET请求都是无害的,因为GET请求应该 是安全/幂等的(如果不是,那是开发人员的不当行为他们的API更新).

I understand that allowing a GET request to be sent is harmless, as long as the response is blocked, because GET requests should be safe/idempotent (if not, that's the developer's fault for not making their API ReSTful).

我从答案中也了解到,GET和POST是用户提出的典型/有意请求,例如在键入时在URL文本框中输入内容,或单击按钮以发布表单.

I also understand from this answer, that GET and POST are typical/intentional requests made by users, eg when typing something into the URL textbox or clicking a button to post a form.

但是为什么浏览器会允许使用xhr进行跨域POST请求?

But why would a browser allow a cross-origin POST request using xhr?

那么,如果用户可以通过单击发布表单的按钮发出有意的POST请求,该怎么办? 允许javascript发送POST请求是灾难的秘诀,任何加载的恶意页面都可以在后台执行跨源POST请求.

So what if the user can make intentional POST requests by clicking on a button to post a form? Allowing javascript to send a POST request is a recipe for disaster, any malicious page that loads could execute a cross-origin POST request behind the scenes.

为什么浏览器从一开始就没有阻止它?

Why didn't browsers prevent this from the beginning?

如果这样做了,那么现在CORS已经存在,可以像PUT/DELETE一样对POST请求进行预检,并且您的xsrf攻击也将更少.

If they did, then now that CORS is around, POST requests could be preflighted just like PUT/DELETE and you'd have fewer xsrf attacks.

推荐答案

如果取消使用POST的功能,将大大降低Web应用程序的功能,而不会显着提高安全性.

Eliminating the ability to use POST would have drastically reduced the capabilities of web applications without providing a significant increase in security.

如果没有POST,将无法请求另一个域修改数据. (请记住,这是在CORS提供选择加入跨域请求之前.)这消除了有用的Web应用程序的整个类. (或者更有可能的是,Web应用程序可以通过滥用GET来解决此问题.)

Without POST there would have been no way to request that another domain modify data. (Remember, this is before CORS offered a way to opt in to cross-domain requests.) That eliminates whole classes of useful web applications. (Or, more likely, web applications would have worked around this problem by abusing GET.)

您将不会为此牺牲任何回报.任何可能受到跨域XHR POST损害的服务器都必须已经具有CSRF保护,以应对来自POST形式的跨域攻击.以及此类防御措施(例如需要特殊令牌)对两者都同样有效.

And you wouldn't get much in return for this sacrifice. Any server that could be harmed by a cross-domain XHR POST would already have to have CSRF protections in place to deal with cross-domain attacks from a form POST. And such defenses (like requiring a special token) are equally effective against both.

这篇关于为什么“相同来源策略"不阻止POST请求?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆