【前端安全】JavaScript防http劫持與XSS

做爲前端，一直以來都知道HTTP劫持與XSS跨站腳本（Cross-site scripting）、CSRF跨站請求僞造（Cross-site request forgery）。可是一直都沒有深刻研究過，前些日子同事的分享會偶然說起，我也對這一塊很感興趣，便深刻研究了一番。

最近用 JavaScript 寫了一個組件，能夠在前端層面防護部分 HTTP 劫持與 XSS。

固然，防護這些劫持最好的方法仍是從後端入手，前端能作的實在太少。並且因爲源碼的暴露，攻擊者很容易繞過咱們的防護手段。可是這不表明咱們去了解這塊的相關知識是沒意義的，本文的許多方法，用在其餘方面也是大有做用。

已上傳到 Github – httphijack.js ，歡迎感興趣看看順手點個 star ，本文示例代碼，防範方法在組件源碼中皆可找到。

接下來進入正文。

 

HTTP劫持、DNS劫持與XSS

先簡單講講什麼是 HTTP 劫持與 DNS 劫持。

HTTP劫持

什麼是HTTP劫持呢，大多數狀況是運營商HTTP劫持，當咱們使用HTTP請求請求一個網站頁面的時候，網絡運營商會在正常的數據流中插入精心設計的網絡數據報文，讓客戶端（一般是瀏覽器）展現「錯誤」的數據，一般是一些彈窗，宣傳性廣告或者直接顯示某網站的內容，你們應該都有遇到過。

DNS劫持

DNS 劫持就是經過劫持了 DNS 服務器，經過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，致使對該域名的訪問由原IP地址轉入到修改後的指定IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現竊取資料或者破壞原有正常服務的目的。

DNS 劫持比之 HTTP 劫持 更加過度，簡單說就是咱們請求的是 http://www.a.com/index.html ，直接被重定向了 http://www.b.com/index.html ，本文不會過多討論這種狀況。

XSS跨站腳本

XSS指的是攻擊者利用漏洞，向 Web 頁面中注入惡意代碼，當用戶瀏覽該頁之時，注入的代碼會被執行，從而達到攻擊的特殊目的。

關於這些攻擊如何生成，攻擊者如何注入惡意代碼到頁面中本文不作討論，只要知道如 HTTP 劫持 和 XSS 最終都是惡意代碼在客戶端，一般也就是用戶瀏覽器端執行，本文將討論的就是假設注入已經存在，如何利用 Javascript 進行行之有效的前端防禦。

 

頁面被嵌入 iframe 中，重定向 iframe

先來講說咱們的頁面被嵌入了 iframe 的狀況。也就是，網絡運營商爲了儘量地減小植入廣告對原有網站頁面的影響，一般會經過把原有網站頁面放置到一個和原頁面相同大小的 iframe 裏面去，那麼就能夠經過這個 iframe 來隔離廣告代碼對原有頁面的影響。

這種狀況還比較好處理，咱們只須要知道咱們的頁面是否被嵌套在 iframe 中，若是是，則重定向外層頁面到咱們的正常頁面便可。

那麼有沒有方法知道咱們的頁面當前存在於 iframe 中呢？有的，就是 window.self 與 window.top 。

window.self

返回一個指向當前 window 對象的引用。

window.top

返回窗口體系中的最頂層窗口的引用。

對於非同源的域名，iframe 子頁面沒法經過 parent.location 或者 top.location 拿到具體的頁面地址，可是能夠寫入 top.location ，也就是能夠控制父頁面的跳轉。

兩個屬性分別能夠又簡寫爲 self 與 top，因此當發現咱們的頁面被嵌套在 iframe 時，能夠重定向父級頁面：

if (self != top) {
  // 咱們的正常頁面
  var url = location.href;
  // 父級頁面重定向
  top.location = url;
}

　　

使用白名單放行正常 iframe 嵌套

