使用Typescript重构axios(二十四)——防御XSRF攻击

0. 系列文章

项目源码请猛戳这里!!!

1. 前言

XSRF，即跨站请求伪造，它是前端常见的一种攻击方式，关于它的攻击原理以及一些常用的防范措施可以猛戳这里查看，在这里我们主要介绍一种常用的防范措施，那就是在客户端与服务端首次登录确认身份成功后，服务端会颁发给客户端一个身份认证令牌，即token，客户端将其存储在cookie中，然后要求客户端以后每次请求都要携带此token，客户端往往会把这个toekn添加到请求的 headers 中，服务端接收到请求后，先从从请求 headers 中读取这个 token ，然后验证该token是否合法，如果合法则进行下一步操作，如果不合法，则直接拒绝服务。服务器端要求每次请求都包含一个 token，这个 token 不在前端生成，而是在我们每次访问站点的时候生成，并通过 set-cookie 的方式种到客户端，然后客户端发送请求的时候，从 cookie 中对应的字段读取出 token，然后添加到请求 headers 中。这样服务端就可以从请求 headers 中读取这个 token 并验证，由于这个 token 是很难伪造的，所以就能区分这个请求是否是用户正常发起的。

官方axios针对该防范措施已经为我们做好了一些基础工作，官方axios在默认请求配置对象中为我们提供了 xsrfCookieName 和 xsrfHeaderName这两个属性，其中 xsrfCookieName 表示存储 token 的 cookie 名称，xsrfHeaderName 表示请求 headers 中 token 对应的 header 名称。然后每次发送请求的时候，会自动从 cookie 中读取对应的 token 值，然后将其添加到请求 headers中。

接下来，我们也要为我们实现的axios添加该功能。

2. 思路分析

要实现跟官方axios一样的功能，首先我们先来分解一下功能，梳理一下实现的思路：

首先我们需要给请求配置对象config上添加 xsrfCookieName 和 xsrfHeaderName这两个属性的接口，并且将其写入默认请求配置对象中；
因为跨站请求伪造是由于进行了跨域请求才有了被攻击的可能，而如果是同域请求那就不存在这个问题，所以我们需要先判断该请求是否跨域；
由于上文所说的防范措施中需要携带cookie，所以我们还要判断上篇文章中添加的withCredentials 是否为 true ，因为该属性表示请求是否允许携带cookie，如果不允许携带，那就没法防御了；
如果上面两个判断都成功，则从cookie中根据xsrfCookieName 来获取到token值；
获取到以后，将token值添加到请求headers中，headers中的属性名叫xsrfHeaderName的属性值；

OK，以上就是实现的整体思路，下面，我们就按照思路一步一步实现该功能。

3. 向请求配置对象添加属性

请求配置对象config中添加 xsrfCookieName 和 xsrfHeaderName这两个属性之前，我们需要先在src/types/index.ts中的配置对象的接口类型定义AxiosRequestConfig上添加该属性的定义，如下：

export interface AxiosRequestConfig {
  // 新增
  xsrfCookieName?: string;
  xsrfHeaderName?: string
 
}

添加好属性接口后，我们还要给默认请求配置对象中添加这两个属性，并且属性的默认值跟官方axios保持一直，如下：

const defaults: AxiosRequestConfig = {
  // 新增
  xsrfCookieName: 'XSRF-TOKEN',
  xsrfHeaderName: 'X-XSRF-TOKEN',
};

4. 判断请求是否跨域

