浅析XSS与CSRF

在 Web 安全方面，XSS 与 CSRF 可以说是老生常谈了。

XSS

XSS，即 cross site script，跨站脚本攻击，缩写原本为 CSS，但为了和层叠样式表（Cascading Style Sheet）区分，改为 XSS。

XSS 攻击是指攻击者在网站上注入恶意脚本，使用户在浏览使用网页时进行恶意操作，注入脚本除了 JavaScript，还会有 CSS、HTML 等等。

XSS 攻击可以分为 3 种：反射型（非持久型）、存储型（持久型）、DOM型。

反射型

反射型的 XSS 攻击方式一般是攻击者诱使用户进行点击恶意链接、提交表单等等操作，从而达到注入脚本的目的。

举个例子，假设某页面会直接把搜索关键词拼接到 HTML 页面上显示出来：

<p>您搜索的关键词是：<?php showKeyword(keyword) ?></p>

当用户点击搜索后，会向服务端发送这样的请求http://example/search?keyword=xxx，然后服务端把 keyword 后面的字符进行 HTML 拼接然后返回。

这时，假如用户点击了一个恶意链接http://example/search?keyword=<script>xss攻击脚本</script>，那返回的 HTML 就会变成这样：

<p>您搜索的关键词是：<script>xss攻击脚本</script></p>

然后浏览器就会执行 script 里面 xss 攻击脚本，从而达到攻击者的攻击目的。

存储型

存储型的 XSS 攻击一般是攻击者将恶意代码作为输入的数据提交给服务端，然后服务端存储到数据库内，当有用户请求这个数据后，服务端返回的数据其实是恶意代码，从而发生 XSS 攻击。

比较常见的就是在论坛发帖、评论，然后在里面注入恶意代码，当用户点击帖子的时候，就会受到攻击。

DOM型

DOM型的 XSS 攻击一般是攻击者在注入恶意脚本后，修改页面元素，获取 DOM 的数据然后执行攻击操作。比如将用户的登录表单的提交换成攻击者的服务端，从而获取用户的登录信息。

防范 XSS

CSP 内容安全策略，主流浏览器都实现了 CSP。

配置内容安全策略涉及到添加 Content-Security-Policy HTTP头部到一个页面，并配置相应的值，以控制用户代理（浏览器等）可以为该页面获取哪些资源。比如一个可以上传文件和显示图片页面，应该允许图片来自任何地方，但限制表单的action属性只可以赋值为指定的端点。一个经过恰当设计的内容安全策略应该可以有效的保护页面免受跨站脚本攻击。 (MDN)
通过设置 HttpOnly 防止 Cookie 被读取。

前端对用户的输入进行检查转义，建立白名单，只允许安全的字符和 HTML 标签存在：

const HTML_DECODE = {

	'
': '\n',

  '&lt;'  : '<',

	'&gt;'  : '>',

	'&amp;' : '&',

  '&quot;': '"',

	'&nbsp;': ' ',

	'&quot;': '\'

	// more code

};

前端逻辑比较容易被绕过，所以后端也要对接收的数据进行检查过滤，并在输出或者拼接 HTML 的时候进行编码、转义。

CSRF

CSRF，即 cross site request forgery，跨站请求伪造，可以理解为重放攻击。比较常见的情况是，攻击者诱使用户打开钓鱼网站进行一些操作。

还是举一个例子来说明：假设某用户登录了www.a.com网站，然后在没有登出的情况下打开了钓鱼网站www.b.com，而钓鱼网站里面有恶意脚本，在被打开的时候就带着 Cookie 信息向www.a.com发送了跨域请求。

CSRF 的特点

CSRF 发起请求方式很多：图片URL、超链接、表单提交等。
与 XSS 攻击不同， CSRF 一般在第三方网站发起攻击。
CSRF 只是利用 http 请求自动携带用户的 Cookie 信息来通过验证，并不能获取 Cookie 信息。

CSRF 防范

对于重放攻击，其实前端是没什么办法进行处理的，主要靠后端。

Referer 字段

在 http 的请求头里，有一个 Referer 字段，记录了 http 请求的来源地址，服务端通过检查这个字段，判断请求是否来自合法地址。但需要注意的是，Referer 字段是由浏览器来进行添加的，所以存在被篡改的可能。
验证机制

通常 CSRF 是在用户不知情的情况下发送请求进行攻击的，所以可以利用验证机制强制用户与网站进行交互，例如发送验证码到用户的手机、邮箱，或者需要用户拼图、填写验证码等。但验证机制对于用户体验不太好，而且并不是所有操作都能加上验证的。
token

服务端在用户登录后，签发一个随机的 token，可以埋在页面中，也可以存储在 sessionStorage 中，然后在客户端设置拦截器，为所有请求加上 token，服务端再设置拦截器，检查请求是否拥有 token。因为同源策略（协议、域名、端口相同为同源）的原因，CSRF 并不能拿到 token。
```
let xhr = new XMLHttpRequest();

let token = sessionStorage.getItem('csrfToken');

xhr.setRequestHeader('CSRF-Token', token);
```
但需要注意的是， token 需要存储在服务端，需要服务端进行读取、验证 token。