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攻擊的功能。

（完）

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 使用Typescript重構axios(二十九)——添加baseURL 使用Typescript重構axios(二十三)——添加withCredentials屬性使用Typescript重構axios(二十一)——請求取消功能：添加axios.isCancel接口使用Typescript重構axios(二十六)——添加HTTP授權auth屬性使用Typescript重構axios(二十八)——自定義序列化請求參數使用Typescript重構axios(二十五)——文件上傳下載進度監控使用Typescript重構axios(十五)——默認配置使用Typescript重構axios(十七)——增加axios.create接口使用Typescript重構axios(九)——異常處理：基礎版使用Typescript重構axios(一)——寫在最前面