Space Shuttle

注意安全（2）！XSRF跨站伪造请求

发表于 | 分类于 ，
上一篇我们说了用脚本注入去攻击小熊哥的博文评论。普通的脚本注入很容易就被前端后台全方位的脚本过滤给处理掉，完全没有杀伤力。一般来说遇到<, > , =” 等等可能加载执行脚本的用户输入，转换为&lt ; & gt ; 等等即可作为数据打印到 DOM 中，而不是作为脚本执行。详细情况参考上一篇文章 。我敢保证，@Swanky 肯定是受了我的蛊惑去 POST 了 三万多条评论导致被 @简书首席封号官 封号了。

伪造请求的过程


这次来说说伪造请求（Cross Site Request Forgery）的事情。通俗点讲就是 有人给你发送了一个链接，然后你手贱点开，是看起来很正常的网页（A.com/index.html），结果暗中被发送了一个指向 招商银行转账服务(B.com/transfer) 的POST请求，这个请求是攻击者在A.com/index.html 脚本中伪造的，因此请求的发送方属于A.com域，而不属于B.com/transfer 的域， 所以叫做 跨站伪造请求

1
2
3
4
5
6
7
8
// attack.html. 为了在这个伪造的网页中自动发送请求并且带上 受害用户的cookie，
// 一般都会在hidden iframe中加载一份正规网站的页面，而且攻击表单也是隐藏的。
// 表面上这个伪造网页是很正规的，并无异常。
  <form id="thisForm" method="POST" target="_blank" action="http://www.bank.com/transfer">
        <input type="text" name="name" value="csrf_Attack2!!!">
  </form>
  <iframe name="tab" src="http://www.bank.com" style="display:none;"> 
  </iframe>

XSRF 原理


XSRF的关键就是 假如正规网站（B.com）的服务器端没有防御机制，只是对于发来的请求做用户身份验证，那么伪造请求就可以借用受害者浏览器自动发送的cookie蒙混过关，实行恶意攻击。其中有几个问题需要明确：

  1. 用户身份信息一般通过Http Request 的头部cookie 字段的值来传递，cookie中往往包含sessionid 这样的用户会话信息，服务器通过比对服务端内存或数据库（Redis等）中维持的session就可以知道是哪个用户在发请求，Session有无过期。 这一过程一般不验证请求发送方的 域。
  2. 跨站伪造请求成功的前提是 B.com 提供了可供跨域调用的服务。因为我们知道大部分浏览器和服务器都禁止脚本请求跨域资源，这种行为一般不太安全。但是我非得请求呢？？ 所以除了用JSONP 来GET跨域资源，更有采用CORS（Cross-origin resource sharing，跨域资源共享是W3C标准）来实现POST，PUT请求跨域的。 CORS的详细介绍可以参考这里.

通常情况下，假如服务器端开启CORS配置允许任何来源的请求，就很难分辨接收到的请求是用户自主发送的（往往是和B.com同一个域下的网页），还是攻击者冒充用户身份伪造的攻击请求（往往不同域，例如A.com）。

一休哥自制 XSRF 图示

XSRF防御——Token


经过上面的介绍，其实防御的办法大概都可以推断出来了。关键就是区分来自于各种域的请求，哪些是合法用户发送的，哪些是被借用了身份发送来的。

第一种方式：配置服务器的CORS，只允许白名单的域发来请求，这样最直接。只要白名单的网站不被攻击注入恶意脚本就基本安全了。以nodejs和express为例，配置如下：

1
2
3
4
5
6
7
app.all('*', function(req, res, next) {
   // 如果用"*", 表示接受任何域发来的请求, 这里只配置一个域名
   res.header("Access-Control-Allow-Origin", "www.icbc.com");
   res.header("Access-Control-Allow-Headers", "X-Requested-With, accept, origin, content-type");
   res.header("Access-Control-Allow-Methods", "PUT,POST,OPTIONS");
   next();
}

另外一种方式: bank.com 的服务器端和客户端通力合作，协商一个除了Session之外的二次身份验证——Token。

Token验证的原理是：每次用户登陆成功，就根据SessionID和特定算法生成一个Token，发回客户端（动态添加到一个隐藏域中，例如 input 或者JS变量中），合法客户端在随后的请求中加入Token作为数据体，服务器端每次接受请求都要去验证SessionID 和 Token，双保险。以nodejs为例，服务端关键代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 当用户登录验证成功时，随即生成与该用户Session绑定的Token
req.session.key = (Math.random()* Math.pow(10, 17));
var crsfToken = generateToken(parseInt(req.session.key).toString());
// 返回token给客户端，客户端将token动态添加至DOM或者变量中
res.send({"status": returnData, "refreshpage": redirectpage, "token": crsfToken});
// return Hex string as token. 
// 加密算法远比这个复杂。这里只是演示，这样也很难猜出token
function generateToken(sess) {
  var tk = "", a = 0.834415, b = 1.214414, c = 1.83121;
  for(var i=0; i < sess.length; i++){
    var baseNum = parseInt(sess[i]);
    tk += (a * Math.pow(baseNum, b) + c).toFixed(0);
  }
  var tkNum = parseInt(tk);
  return tkNum.toString(16);
}
// 当收到请求后，除了验证session，再根据session计算一次token，比对客户端发来的是否一致。
// check Token to prevent XSRF... 
function checkToken(session, params) {
  var validToken = generateToken(session.name);
  if (params.token && params.token == validToken) {
    return true;
  } else {
    console.error("CSRF Token not valid! Attack Found !!");
    return false;
  }
}

再补充一点，因为冒充身份的请求一般都是趁受害者处于登录状态了，所以DOM中没有Token，而经过合法登录后才会有Token存在。这样就较好地防御了跨站伪造请求攻击。

写在最后

现如今，网络安全形势越来越严峻，作为一个Web前端工程师，之前很少注意这一点。至此已经更新了两篇 跟前端工程师相关的网络安全 笔记了。希望大家喜欢本文，有所收获。

传送门：注意安全第一篇 XSS 跨站脚本注入

另外一篇很棒的英文参考 CSRF Attacks, XSRF or Sea-Surf – What They Are and How to Defend Against Them