固然不少時候，也許運營須要，咱們的頁面會被以各類方式推廣，也有多是正常業務須要被嵌套在 iframe 中，這個時候咱們須要一個白名單或者黑名單，當咱們的頁面被嵌套在 iframe 中且父級頁面域名存在白名單中，則不作重定向操做。

上面也說了，使用 top.location.href 是沒辦法拿到父級頁面的 URL 的，這時候，須要使用document.referrer。

經過 document.referrer 能夠拿到跨域 iframe 父頁面的URL。

// 創建白名單
var whiteList = [
  'www.aaa.com',
  'res.bbb.com'
];

if (self != top) {
  var
    // 使用 document.referrer 能夠拿到跨域 iframe 父頁面的 URL
    parentUrl = document.referrer,
    length = whiteList.length,
    i = 0;

  for(; i<length; i++){
    // 創建白名單正則
    var reg = new RegExp(whiteList[i],'i');

    // 存在白名單中，放行
    if(reg.test(parentUrl)){
      return;
    }
  }

  // 咱們的正常頁面
  var url = location.href;
  // 父級頁面重定向
  top.location = url;
}

 

更改 URL 參數繞過運營商標記

這樣就完了嗎？沒有，咱們雖然重定向了父頁面，可是在重定向的過程當中，既然第一次能夠嵌套，那麼這一次重定向的過程當中頁面也許又被 iframe 嵌套了，真尼瑪蛋疼。

固然運營商這種劫持一般也是有跡可循，最常規的手段是在頁面 URL 中設置一個參數，例如 http://www.example.com/index.html?iframe_hijack_redirected=1 ，其中 iframe_hijack_redirected=1 表示頁面已經被劫持過了，就再也不嵌套 iframe 了。因此根據這個特性，咱們能夠改寫咱們的 URL ，使之看上去已經被劫持了：

var flag = 'iframe_hijack_redirected';
// 當前頁面存在於一個 iframe 中
// 此處須要創建一個白名單匹配規則，白名單默認放行
if (self != top) {
  var
    // 使用 document.referrer 能夠拿到跨域 iframe 父頁面的 URL
    parentUrl = document.referrer,
    length = whiteList.length,
    i = 0;

  for(; i<length; i++){
    // 創建白名單正則
    var reg = new RegExp(whiteList[i],'i');

    // 存在白名單中，放行
    if(reg.test(parentUrl)){
      return;
    }
  }

  var url = location.href;
  var parts = url.split('#');
  if (location.search) {
    parts[0] += '&' + flag + '=1';
  } else {
    parts[0] += '?' + flag + '=1';
  }
  try {
    console.log('頁面被嵌入iframe中:', url);
    top.location.href = parts.join('#');
  } catch (e) {}
}

固然，若是這個參數一改，防嵌套的代碼就失效了。因此咱們還須要創建一個上報系統，當發現頁面被嵌套時，發送一個攔截上報，即使重定向失敗，也能夠知道頁面嵌入 iframe 中的 URL，根據分析這些 URL ，不斷加強咱們的防禦手段，這個後文會說起。

 

內聯事件及內聯腳本攔截

在 XSS 中，其實能夠注入腳本的方式很是的多，尤爲是 HTML5 出來以後，一不留神，許多的新標籤均可以用於注入可執行腳本。

列出一些比較常見的注入方式：

1. <a href="javascript:alert(1)" ></a>
2. <iframe src="javascript:alert(1)" />
3. <img src='x' onerror="alert(1)" />
4. <video src='x' onerror="alert(1)" ></video>
5. <div onclick="alert(1)" onmouseover="alert(2)" ><div>

除去一些未列出來的很是少見生僻的注入方式，大部分都是 javascript:... 及內聯事件 on*。

咱們假設注入已經發生，那麼有沒有辦法攔截這些內聯事件與內聯腳本的執行呢？

對於上面列出的 (1) (5) ，這種須要用戶點擊或者執行某種事件以後才執行的腳本，咱們是有辦法進行防護的。

瀏覽器事件模型

這裏說可以攔截，涉及到了事件模型相關的原理。

