这个设备就是域名白名单，规定在什么样的域名下才能进行AJAX跨域请求。

CORS Origin: *的安然性

关键问题来了，在膳绫擎的CORS设备是如许的：

SELECT * FROM  users  WHERE name = ' ' or 1=1  AND password = 'anything'  

Access-Control-Allow-Origin: http://xxx 

然则这个设备只许可特定域名拜访，鉴于前端的复杂性，有时刻调试起来不是很便利，是以有时刻，会偷懒的设置为：

Access-Control-Allow-Origin: * 

这个代表所有来源的跨域AJAX请求都能正常响应。

接下来我们再来分析设置Origin: *可能带来哪些问题。（都是基于AJAX的情况）

不会。固然*代表了所有来源都能正常请求，然则同源策略下，是无法带上跨域cookie的。是以根本无法用身份验证。

并且，就算用withCredentials强行带上跨域cookie，因为后台没有支撑，所以会报错。（这可以算作是CORSs模型的最后一道防地）

再者，后台就算设备Access-Control-Allow-Credentials许可跨域cookie，然则这时刻的安然策略是Origin不许可为*，必须是一个明白的地址。
（不然你就可以看到浏览器的报错信息-跨域cookie时，Origin不许可为*）

问题2：如不雅捏造Origin头部呢？

起首，标准的浏览器中是不许可你捏造的（除非有严重马脚），所以一般须要经由过程模仿客户端请求捏造。

然则。在非浏览器情况下，本来就没有同源策略。这又是何必。。。

固然很多时刻，都是经由多翻口舌之争后，最终后台那边让步，许可部分相符前提的AJAX请求。然则，我却很纠结一个问题：AJAX请求真的不安然么？为什愦我本身写后台时并没有发明这个问题？

所以说，捏造Origin与CORS并没有关系。

问题3：如不雅后台本来就存在马脚呢？

再假设内网办事器上刚巧存在敏感资本，并且没有额外设防，只要内网就能拜访。譬如：

192.168.111.23/users.md 

然后用户拜访了恶意网页，而像HTML之类的网页都是下载到本地履行的，
正好网页内有恶意代码，去向192.168.111.23/users.md请求资本，再将接收到的办事端返回发送到进击者办事器。
（因为加了Origin为*，并且AJAX是由本地浏览器发出的，所以用户下载到本地的恶意网站是可以拜访到用户内网中的后台的）

然后这些敏感数据就如许被窃取了。

But，这是因为办事端马脚而存在的问题，设置Origin为的后台上为何要放置敏感资本？正常设置为Origin为的最大年夜感化是用作公共API。
并且更重要的是，为何敏感资本就如许随便马虎的被获取了？为什么没有二次验证？

SO，后台本身有马脚，所以才导致被进击，AJAX正好是进击的手段之一（除了AJAX外还会有其它的方法），所以很多锅都甩到了AJAX头上。

Origin如不雅不是*，AJAX请求并不会有安然问题，如不雅是*，可能会因为后台的马脚，不经意间，AJAX就被作为一种进击手段了，导致了出现AJAX不安然的说法

再看，AJAX请求真的不安然么？

如不雅某个Web运器具备优胜的安然性，那么再怎么竽暌姑“不安然的AJAX”也减弱不了它的安然性，反之如不雅应用本身存在马脚，不管用何种技巧请求，它都是不安然的

我们可以看到，XSS也好，CSRF也好，以及其它隐蔽的可能马脚也好，本质上都是后台已有马脚造成的问题，AJAX最多是被用作一种进击手段（甚至某些琅绫擎AJAX还无法应用）

提到AJAX请求不安然的，譬如有CORS琅绫擎设备Origin: *造成某些极端情况下能经由过程AJAX发出进击。但事实上这也是个中的一种进击手段罢了，没有AJAX，该不安然的仍然不安然。

最重要一点，大年夜Web应用安然角度来谈，Web应用必须大年夜不信赖客户端。所以不要再把锅甩给AJAX。

AJAX请求哪里不安然？

同上，AJAX本身并不存在这种安然问题。

不过有一点需留意，如不雅应用了CORS筹划。

1. Allow-Origin可以设置特定的值，过滤特定的白名单

2. 对于一些公共的API，可以直接将Allow-Origin设置为`*`


怎么样让AJAX请求更安然？

CORS Origin: *的安然性