AJAX请求真的不安全么？
AJAX请求哪里不安全？
怎么样让AJAX请求更安全？
前言
日前网络中流行围绕AJAX和安全风险的讨伐声浪让人不绝于耳。下面就来详细谈一谈Web安全与AJAX的关系。
本文包含的内容较多，包括AJAX，CORS，XSS，CSRF等内容，要完整的看完并理解需要付出一定的时间。
另外，见解有限，如有描述不当之处，请帮忙及时指出。
正文开始...
从入坑前端开始，一直到现在，AJAX请求都是以极高的频率重复出现，也解决过不少AJAX中遇到的问题，如跨域调试，错误调试等等。
从这种，发现了一个共通现象：那就是每次和后台人员对接时，他们都会提到AJAX请求不安全，请用普通http请求！
虽然很多时候，都是经过多翻口舌之争后，最终后台那边妥协，允许部分符合条件的AJAX请求。但是，我却很纠结一个问题：AJAX请求真的不安全么？为什么我自己写后台时并没有发现这个问题？
于是，开始准备搜集资料，结合自己已有的认知，整理成一份解决方案，分析AJAX请求真的不安全么？哪里不安全？，后续遇到类似的问题就直接向对方抛出一篇文章
大纲
AJAX请求真的不安全么
AJAX不安全的说法从何而来
常见的几种Web前端安全问题
CSRF简介
CSRF与AJAX的关系
XSS简介
XSS与AJAX的关系
SQL注入简介
SQL注入与AJAX的关系
AJAX和HTTP请求的区别
CORS与AJAX安全性之间的关联
CORS与AJAX关系的简介
为什么要配置CORS？
CORS会配置些什么信息？
CORS Origin: *的安全性
再看，AJAX请求真的不安全么？
AJAX请求哪里不安全？
怎么样让AJAX请求更安全？
AJAX请求真的不安全么
首先，先说一个定论：AJAX请求是否安全，由服务端（后台）决定
有这样一个说法：如果某个Web应用具备良好的安全性，那么再怎么用“不安全的AJAX”也削弱不了它的安全性，反之如果应用本身存在漏洞，不管用何种技术请求，它都是不安全的
为何会有这种说法？因为在Web应用中，客户端输入不可信是一个基本原则
AJAX不安全的说法从何而来？
在AJAX出现时，那时的服务端还是很古老的那一批，因此完全没有考虑到AJAX出现后，前端请求方式会变得异常复杂，造成以前的安全策略已经无法满足要求了，导致大批的后台安全漏洞曝光。。。
很显然，都是因为AJAX出现后曝光了更多的安全漏洞，导致它看起来很危险（因为AJAX出现后，请求方式变多了，以前的架构在新的请求中就可能出现更多漏洞）
So，AJAX不安全的说法自然扩散到了各个角落。
常见的几种Web前端安全问题
要知道AJAX请求是否安全，那么就得先知道Web前端中到底有那几种安全问题
1.XSS（跨站脚本攻击）（cross-site scripting） -> 伪造会话（基于XSS实现CSRF） -> 劫持cookie -> 恶意代码执行 2.CSRF（跨站请求伪造）（cross-site request forgery） -> 伪造用户身份操作 3. SQL注入 ...（其它暂且不提）
如上，Web前端中的安全问题主要就是这几大类（仅列举部分做分析），所以我们首先要分析AJAX与这几大类之间的关系。（XSS和CSRF，在下文也会做简单介绍。）
CSRF简介
CSRF，特征很简单：冒用用户身份，进行恶意操作
时至今日，这项安全漏洞已经被人们剖析的很透彻了，随便Google，百度之，都会找到很多的解释。这里也用一张图来先做简单描述：
（注，下面介绍参考了来源文章中的描述，譬如图就是参考了来源中的博文后重绘的）
所以，我们看到关键条件是：
1. 采用cookie来进行用户校验
2. 登录受信任网站A，并在本地生成Cookie
3. 在不登出A的情况下，访问危险网站B
一般在(4)处恶意网站(B)的攻击手段如下（必须是指向A的地址，否则无法带上cookie）：
// 1.譬如在网站内的图片资源中潜入恶意的转账操作 <img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000> // 2.构建恶意的隐藏表单，并通过脚本提交恶意请求 <iframe></iframe> <form method='POST' action='http://www.bank.example/transfer' target="csrf-frame"> <input type='hidden' value='hello'> <input type='hidden' value='1000000'> <input type='submit' value='submit'> </form> <script>document.getElementById("csrf-form").submit()</script>
而且，从头到尾，攻击网站都没有获取到过 cookie，都是通过浏览器间接实现（利用Web的cookie隐式身份验证机制），所以HttpOnly并不会影响这个攻击
最后说下，几种常见的CSRF防御手段：
1. 验证HTTP Referer字段（非常简单，但是鉴于客户端并不可信任，所以并不是很安全）
（防止CSRF，检查Referer字段简单直接，但是其完全依赖浏览器发送正确的Referer字段。