咱們都知道，標準瀏覽器事件模型存在三個階段：

• 捕獲階段
• 目標階段
• 冒泡階段

對於一個這樣 <a href="javascript:alert(222)" ></a> 的 a 標籤而言，真正觸發元素 alert(222) 是處於點擊事件的目標階段。

點擊上面的 click me ，先彈出 111 ，後彈出 222。

那麼，咱們只須要在點擊事件模型的捕獲階段對標籤內 javascript:... 的內容創建關鍵字黑名單，進行過濾審查，就能夠作到咱們想要的攔截效果。

對於 on* 類內聯事件也是同理，只是對於這類事件太多，咱們沒辦法手動枚舉，能夠利用代碼自動枚舉，完成對內聯事件及內聯腳本的攔截。

以攔截 a 標籤內的 href="javascript:... 爲例，咱們能夠這樣寫：

// 創建關鍵詞黑名單
var keywordBlackList = [
  'xss',
  'BAIDU_SSP__wrapper',
  'BAIDU_DSPUI_FLOWBAR'
];
  
document.addEventListener('click', function(e) {
  var code = "";

  // 掃描 <a href="javascript:"> 的腳本
  if (elem.tagName == 'A' && elem.protocol == 'javascript:') {
    var code = elem.href.substr(11);

    if (blackListMatch(keywordBlackList, code)) {
      // 註銷代碼
      elem.href = 'javascript:void(0)';
      console.log('攔截可疑事件:' + code);
    }
  }
}, true);

/**
 * [黑名單匹配]
 * @param  {[Array]} blackList [黑名單]
 * @param  {[String]} value    [須要驗證的字符串]
 * @return {[Boolean]}         [false -- 驗證不經過，true -- 驗證經過]
 */
