一、XSS
（一）XSS 原理
Xss(cross-site scripting) 攻击：全称跨站脚本攻击，通过向某网站写入 js 脚本或插入恶意 html 标签来实现攻击。
比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取 cookie 中的用户私密信息；
或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。
（二）主要危害
- 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
- 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
- 盗窃企业重要的具有商业价值的资料
- 非法转账
- 强制发送电子邮件
- 网站木马
- 控制受害者机器向其它网站发起攻击
（三）XSS 攻击的类型
分为存储性（持久型）、反射型（非持久型）、基于 DOM
1、存储性（持久型）
存储型 XSS，也叫持久型 XSS，主要是将 XSS 代码发送到服务器（不管是数据库、内存还是文件系统等。），然后在下次请求页面的时候就不用带上 XSS 代码了。用户输入的带有恶意脚本的数据存储在服务器端。当浏览器请求数据时，服务器返回脚本并执行。
最典型的就是留言板 XSS。用户提交了一条包含 XSS 代码的留言到数据库。当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来。浏览器发现有 XSS 代码，就当做正常的 HTML 和 JS 解析执行。XSS 攻击就发生了。
常见的场景：
- 窃取用户信息，如 cookie，token，账号密码等。例如：张三发了一篇帖子，李四进行回复，但内容却是一段 js 脚本，这篇帖子被他人浏览的时候就会中招，盗用用户 cookie 等等操作
- 除了这种 hacker 还有个很惯用的伎俩，例如存储型 XSS 生成一些诱人的图片，文字（你懂的！），然后用户去点击的时候就可以执行某些坏事，窃取信息或者诱导到钓鱼网站。
- 劫持流量实现恶意跳转
用户打开的网址，会默认跳转至指定网站
2、反射型（非持久型）
反射型 XSS，也叫非持久型 XSS，把用户输入的数据 “反射” 给浏览器。通常是，用户点击链接或提交表单时，攻击者向用户访问的网站注入恶意脚本。XSS 代码出现在请求 URL 中，作为参数提交到服务器，服务器解析并响应。响应结果中包含 XSS 代码，最后浏览器解析并执行。从概念上可以看出，反射型 XSS 代码是首先出现在 URL 中的，然后需要服务端解析，最后需要浏览器解析之后 XSS 代码才能够攻击。
常见的场景：
-
在正常页面上添加一个恶意链接。恶意链接的地址指向 localhost:8080。然后攻击者有一个 node 服务来处理对 localhost:8080 的请求:
-
当用户点击恶意链接时，页面跳转到攻击者预先准备的 localhost:8080 页面，执行了 恶意的 js 脚本，产生攻击。
举例：
- Alice 给 Bob 发送一个恶意构造了 Web 的 URL。
- Bob 点击并查看了这个 URL。
- 恶意页面中的 JavaScript 打开一个具有漏洞的 HTML 页面并将其安装在 Bob 电脑上。
- 具有漏洞的 HTML 页面包含了在 Bob 电脑本地域执行的 JavaScript。
- Alice 的恶意脚本可以在 Bob 的电脑上执行 Bob 所持有的权限下的命令。
3、基于 DOM
基于 DOM 的 XSS 是指通过恶意脚本修改页面的 DOM 结构。是纯粹发生在 客户端的攻击。
（四）XSS 防范方法
1. 内容安全策略 (CSP)
它是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段。
其实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。
常见的策略：
- 入参字符过滤，在源头控制，把输入的一些不合法的东西都过滤掉，从而保证安全性。
- 出参进行编码，如果源头没控制好，就得后期补救了：像一些常见的符号，如 <> 在输出的时候要对其进行转换编码，这样做浏览器是不会对该标签进行解释执行的，同时也不影响显示效果。
- 入参长度限制，通过以上的案例我们不难发现 xss 攻击要能达成往往需要较长的字符串，因此对于一些可以预期的输入可以通过限制长度强制截断来进行防御。
两种方法可以启用 CSP：
- 设置 HTTP 的 Content-Security-Policy 头部字段
- 设置网页的<meta> 标签。
2.HttpOnly 阻止 Cookie 劫持攻击
服务器端 Set-Cookie 字段设置 HttpOnly 参数，这样可以避免。这时候，客户端的 Document.cookie API 无法访问带有 HttpOnly 标记的 Cookie, 但可以设置 cookie。
注：发起 XSS 的攻击者既然可以通过注入恶意脚本获取用户的 Cookie 信息。所以，严格来说，HttpOnly 并非阻止 XSS 攻击，而是能阻止 XSS 攻击后的 Cookie 劫持攻击。
二、CSRF
（一）原理
CSRF (Cross Site Request Forgery)，跨站请求伪造。
CSRF 攻击是攻击者借助用户的 Cookie 骗取服务器的信任，以用户名义伪造请求发送给服务器。如：在请求的 url 后加入一些恶意的参数
换句话说，CSRF 就是利用用户的登录态发起恶意请求。
（二）攻击过程
-
用户 C 打开浏览器，访问受信任网站 A，输入用户名和密码请求登录网站 A；
-
在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 成功，可以正常发送请求到网站 A；
-
用户未退出网站 A 之前，在同一浏览器中，打开一个新的标签页访问网站 B；
-
网站 B 接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问站点 A；
-
浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。
（三）场景
假设某银行网站 A 以 GET 请求来发起转账操作，转账的地址为 www.xxx.com/transfer.do?accountNum=l000l&money=10000，参数 accountNum 表示转账的账户，参数 money 表示转账金额。
而某大型论坛 B 上，一个恶意用户上传了一张图片，而图片的地址栏中填的并不是图片的地址，而是前而所说的转账地址：<img src="http://www.xxx.com/transfer.do?accountNum=l000l&money=10000">
当你登录网站 A 后，没有及时登出，这时你访问了论坛 B，不幸的事情发生了，你会发现你的账号里面少了 10000 块…
注：上述只是举例呦，转账怎么可能是 get 请求，为了保险，肯定是 post 请求，更何况银行的交易付款会有登录密码和支付密码等一系列屏障，流程复杂得多，安全系数也高得多
（四）防范措施
1、Referer Check
在 HTTP 头中有一个字段叫做 Referer, 它记录了该 HTTP 请求的来源地址。通过 Referer Check, 可以检查是否来自合法的 “源”.
例如：
从 www.user.com 发起的删帖请求，那么 Referer 值是 http://www.user.com, 删帖请求应该被允许；
而如果是从 CSRF 攻击者构造的页面 www.attack.com 发起删帖请求， 那么 Referer 值是 http://www.attack.com, 删帖请求应该被阻止。
缺点：
Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。
2、添加 token 验证
在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，若请求无 token 或者 token 不正确，则认为可能是 CSRF 攻击而拒绝该请求。
缺点：
在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
3、验证码
验证码会强制用户必须与应用进行交互，才能完成最终请求，但是也不能给网站所有的操作都加上验证码，所以只能作为防御 CSRF 的一种辅助手段，而不能作为最终的解决方案
三、XSS 和 CSRF 区别：
- XSS 是利用用户对指定网站的信任
- CSRF 是利用网站对用户的信任
