Col*_*der 4 javascript security cors
我假设在cors请求中默认阻止自定义标头是为了防止某种攻击.
这个假设是否正确？如果是这样,那攻击是什么？
来自https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
在CORS中,发送带有OPTIONS方法的预检请求,以便服务器可以响应是否可以使用这些参数发送请求.Access-Control-Request-Method标头作为预检请求的一部分通知服务器,当发送实际请求时,它将使用POST请求方法发送.
在浏览器的跨域限制的目的是不会导致服务器允许脚本跨域XHR /抓取请求使用由默认比浏览器已经允许的图片,脚本和样式表请求更多做任何事img,script和link元素.
当在原点A的文档或应用程序的HTML标记中放置一个img,script或者link来自原点B的嵌入图像,脚本或样式表的元素时,您无法在对该图像,脚本的请求上设置自定义标题,或来自B的样式表.
因此,脚本化跨源XHR/Fetch请求的默认浏览器行为旨在匹配由img/ script/ linkmarkup 启动的请求中固有的相同行为/限制.
这里的工作原理是不要破坏某人在服务器端代码中做出的任何假设,即他们不会接收来自浏览器中运行的文档/应用程序的请求,这些文档/应用程序包含自定义标题或者做任何其他人无法做的事情img/ script/ link.
但CORS协议的目的是允许服务器选择加入比默认行为更不严格的东西.因此,他们可以选择对请求标头采用不太严格的行为的具体方式是,他们可以选择发送Access-Control-Allow-Headers并使用它来定制/调整/控制他们想要允许脚本化的跨源XHR/Fetch请求的请求标头.
但如果他们不通过选择发送来选择加入Access-Control-Allow-Headers,那么他们可以确信浏览器不会允许来自前端JavaScript代码的脚本化跨域XHR/Fetch请求执行令人惊讶/意外的事情他们没有选择 -在...
而且要明确的是,强加默认限制不是"CORS".相反,这些限制只是浏览器遵循的默认同源策略的一部分,并且如https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy和https:/中所述. /en.wikipedia.org/wiki/Same-origin_policy.因此,CORS只是一种允许服务器选择何时要求浏览器对特定资源使用不太严格的限制的方法.
| 归档时间： |
|
| 查看次数： |
724 次 |
| 最近记录： |