function blackListMatch(blackList, value) {
  var length = blackList.length,
    i = 0;

  for (; i < length; i++) {
    // 創建黑名單正則
    var reg = new RegExp(whiteList[i], 'i');

    // 存在黑名單中，攔截
    if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

能夠戳我查看DEMO。(打開頁面後打開控制檯查看 console.log) 

點擊圖中這幾個按鈕，能夠看到以下：

這裏咱們用到了黑名單匹配，下文還會細說。

 

靜態腳本攔截

XSS 跨站腳本的精髓不在於「跨站」，在於「腳本」。

一般而言，攻擊者或者運營商會向頁面中注入一個<script>腳本，具體操做都在腳本中實現，這種劫持方式只須要注入一次，有改動的話不須要每次都從新注入。

咱們假定如今頁面上被注入了一個 <script src="http://attack.com/xss.js"> 腳本，咱們的目標就是攔截這個腳本的執行。

聽起來很困難啊，什麼意思呢。就是在腳本執行前發現這個可疑腳本，而且銷燬它使之不能執行內部代碼。

因此咱們須要用到一些高級 API ，可以在頁面加載時對生成的節點進行檢測。

 

MutationObserver

MutationObserver 是 HTML5 新增的 API，功能很強大，給開發者們提供了一種能在某個範圍內的 DOM 樹發生變化時做出適當反應的能力。

說的很玄乎，大概的意思就是可以監測到頁面 DOM 樹的變換，並做出反應。

MutationObserver() 該構造函數用來實例化一個新的Mutation觀察者對象。

MutationObserver(
  function callback
);

目瞪狗呆，這一大段又是啥？意思就是 MutationObserver 在觀測時並不是發現一個新元素就當即回調，而是將一個時間片斷裏出現的全部元素，一塊兒傳過來。因此在回調中咱們須要進行批量處理。並且，其中的 callback 會在指定的 DOM 節點(目標節點)發生變化時被調用。在調用時,觀察者對象會傳給該函數兩個參數，第一個參數是個包含了若干個 MutationRecord 對象的數組，第二個參數則是這個觀察者對象自己。

因此，使用 MutationObserver ，咱們能夠對頁面加載的每一個靜態腳本文件，進行監控：

// MutationObserver 的不一樣兼容性寫法
var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || 
window.MozMutationObserver;
// 該構造函數用來實例化一個新的 Mutation 觀察者對象
// Mutation 觀察者對象能監聽在某個範圍內的 DOM 樹變化
var observer = new MutationObserver(function(mutations) {
  mutations.forEach(function(mutation) {
    // 返回被添加的節點,或者爲null.
    var nodes = mutation.addedNodes;

    for (var i = 0; i < nodes.length; i++) {
      var node = nodes[i];
      if (/xss/i.test(node.src))) {
        try {
          node.parentNode.removeChild(node);
          console.log('攔截可疑靜態腳本:', node.src);
        } catch (e) {}
      }
    }
  });
});

// 傳入目標節點和觀察選項
// 若是 target 爲 document 或者 document.documentElement
// 則當前文檔中全部的節點添加與刪除操做都會被觀察到
observer.observe(document, {
  subtree: true,
  childList: true
});

能夠看到以下：能夠戳我查看DEMO。(打開頁面後打開控制檯查看 console.log)

<script type="text/javascript" src="./xss/a.js"></script> 是頁面加載一開始就存在的靜態腳本（查看頁面結構），咱們使用 MutationObserver 能夠在腳本加載以後，執行以前這個時間段對其內容作正則匹配，發現惡意代碼則 removeChild() 掉，使之沒法執行。

 

使用白名單對 src 進行匹配過濾

上面的代碼中，咱們判斷一個js腳本是不是惡意的，用的是這一句：

if (/xss/i.test(node.src)) {}

固然實際當中，注入惡意代碼者不會那麼傻，把名字改爲 XSS 。因此，咱們頗有必要使用白名單進行過濾和創建一個攔截上報系統。 

// 創建白名單
var whiteList = [
  'www.aaa.com',
  'res.bbb.com'
];

/**
 * [白名單匹配]
 * @param  {[Array]} whileList [白名單]
 * @param  {[String]} value    [須要驗證的字符串]
 * @return {[Boolean]}         [false -- 驗證不經過，true -- 驗證經過]
 */
function whileListMatch(whileList, value) {
  var length = whileList.length,
    i = 0;

  for (; i < length; i++) {
    // 創建白名單正則
    var reg = new RegExp(whiteList[i], 'i');

    // 存在白名單中，放行
    if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

// 只放行白名單
if (!whileListMatch(blackList, node.src)) {
  node.parentNode.removeChild(node);
}　

這裏咱們已經屢次提到白名單匹配了，下文還會用到，因此能夠這裏把它簡單封裝成一個方法調用。

 

動態腳本攔截

上面使用 MutationObserver 攔截靜態腳本，除了靜態腳本，與之對應的就是動態生成的腳本。

var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'http://www.example.com/xss/b.js';

document.getElementsByTagName('body')[0].appendChild(script);　

要攔截這類動態生成的腳本，且攔截時機要在它插入 DOM 樹中，執行以前，原本是能夠監聽 Mutation Events 中的 DOMNodeInserted 事件的。

 

Mutation Events 與 DOMNodeInserted

打開 MDN ，第一句就是:

該特性已經從 Web 標準中刪除，雖然一些瀏覽器目前仍然支持它，但也許會在將來的某個時間中止支持，請儘可能不要使用該特性。

雖然不能用，也能夠了解一下：

document.addEventListener('DOMNodeInserted', function(e) {
  var node = e.target;
  if (/xss/i.test(node.src) || /xss/i.test(node.innerHTML)) {
    node.parentNode.removeChild(node);
    console.log('攔截可疑動態腳本:', node);
  }
}, true);

然而惋惜的是，使用上面的代碼攔截動態生成的腳本，能夠攔截到，可是代碼也執行了:DOMNodeInserted 顧名思義，能夠監聽某個 DOM 範圍內的結構變化，與 MutationObserver 相比，它的執行時機更早。

可是 DOMNodeInserted 再也不建議使用，因此監聽動態腳本的任務也要交給 MutationObserver。

惋惜的是，在實際實踐過程當中，使用 MutationObserver 的結果和 DOMNodeInserted 同樣，能夠監聽攔截到動態腳本的生成，可是沒法在腳本執行以前，使用 removeChild 將其移除，因此咱們還須要想一想其餘辦法。

 

重寫 setAttribute 與 document.write

重寫原生 Element.prototype.setAttribute 方法

在動態腳本插入執行前，監聽 DOM 樹的變化攔截它行不通，腳本仍然會執行。

那麼咱們須要向上尋找，在腳本插入 DOM 樹前的捕獲它，那就是建立腳本時這個時機。

假設如今有一個動態腳本是這樣建立的：

var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'http://www.example.com/xss/c.js');

document.getElementsByTagName('body')[0].appendChild(script);

而重寫 Element.prototype.setAttribute 也是可行的：咱們發現這裏用到了 setAttribute 方法，若是咱們可以改寫這個原生方法，監聽設置 src 屬性時的值，經過黑名單或者白名單判斷它，就能夠判斷該標籤的合法性了。

// 保存原有接口
var old_setAttribute = Element.prototype.setAttribute;

// 重寫 setAttribute 接口
Element.prototype.setAttribute = function(name, value) {

  // 匹配到 <script src='xxx' > 類型
  if (this.tagName == 'SCRIPT' && /^src$/i.test(name)) {
    // 白名單匹配
    if (!whileListMatch(whiteList, value)) {
      console.log('攔截可疑模塊:', value);
      return;
    }
  }
  
  // 調用原始接口
  old_setAttribute.apply(this, arguments);
};

// 創建白名單
var whiteList = [
'www.yy.com',
'res.cont.yy.com'
];

/**
 * [白名單匹配]
 * @param  {[Array]} whileList [白名單]
 * @param  {[String]} value    [須要驗證的字符串]
 * @return {[Boolean]}         [false -- 驗證不經過，true -- 驗證經過]
 */
function whileListMatch(whileList, value) {
  var length = whileList.length,
    i = 0;

  for (; i < length; i++) {
    // 創建白名單正則
    var reg = new RegExp(whiteList[i], 'i');

    // 存在白名單中，放行
    if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

能夠看到以下結果：能夠戳我查看DEMO。(打開頁面後打開控制檯查看 console.log)

重寫 Element.prototype.setAttribute ，就是首先保存原有接口，而後當有元素調用 setAttribute 時，檢查傳入的 src 是否存在於白名單中，存在則放行，不存在則視爲可疑元素，進行上報並不予以執行。最後對放行的元素執行原生的 setAttribute ，也就是 old_setAttribute.apply(this, arguments);。

上述的白名單匹配也能夠換成黑名單匹配。

 

重寫嵌套 iframe 內的 Element.prototype.setAttribute

固然，上面的寫法若是 old_setAttribute = Element.prototype.setAttribute 暴露給攻擊者的話，直接使用old_setAttribute 就能夠繞過咱們重寫的方法了，因此這段代碼必須包在一個閉包內。

固然這樣也不保險，雖然當前窗口下的 Element.prototype.setAttribute 已經被重寫了。可是仍是有手段能夠拿到原生的 Element.prototype.setAttribute ，只須要一個新的 iframe 。

var newIframe = document.createElement('iframe');
document.body.appendChild(newIframe);

Element.prototype.setAttribute = newIframe.contentWindow.Element.prototype.setAttribute;

經過這個方法，能夠從新拿到原生的 Element.prototype.setAttribute ，由於 iframe 內的環境和外層 window 是徹底隔離的。wtf?

怎麼辦？咱們看到建立 iframe 用到了 createElement，那麼是否能夠重寫原生 createElement 呢？可是除了createElement 還有 createElementNS ，還有多是頁面上已經存在 iframe，因此不合適。

那就在每當新建立一個新 iframe 時，對 setAttribute 進行保護重寫，這裏又有用到 MutationObserver ：

/**
 * 使用 MutationObserver 對生成的 iframe 頁面進行監控，
 * 防止調用內部原生 setAttribute 及 document.write
 * @return {[type]} [description]
 */
function defenseIframe() {
  // 先保護當前頁面
  installHook(window);
}

/**
 * 實現單個 window 窗口的 setAttribute保護
 * @param  {[BOM]} window [瀏覽器window對象]
 * @return {[type]}       [description]
 */
function installHook(window) {
  // 重寫單個 window 窗口的 setAttribute 屬性
  resetSetAttribute(window);

  // MutationObserver 的不一樣兼容性寫法
  var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;

  // 該構造函數用來實例化一個新的 Mutation 觀察者對象
  // Mutation 觀察者對象能監聽在某個範圍內的 DOM 樹變化
  var observer = new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
      // 返回被添加的節點,或者爲null.
      var nodes = mutation.addedNodes;

      // 逐個遍歷
      for (var i = 0; i < nodes.length; i++) {
        var node = nodes[i];

        // 給生成的 iframe 裏環境也裝上重寫的鉤子
        if (node.tagName == 'IFRAME') {
          installHook(node.contentWindow);
        }
      }
    });
  });

  observer.observe(document, {
    subtree: true,
    childList: true
  });
}

