3. 所以AJAX中如果给那个字段传入非法的注入信息，就会触发这个漏洞，导致攻击生效
对，就是这样极端的情况下才会发生，而且与AJAX并没有关系，因为换成任何一种其它请求都会有类似的情况。。。
所以说，结论是：SQL注入与AJAX无关
AJAX和HTTP请求的区别
从本质上将：AJAX就是浏览器发出的HTTP请求，只不过是浏览器加上了一个同源策略限制而已。
AJAX请求的XMLHTTPRequest对象就是浏览器开放给JS调用HTTP请求用的。
那么AJAX和HTTP的区别呢？列出以下几点：
AJAX请求受到浏览器的同源策略限制，存在跨域问题
AJAX在进行复杂请求时，浏览器会预先发出OPTIONS预检（HTTP自己是不会预检的）
从使用角度上说，AJAX使用简单一点，少了些底层细节，多了些浏览器特性（如自动带上同域cookie等）
所以说，和认证上的HTTP请求的区别就是-多了一次浏览器的封装而已（浏览器会有自己的预处理，加上特定限制）
但是，从最终发出的报文来看，内容都是一样的（HTTP协议规范的内容），AJAX是发送HTTP请求的一种方式
所以从这一点可以得出一个结论：AJAX本质上安全性和HTTP请求一样
CORS与AJAX安全性之间的关联
按照前文中提到的内容，基本无法得出AJAX与请求不安全的关联。那么接下来，再继续分析，如果使用了跨域资源共享（CORS）后的安全性。
(因为往往ajax都会伴随着CORS)
CORS与AJAX关系的简介
这是一个跨域共享方案，大致流程就是：（仅以复杂请求的预检举例-这一部分要求提前掌握CORS相关知识）
1. 前端AJAX请求前发出一个OPTIONS预检，会带一堆相关头部发送给服务端
2. 服务端在接受到预检时，检查头部，来源等信息是否合法，合法则接下来允许正常的请求，否则直接无情的拒绝掉
3. 浏览器端如果收到服务端拒绝的信息（响应头部检查），就抛出对应错误。
否则就是正常的响应，接下来发出真正的请求（如POST）
请求和响应的头部信息大概如下：
Request Headers
// 在CORS中专门作为Origin信息供后端比对，表示来源域。 Origin: Access-Control-Request-Headers: X-Requested-With // 所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中，一般POST请求中就会带上 Access-Control-Request-Method: OPTIONS
Response Headers
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Origin:
最终，客户端发出的请求，必须符合服务端的校验规则才能正确，服务端才会返回正确头部，否则只会请求失败。报跨域错误。
以上仅是简介，更多信息可以参考来源中的ajax跨域，这应该是最全的解决方案了
为什么要配置CORS？
因为同源策略限制，AJAX无法请求跨域资源，CORS可以解决AJAX跨域请求问题。
因此：在本文中，配置CORS只是为了AJAX能跨域请求
CORS会配置些什么信息？
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Origin:
如上，加上这个配置后，必须符合要求的才算是正常的请求，否则就会拒绝掉，一般AJAX跨域的话都会有OPTIONS，所以在预检中就做了这一步。
可以看到，关键的可变信息是：Access-Control-Allow-Origin:
这个配置就是域名白名单，规定在什么样的域名下才能进行AJAX跨域请求。
CORS Origin: *的安全性
关键问题来了，在上面的CORS配置是这样的：
Access-Control-Allow-Origin:
但是这个配置只允许特定域名访问，鉴于前端的复杂性，有时候调试起来不是很方便，因此有时候，会偷懒的设置为：
Access-Control-Allow-Origin: *
这个代表所有来源的跨域AJAX请求都能正常响应。
接下来我们再来分析设置Origin: *可能带来哪些问题。（都是基于AJAX的情况）
问题1：会对cookie认证造成影响么？
不会。虽然*代表了所有来源都能正常请求，但是同源策略下，是无法带上跨域cookie的。因此根本无法用身份验证。
而且，就算用withCredentials强行带上跨域cookie，因为后台没有支持，所以会报错。（这可以看成是CORSs模型的最后一道防线）
再者，后台就算配置Access-Control-Allow-Credentials允许跨域cookie，但是这时候的安全策略是Origin不允许为*，必须是一个明确的地址。
（否则你就可以看到浏览器的报错信息-跨域cookie时，Origin不允许为*）
问题2：如果伪造Origin头部呢？
首先，标准的浏览器中是不允许你伪造的（除非有严重漏洞），所以一般需要通过模拟客户端请求伪造。
但是。在非浏览器情况下，本来就没有同源策略。这又是何必。。。
所以说，伪造Origin与CORS并没有关系。
问题3：如果后台本来就存在漏洞呢？
做这样一个假设，假设用户所在网络的内网中有一台内网服务器，并且配置了允许所有的跨域请求：（当然，外网是请求不到内网的）
// 允许任何来自任意域的跨域请求 Access-Control-Allow-Origin: *
再假设内网服务器上恰巧存在敏感资源，并且没有额外设防，只要内网就能访问。譬如：
192.168.111.23/users.md