判断请求是否跨域，即判断当前页面的url与请求的url是否同源，所谓同源，即两者的域名，协议，端口均相同，如有一个不同即为跨域，官方axios对于判断是否跨域使用了一个很巧妙的办法，它通过创建一个a标签的 DOM，然后设置该a标签的 href属性为我们请求的的url，然后这样就可以获取到该 DOM的protocol、host、port。再把当前页面的 url也都通过这种方式获取，然后对比它们的 protocol 、host以及port` 是否都相同，进而判断出请求是否跨域。那么接下来，我们也使用这种方法来判断请求是否跨域。

我们在src/helpers目录下创建isURLSameOrigin.ts 文件，在该文件内创建isURLSameOrigin方法，用来判断请求是否跨域，如下：

interface URLOrigin {
  protocol: string;
  host: string;
  port: string;
}

export default function isURLSameOrigin(requestURL: string): boolean {
  let urlParsingNode = document.createElement("a");

  // 1.先获取当前页面地址的协议、域名、端口
  const currentOrigin = resolveURL(window.location.href);
  // 2.再获取请求url的协议、域名、端口
  const parsedOrigin = resolveURL(requestURL);

  // 3.最后比较三者是否相同
  return (
    parsedOrigin.protocol === currentOrigin.protocol &&
    parsedOrigin.host === currentOrigin.host &&
    parsedOrigin.port === currentOrigin.port
  );

  // 创建一个可以通过url获取协议、域名、端口的函数
  function resolveURL(url: string): URLOrigin {
    urlParsingNode.setAttribute("href", url);
    return {
      protocol: urlParsingNode.protocol
        ? urlParsingNode.protocol.replace(/:$/, "")
        : "",
      host: urlParsingNode.host,
      port: urlParsingNode.port
    };
  }
}

代码很简单，具体的细节也已经写进注释了。

判断完请求是否跨域，还要判断该请求的withCredentials 属性是否为 true，这个就比较好判断了，直接获取请求配置对象config里的withCredentials 属性再判断就好了，就不细说了，接下来，如果这两个判断都成功，那么就需要从cookie中根据xsrfCookieName属性的属性值作为token的键来获取到token的值；

5. 从cookie中获取token值

如果上面两个判断都成功，那么我们就需要根据请求配置对象中xsrfCookieName属性的属性值作为键名从cookie中来获取token的值，由于浏览器对cookie的操作不是很友好，所以我们先封装一个从cookie中根据键名来获取值的辅助函数，我们在src/helpers目录下创建cookies.ts文件，在该文件中实现该辅助函数，如下：

const cookie = {
  read(name: string): string | null {
    const match = document.cookie.match(
      new RegExp("(^|;\\s*)(" + name + ")=([^;]*)")
    );
    return match ? decodeURIComponent(match[3]) : null;
  }
};

export default cookie;

这个辅助函数实现过程很简单，就是在cookie中通过正则把传入的键名对应的值获取到。

有了这个辅助函数后，我们只需调用cookie.read(xsrfCookieName)就可以获取到token值了，获取到token值以后把它添加到请求headers中，headers中的属性名叫xsrfHeaderName的属性值。

6. 完整逻辑

分解步骤已经全部实现好了，接下来就需要将所有的分解步骤按照逻辑组合在一起，首先，我们需要明确这一系列都是在发请求之前完成的，而且我们在这里为headers增加了东西，所以我们需要把这段逻辑写在处理headers之前，我们在src/core/xhr.ts中添加如下逻辑：

const {
    // 新增
    xsrfCookieName,
    xsrfHeaderName
} = config;
let xsrfValue =
    (withCredentials || isURLSameOrigin(url!)) && xsrfCookieName
    ? cookies.read(xsrfCookieName)
    : undefined;

    if (xsrfValue) {
        headers[xsrfHeaderName!] = xsrfValue;
    }

OK，到此，我们就已经按照思路分析中将所有功能实现完毕了，接下来，我们就编写demo来测试效果如何。

7. demo编写

在 examples 目录下创建 defendXSRF目录，在 defendXSRF目录下创建 index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>defendXSRF demo</title>
  </head>
  <body>
    <script src="/__build__/defendXSRF.js"></script>
  </body>
</html>

接着再创建 app.ts 作为入口文件：

import axios from "../../src/axios";

axios
  .get("/api/defendXSRF", {
    xsrfCookieName: "XSRF-NLRX",
    xsrfHeaderName: "X-XSRF-NLRX",
    withCredentials: true
  })
  .then(res => {
    console.log(res);
  });

接着在 server/server.js 添加新的接口路由：

// 防御XSRF
router.get("/api/defendXSRF", function(req, res) {
  res.cookie("XSRF-NLRX", "NLRX");
  res.json(req.cookies);
});

在本demo中，我们为请求配置了xsrfCookieName、xsrfHeaderName以及withCredentials，并且在服务端给客户端种了 key 为 XSRF-NLRX，值为 NLRX 的 cookie，作为 xsrf 的 token 值。然后我们在前端发送请求的时候，就能从 cookie 中读出 key 为 XSRF-NLRX 的值，然后把它添加到 key 为 X-XSRF-NLRX的请求 headers 中。

最后在根目录下的index.html中加上启动该demo的入口：

<li><a href="examples/defendXSRF">defendXSRF</a></li>

OK,我们在命令行中执行：

# 同时开启客户端和服务端
npm run server | npm start

接着我们打开 chrome 浏览器，访问 http://localhost:8000/ 即可访问我们的 demo 了，我们点击 defendXSRF，通过F12的 network 部分我们可以看到：请求已经正常发出，并且在请求的头部有我们添加的token。

OK，以上就是为axios添加防御XSRF攻击的功能。

（完）

posted on 2019-08-19 15:51 难凉热血，码梦为生！阅读(2435) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

难凉热血，码梦为生！