/**
 * 重寫單個 window 窗口的 setAttribute 屬性
 * @param  {[BOM]} window [瀏覽器window對象]
 * @return {[type]} [description]
 */
function resetSetAttribute(window) {
  // 保存原有接口
  var old_setAttribute = window.Element.prototype.setAttribute;

  // 重寫 setAttribute 接口
  window.Element.prototype.setAttribute = function(name, value) {
    ...
  };
}　

咱們定義了一個 installHook 方法，參數是一個 window ，在這個方法裏，咱們將重寫傳入的 window 下的 setAttribute ，而且安裝一個 MutationObserver ，並對此窗口下將來可能建立的 iframe 進行監聽，若是將來在此 window 下建立了一個 iframe ，則對新的 iframe 也裝上 installHook 方法，以此進行層層保護。

 

重寫 document.write

根據上述的方法，咱們能夠繼續挖掘一下，還有什麼方法能夠重寫，以便對頁面進行更好的保護。

document.write 是一個很不錯選擇，注入攻擊者，一般會使用這個方法，往頁面上注入一些彈窗廣告。

咱們能夠重寫 document.write ，使用關鍵詞黑名單對內容進行匹配。

什麼比較適合當黑名單的關鍵字呢？咱們能夠看看一些廣告不少的頁面：

