大家好，又见面了，我是你们的朋友全栈君。

1 XSS

1.1 名词解释

XSS，即：Cross Site Script，中译是跨站脚本攻击；其原本缩写是 CSS，但为了和网站前端技术领域——层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS。

1.2 作用原理

XSS是注入攻击的一种，其特点是不对服务器端造成任何伤害。
XSS 攻击是指攻击者在网站上注入恶意的客户端代码，通过恶意脚本对客户端网页进行篡改，从而导致：在用户浏览网页时，如果客户端浏览器或者服务器端没有过滤或转义掉这些脚本，而是将其作为内容发布到了页面上，则其他用户访问这个页面的时候就会运行这些脚本。
攻击者对客户端网页注入的恶意脚本一般包括 JavaScript，有时也会包含 HTML 和 Flash。有很多种方式进行 XSS 攻击，但它们的共同点为：将一些隐私数据像 cookie、session发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。
XSS攻击可以分为3类：反射型（非持久型）、存储型（持久型）、基于DOM。

1.3 防范措施

我们不需要用户输入HTML而只想让他们输入纯文本，那么把所有用户输入进行HTML转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。
大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击都是由于疏漏。建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。

2 CSRF/XSRF

2.1 名词解释

CSRF，即：Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
XSS是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF，即：Cross Site Request Forgery，中译是跨站请求伪造。

2.2 作用原理

通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。
CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而并不一定都是站内。所以我们唯有一条路可行，就是过滤请求的处理者。

2.3 防范措施

当前，对 CSRF 攻击的防范措施主要有如下几种方式。

2.3.1 验证码

验证码被认为是对抗 CSRF 攻击最简洁而有效的防御方法。
CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求。因为通常情况下，验证码能够很好地遏制 CSRF 攻击。
但验证码并不是万能的，因为出于用户考虑，不能给网站所有的操作都加上验证码。因此，验证码只能作为防御 CSRF 的一种辅助手段，而不能作为最主要的解决方案。

2.3.2 Referer Check

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。通过 Referer Check，可以检查请求是否来自合法的”源”。
比如，如果用户要删除自己的帖子，那么先要登录 www.c.com，然后找到对应的页面，发起删除帖子的请求。此时，Referer 的值是 http://www.c.com；当请求是从 www.a.com 发起时，Referer 的值是 http://www.a.com 了。因此，要防御 CSRF 攻击，只需要对于每一个删帖请求验证其 Referer 值，如果是以 www.c.com 开头的域名，则说明该请求是来自网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是 CSRF 攻击，可以拒绝该请求。
对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用REST风格的API接口设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE请求方法，我们可以使用ajax提交请求。也可以使用隐藏域指定请求方法，然后用POST模拟PUT和DELETE（Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚。

2.3.3 添加 token 验证(token==令牌)

CSRF 攻击之所以能够成功，是因为攻击者可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 Cookie 中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的 Cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求，返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。

3 CORS

3.1 名词解释

CORS是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）。它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

3.2 作用原理

由于跨域访问的允许，因此，即使服务器本机域上阻止了XSS威胁，攻击者还可以利用其他任意子域上XSS漏洞（如客户第三方业
务系统），发送跨域请求到目标重要域网站，从而获取敏感内容。

3.3 防范措施

现代浏览器默认都会基于安全原因而阻止跨域的ajax请求，这是现代浏览器中必备的功能，但是往往给开发带来不便。
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求(not-so-simple request)。

3.3.1 简单请求

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。
Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

3.3.2 非简单请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。
浏览器发现，这是一个非简单请求，就自动发出一个”预检”请求，要求服务器确认可以这样请求。
“预检”请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。
除了Origin字段，”预检”请求的头信息包括两个特殊字段。

—————————————————————————————
参考文献：
【1】https://blog.csdn.net/ccyutaotao/article/details/78348567；
【2】https://blog.csdn.net/luojinbai/article/details/50763182.