這裏在頁面最底部嵌入了一個 iframe ，裏面裝了廣告代碼，這裏的最外層的 id 名id="BAIDU_SSP__wrapper_u2444091_0" 就很適合成爲咱們判斷是不是惡意代碼的一個標誌，假設咱們已經根據攔截上報收集到了一批黑名單列表：

// 創建正則攔截關鍵詞
var keywordBlackList = [
'xss',
'BAIDU_SSP__wrapper',
'BAIDU_DSPUI_FLOWBAR'
];

接下來咱們只須要利用這些關鍵字，對 document.write 傳入的內容進行正則判斷，就能肯定是否要攔截document.write 這段代碼。　

```javascript
// 創建關鍵詞黑名單
var keywordBlackList = [
  'xss',
  'BAIDU_SSP__wrapper',
  'BAIDU_DSPUI_FLOWBAR'
];

/**
 * 重寫單個 window 窗口的 document.write 屬性
 * @param  {[BOM]} window [瀏覽器window對象]
 * @return {[type]}       [description]
 */
function resetDocumentWrite(window) {
  var old_write = window.document.write;

  window.document.write = function(string) {
    if (blackListMatch(keywordBlackList, string)) {
      console.log('攔截可疑模塊:', string);
      return;
    }

    // 調用原始接口
    old_write.apply(document, arguments);
  }
}

/**
 * [黑名單匹配]
 * @param  {[Array]} blackList [黑名單]
 * @param  {[String]} value    [須要驗證的字符串]
 * @return {[Boolean]}         [false -- 驗證不經過，true -- 驗證經過]
 */
function blackListMatch(blackList, value) {
  var length = blackList.length,
    i = 0;

  for (; i < length; i++) {
    // 創建黑名單正則
    var reg = new RegExp(whiteList[i], 'i');

    // 存在黑名單中，攔截
    if (reg.test(value)) {
      return true;
    }
  }
  return false;
} 

咱們能夠把 resetDocumentWrite 放入上文的 installHook 方法中，就能對當前 window 及全部生成的 iframe 環境內的 document.write 進行重寫了。

 

鎖死 apply 和 call

接下來要介紹的這個是鎖住原生的 Function.prototype.apply 和 Function.prototype.call 方法，鎖住的意思就是使之沒法被重寫。

這裏要用到 Object.defineProperty ，用於鎖死 apply 和 call。

 

Object.defineProperty

Object.defineProperty() 方法直接在一個對象上定義一個新屬性，或者修改一個已經存在的屬性， 並返回這個對象。

Object.defineProperty(obj, prop, descriptor)

其中: 

• obj – 須要定義屬性的對象
• prop – 需被定義或修改的屬性名
• descriptor – 需被定義或修改的屬性的描述符

咱們可使用以下的代碼，讓 call 和 apply 沒法被重寫。

// 鎖住 call
Object.defineProperty(Function.prototype, 'call', {
  value: Function.prototype.call,
  // 當且僅當僅當該屬性的 writable 爲 true 時，該屬性才能被賦值運算符改變
  writable: false,
  // 當且僅當該屬性的 configurable 爲 true 時，該屬性纔可以被改變，也可以被刪除 
  configurable: false,
  enumerable: true
});
// 鎖住 apply
Object.defineProperty(Function.prototype, 'apply', {
  value: Function.prototype.apply,
  writable: false,
  configurable: false,
  enumerable: true
});　

爲啥要這樣寫呢？其實仍是與上文的 重寫 setAttribute 有關。

雖然咱們將原始 Element.prototype.setAttribute 保存在了一個閉包當中，可是還有奇技淫巧能夠把它從閉包中給「偷出來」。

試一下：

(function() {})(
	// 保存原有接口
	var old_setAttribute = Element.prototype.setAttribute;
	// 重寫 setAttribute 接口
	Element.prototype.setAttribute = function(name, value) {
		// 具體細節
		if (this.tagName == 'SCRIPT' && /^src$/i.test(name)) {}
		// 調用原始接口
		old_setAttribute.apply(this, arguments);
	};
)();
// 重寫 apply
Function.prototype.apply = function(){
	console.log(this);
}
// 調用 setAttribute
document.getElementsByTagName('body')[0].setAttribute('data-test','123');　

猜猜上面一段會輸出什麼？看看：

竟然返回了原生 setAttribute 方法！

這是由於咱們在重寫 Element.prototype.setAttribute 時最後有 old_setAttribute.apply(this, arguments);這一句，使用到了 apply 方法，因此咱們再重寫 apply ，輸出 this ，當調用被重寫後的 setAttribute 就能夠從中反向拿到原生的被保存起來的 old_setAttribute 了。

這樣咱們上面所作的嵌套 iframe 重寫 setAttribute 就毫無心義了。

使用上面的 Object.defineProperty 能夠鎖死 apply 和 相似用法的 call 。使之沒法被重寫，那麼也就沒法從閉包中將咱們的原生接口偷出來。這個時候纔算真正意義上的成功重寫了咱們想重寫的屬性。

 

創建攔截上報

防護的手段也有一些了，接下來咱們要創建一個上報系統，替換上文中的 console.log() 日誌。

上報系統有什麼用呢？由於咱們用到了白名單，關鍵字黑名單，這些數據都須要不斷的豐富，靠的就是上報系統，將每次攔截的信息傳到服務器，不只可讓咱們程序員第一時間得知攻擊的發生，更可讓咱們不斷收集這類相關信息以便更好的應對。

這裏的示例我用 nodejs 搭一個十分簡易的服務器接受 http 上報請求。

先定義一個上報函數：

/**
 * 自定義上報 -- 替換頁面中的 console.log()
 * @param  {[String]} name  [攔截類型]
 * @param  {[String]} value [攔截值]
 */
function hijackReport(name, value) {
  var img = document.createElement('img'),
    hijackName = name,
    hijackValue = value.toString(),
    curDate = new Date().getTime();

  // 上報
  img.src = 'http://www.reportServer.com/report/?msg=' + hijackName + '&value=' + hijackValue + '&time=' + curDate;
}

假定咱們的服務器地址是 www.reportServer.com 這裏，咱們運用 img.src 發送一個 http 請求到服務器http://www.reportServer.com/report/ ，每次會帶上咱們自定義的攔截類型，攔截內容以及上報時間。

用 Express 搭 nodejs 服務器並寫一個簡單的接收路由：

var express = require('express');
var app = express();

app.get('/report/', function(req, res) {
	var queryMsg = req.query.msg,
		queryValue = req.query.value,
		queryTime = new Date(parseInt(req.query.time));

	if (queryMsg) {
		console.log('攔截類型：' + queryMsg);
	}

	if (queryValue) {
		console.log('攔截值：' + queryValue);
	}

	if (queryTime) {
		console.log('攔截時間：' + req.query.time);
	}
});

app.listen(3002, function() {
	console.log('HttpHijack Server listening on port 3002!');
});

運行服務器，當有上報發生，咱們將會接收到以下數據：

好接下來就是數據入庫，分析，添加黑名單，使用 nodejs 固然攔截髮生時發送郵件通知程序員等等，這些就再也不作展開。

 

HTTPS 與 CSP

最後再簡單談談 HTTPS 與 CSP。其實防護劫持最好的方法仍是從後端入手，前端能作的實在太少。並且因爲源碼的暴露，攻擊者很容易繞過咱們的防護手段。

CSP

CSP 便是 Content Security Policy，翻譯爲內容安全策略。這個規範與內容安全有關，主要是用來定義頁面能夠加載哪些資源，減小 XSS 的發生。

MDN – CSP

HTTPS

可以實施 HTTP 劫持的根本緣由，是 HTTP 協議沒有辦法對通訊對方的身份進行校驗以及對數據完整性進行校驗。若是能解決這個問題，則劫持將沒法輕易發生。

HTTPS，是 HTTP over SSL 的意思。SSL 協議是 Netscape 在 1995 年首次提出的用於解決傳輸層安全問題的網絡協議，其核心是基於公鑰密碼學理論實現了對服務器身份認證、數據的私密性保護以及對數據完整性的校驗等功能。

由於與本文主要內容關聯性不大，關於更多 CSP 和 HTTPS 的內容能夠自行谷歌。

 

本文到此結束，我也是涉獵前端安全這個方面不久，文章必然有所紕漏及錯誤，文章的方法也是衆多防護方法中的一小部分，許多內容參考下面文章，都是精品文章，很是值得一讀：

• 《web前端黑客技術揭祕》
• XSS 前端防火牆系列1~3
• 【HTTP劫持和DNS劫持】實際JS對抗
• 淺談DNS劫持
• HTTP Request Hijacking

 

使用 Javascript 寫的一個防劫持組件，已上傳到 Github – httphijack.js，歡迎感興趣看看順手點個 star ，本文示例代碼，防範方法在組件源碼中皆可找到。

另外組件處於測試修改階段，未在生產環境使用，並且使用了不少 HTML5 才支持的 API，兼容性是個問題，僅供學習交流。

到此本文結束，若是還有什麼疑問或者建議，能夠多多交流，原創文章，文筆有限，才疏學淺，文中如有不正之處，萬望告知。