從JS文件中發現「認證繞過」漏洞

譯：h4d35

預估稿費：120RMB

投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿

前言

本篇文章主要介紹了在一次漏洞懸賞項目中如何利用配置錯誤挖到一個認證繞過漏洞。

從JS文件中發現認證繞過漏洞

本文內容源自一個私有漏洞賞金計劃。在這個漏洞計劃中，接受的漏洞范圍限于目標網站少數幾個公開的功能。基于前期發現的問題（當我被邀請進這個計劃時，其他人一共提交了5個漏洞），似乎很難再挖到新的漏洞。同時，在賞金詳情中提到了這樣一句話：

如果你成功進入管理頁面，請立即報告，請勿在/admin中進行進一步的測試。

然而，目標網站中存在一個僅限于未認證和未經授權的用戶訪問的管理頁面。當我們訪問/login或/admin時會跳轉到https://bountysite.com/admin/dashboard?redirect=/。

對登錄頁面進行暴力破解也許是一個可行方案，但是我并不喜歡這種方式。看一下網頁源碼，沒什么有用的內容。于是我開始查看目標網站的結構。似乎目標網站的JS文件都放在少數幾個文件夾中，如/lib、/js、/application等。

有意思！

祭出神器BurpSuite，使用Intruder跑一下看能否在上述文件夾中找到任何可訪問的JS文件。將攻擊點設置為https://bountysite.com/admin/dashboard/js/*attack*.js。注意，不要忘記.js擴展名，這樣如果文件能夠訪問則返回200響應。確實有意思！因為我找到了一些可訪問的JS文件，其中一個文件是/login.js。

訪問這個JS文件https://bountysite.com/admin/dashboard/js/login.js，請求被重定向至管理頁面:) 。但是，我并沒有查看該文件的權限，只能看到部分接口信息。

但是我并沒有就此止步。這看起來很奇怪，為什么我訪問一個.js文件卻被作為HTML加載了呢？經過一番探查，終于發現，我能夠訪問管理頁面的原因在于*login*。是的，只要在請求路徑/dashboard/后的字符串中含有*login*（除了'login'，這只會使我回到登錄頁面），請求就會跳轉到這個管理接口，但是卻沒有正確的授權。

我繼續對這個受限的管理接口進行了進一步的測試。再一次查看了頁面源碼，試著搞清楚網站結構。在這個管理接口中，有其他一些JS文件能夠幫助我理解管理員是如何執行操作的。一些管理操作需要一個有效的令牌。我試著使用從一個JS文件中泄露的令牌執行相關管理操作，然并卵。請求還是被重定向到了登錄頁面。我發現另外一個真實存在的路徑中也部署了一些內容，那就是/dashboard/controllers/*.php。

再一次祭出BurpSuite，使用Intruder檢查一下是否存在可以從此處訪問的其他任何路徑。第二次Intruder的結果是，我發現幾乎不存在其他無需授權即可訪問的路徑。這是基于服務器返回的500或者200響應得出的結論。

回到我在上一步偵察中了解到的網站結構中，我發現這些路徑是在/controllers中定義的，通過/dashboard/*here*/進行訪問。但是直接訪問這些路徑會跳轉到登錄頁面，似乎網站對Session檢查得還挺嚴格。此時我又累又困，幾乎都打算放棄了，但是我想最后再試一把。如果我利用與訪問管理頁面相同的方法去執行這些管理操作會怎么樣呢？很有趣，高潮來了:) 我能夠做到這一點。

通過訪問/dashboard/photography/loginx，請求跳轉到了Admin Photography頁面，并且擁有完整的權限！

從這里開始，我能夠執行和訪問/dashboard/*路徑下的所有操作和目錄，這些地方充滿了諸如SQL注入、XSS、文件上傳、公開重定向等漏洞。但是，我沒有繼續深入測試，因為這些都不在賞金計劃之內，根據計劃要求，一旦突破管理授權限制，應立即報告問題。此外，根據管理頁面顯示的調試錯誤信息可知，我之所以能夠訪問到管理頁面，是因為應用程序在/dashboard/controllers/*文件中存在錯誤配置。期望達到的效果是：只要請求鏈接中出現*login*，就重定向至主登錄頁面，然而，實際情況并不如人所愿。

后記

總之，這是有趣的一天！我拿到了這個漏洞賞金計劃最大金額的獎勵。

程語言都會需要完善的錯誤處理策略使得應用程序更為合理的操作錯誤。錯誤處理在服務端的處理較為完善，但是瀏覽器端進展較為緩慢，不同瀏覽器的錯誤處理方式也不同，且默認的錯誤處理方式對用戶也不友好。因此，必須理解各種捕獲和處理錯誤的方式。而在 ECMA-262 的第3版中增加了 try-catch 語句塊和 throw 語句來處理錯誤，以及一些錯誤類型來描述錯誤。

try-catch

ECMA-262 新增的錯誤處理方式與 Java 相似，將可能出錯的代碼放在 try 子句中，而處理錯誤的代碼放在 catch 子句中：

try {
    // Possible error code
} catch (e) {
    // Error Handler
}

catch 子句中捕獲到的錯誤對象包含發生錯誤的相關信息，通過該錯誤對象可以獲取錯誤類型的 name 屬性和保存錯誤消息的 message 屬性，e.message 即可調用。

在使用 try-catch 語句塊時，要知道什么時候使用最好。如果發生無法控制的錯誤上，就需要使用 try-catch 語句塊來處理錯誤；如果明確知道代碼會發生某種錯誤，就要采用相應的操作來防止錯誤發生，而不是使用 try-catch 語句塊來處理錯誤。

finally

在 try-catch 語句塊中，無論是 try 子句執行完，還是 catch 子句執行完，都可以接著執行 finally 子句中的代碼，try 與 catch 都無法阻止，包括 return 語句。

function test(){
    try {
        return 1;
    } catch (e){
        throw e;
    } finally {
        return false;
    }
}

上面的方法，最后會返回 false。

注意：主要代碼中包含了 finally 子句，try 塊或 catch 塊中的 return 語句就會被忽略，理解這一點很重要。在使用 finally 時一定要仔細確認代碼的行為。

拋出錯誤

使用 throw 拋出錯誤是另一種錯誤處理方式。throw 拋出任意表達式。如下所示：

throw "Not Value Error";        // String type error
throw 31;                       // Number type error
throw false;                    // Boolean type error
throw { name: "JavaScript" };   // Object type error

也可以調用 Error 構造函數來生成一個錯誤對象拋出，接收的值為錯誤消息。如下所示：

throw new Error("Null value Error.");

也可以調用特定的錯誤類型生成一個錯誤對象并拋出。如 SyntaxError、TypeError 等。使用 ES6 中的繼承語法創建錯誤類型也可以，這樣需要提供 name 屬性和 message 屬性。如下所示：

class CustomError extends Error {
    constructor(message) {
        super(message);
        this.name = "CustomError";
        this.message = message;
    }
}
throw new CustomError("Null Value Error.");

這種方式有助于在捕獲錯誤時更精準地區分錯誤。

Error

Error 錯誤類型是基本類型，其它錯誤類型基本都是繼承該類型。Error 提供了一個構造方法用來創建實例對象，當發生錯誤時，Error 通過構造方法創建實例對象并被拋出。

throw new Error("Null Value Error.");

Error 錯誤類型提供了三個屬性：

name：字符串類型。表示錯誤名稱。
message：字符串類型。表示錯誤信息。
stack：字符串類型。表示錯誤的堆棧。

ECMA-262 總共定義了 8 種錯誤類型，除了 Error 通用的錯誤類型外，還有如下幾種類型：

EvalError：該錯誤類型會在使用 eval() 函數發生錯誤時拋出。
InternalError：該錯誤類型主要會在底層 JavaScript 引擎拋出異常時由瀏覽器拋出。如遞歸過多導致棧溢出。通常并不是需要處理的錯誤。
RangeError：該錯誤類型會在數值變量或參數越界時拋出。
ReferenceError：該錯誤類型會在引用無效時拋出。
SyntaxError：該錯誤類型會在 eval() 在解析代碼的過程中發生。
TypeError：該錯誤類型會在變量或參數不是預期類型，或者訪問不存在的方法時拋出。
URIError：該錯誤類型只會在使用 encodeURI() 或 decodeURI() ，并且傳入的 URI 格式錯誤時發生。

瀏覽器很少會拋出 Error 類型的錯誤，主要是開發者拋出的自定義錯誤。而其它錯誤類型可以使用 instanceof 進行判斷。如下所示：

try {
    // Possible error code
} catch (e) {
    if (e instanceof TypeError) {
        // Type Error Handler
    } else if (e instanceof ReferenceError) {
        // Reference Error Handler
    } else {
        // Other Error Handler
    }
}

error 事件

沒有被 try-catch 捕獲的錯誤都會在 window 對象上觸發 error 事件。該事件會傳入幾個參數：

message：錯誤消息。
url：發生錯誤的 URL。
line：錯誤的行號。
colno：錯誤的列號。
error：Error對象。

window.onerror = (message, url, line, colno, error) => {
    // 可以對錯誤的消息進行處理，這里打印在控制臺上
    console.log(message);
    return false; // 這里返回 false 來阻止瀏覽器默認報告錯誤的行為
};

通過返回 false，函數實際上變成整個文檔的 try/catch 語句，可以捕獲所有未處理的運行時錯誤。適當的 try-catch 語句塊意味著不會有錯誤到達瀏覽器這個層次，因此就不會觸發 error 事件。當返回 true，會阻止執行默認事件處理函數。

而有一些資源加載失敗，會觸發一個 error 事件，這個事件遵循 DOM 格式。因此可以使用 addEventListener 捕獲。

const image = new Image();
image.addEventListener("error", (event) => {
    console.log("Image not loaded!");
});
image.src = "resource.gif"; // 不存在，資源會加載失敗。

總結

一個設計良好的錯誤處理對編程語言十分重要。JavaScript 提供的 try-cath 和 throw 兩種處理錯誤的方式。但是兩種錯誤處理方式，有不同的錯誤場景要求。如果編寫的庫或函數需要知道錯誤發生的具體原因，就拋出異常；如果確切知道接下來的操作，就捕獲錯誤。而沒有通過 try-catch 處理的錯誤，可以使用 window.onerror 事件來處理。

過統計數據庫中的1000多個項目，我們發現在 JavaScript 中最常出現的錯誤有10個。下面會向大家介紹這些錯誤發生的原因以及如何防止。

對于這些錯誤發生的次數，我們是通過收集的數據統計得出的。Rollbar 會收集每個項目中的所有錯誤，并總結每個錯誤發生的次數，然后通過各個錯誤的特征進行分組。

下圖是發生次數最多的10大 JavaScript 錯誤：

下面開始深入探討每個錯誤發生的情況，以便確定導致錯誤發生的原因以及如何避免。

1. Uncaught TypeError: Cannot Read Property

這是 JavaScript 開發人員最常遇到的錯誤。當你讀取一個屬性或調用一個未定義對象的方法時，Chrome 中就會報出這樣的錯誤。

導致這個錯誤發生的原因有很多，常見的一種情況是在渲染 UI 組件時，不正確地初始化狀態。我們來看一個真實的應用程序中發生這種情況的例子。

以上代碼有兩個重要方面：

一是組件的狀態（例如 this.state），在開始生命周期之前是 undefined 狀態。

二是當通過異步的方式獲取數據時，無論是在構造函數中 componentWillMount 中，還是在構造函數中提取 componentDidMount，組件在數據加載之前至少會渲染一次。當檢測首次渲染時，會發現 this.state.items 是未定義的。此時就會出現一個錯誤 -“Uncaught TypeError: Cannot read property ‘map’ of undefined" in the consol”。

解決的方法很簡單：在構造函數中使用合理的默認值進行狀態初始化。

2. TypeError: ‘undefined’ Is Not an Object (evaluating...)

這是在 Safari 中讀取屬性或調用未定義對象上的方法時發生的錯誤，這與 Chrome 的上述錯誤基本相同，只是 Safari 使用不同的錯誤消息。

3. TypeError: Null Is Not an Object (evaluating...)

這是在 Safari 中讀取屬性或調用空對象上的方法時發生的錯誤。

有趣的是，在 JavaScript 中，null 和 undefined 是兩種不同的類型，這就是為什么會出現兩個不同的錯誤消息。未定義通常是一個尚未分配的變量，而 null 則表示該值為空。要驗證它們不相等，請使用嚴格的相等運算符：

在實際情況中，導致這種錯誤的原因之一是：在元素加載之前，就嘗試在 JavaScript 中使用 DOM 元素。這是因為 DOM API 對于空白的對象引用返回 null。

任何執行和處理 DOM 元素的 JS 代碼，都應該在創建 DOM 元素之后執行。JS 代碼按照 HTML 中的規定自上而下進行解釋。因此，如果在 DOM 元素之前存在標簽，則腳本標簽內的 JS 代碼就會在瀏覽器分析 HTML 頁面時執行。如果在加載腳本之前尚未創建 DOM 元素，就會出現這樣的錯誤。

在這個例子中，我們可以通過添加一個事件偵聽器來解決這個問題，事件偵聽器會在頁面準備就緒時通知我們。一旦 addEventListener 被觸發，該 init( ) 方法就可以使用 DOM 元素。

4. (unknown): Script Error

當未捕獲的 JavaScript 錯誤違背跨邊界原則時，就會發生腳本錯誤。例如，如果將 JavaScript 代碼托管在 CDN 上，則任何未被捕獲的錯誤（通過 window.onerror 處理程序發出的錯誤，而不是 try-catch 中捕獲到的錯誤）將僅報告為“腳本錯誤”。這是瀏覽器的一種安全措施，主要用于防止跨域傳遞數據的情況出現。

要獲取真實的錯誤消息，需要執行以下操作：

Access-Control-Allow-Origin

將 Access-Control-Allow-Origin 設置為 *，表示可以從任何域正確訪問資源。* 如有必要，也可以用自己的域名進行替換，例如：

Access-Control-Allow-Origin: www.example.com。

以下是在各種環境中設置的一些示例：

Apache

在 JavaScript 文件夾中，創建一個 .htaccess 文件，并包含以下內容：

Nginx

將 add_header 指令添加到提供 JavaScript 文件的 location block 中：

HAProxy

將以下內容添加到提供 JavaScript 文件的靜態資源配置后端：

在腳本標簽上設置crossorigin =“anonymous”

在你的 HTML 源代碼中，為每一個腳本設置 Access-Control-Allow-Origin，在設置 SCRIPT 標簽中，設置 crossorigin="anonymous"。在將 crossorigin 屬性添加到腳本標簽之前，請確保正在向腳本文件發送 header。在 Firefox 中，如果 crossorigin 屬性存在但 Access-Control-Allow-Origin 標題不存在，則腳本不會執行。

5. TypeError: Object Doesn’t Support Property

當調用未定義的方法時，IE 中會發生這樣的錯誤。

這相當于 Chrome 中的 “undefined’ is not a function” 錯誤。對于相同的邏輯錯誤，不同的瀏覽器可能會有不同的錯誤消息。

這是在 IE 的 Web 應用程序中使用 JavaScript 命名空間出現的一個常見問題。出現這種情況的絕大部分原因是IE無法將當前名稱空間內的方法綁定到this關鍵字。例如，如果你有 JS Rollbar 方法的命名空間 isAwesome。通常，如果位于 Rollbar 命名空間內，則可以使用以下語法調用該 isAwesome 方法：

Chrome、Firefox 和 Opera 接受這種語法，IE則不接受。因此，使用 JS 命名空間時最安全的做法是：始終以實際名稱空間作為前綴。

6. TypeError: ‘undefined’ Is Not a Function

當調用未定義的函數時，Chrome 中就會發生這樣的錯誤。

隨著 JavaScript 編碼技術和設計模式在過去幾年中變得越來越復雜，回調和閉包中的自引用范圍也相應增加，這是造成這種混亂現象的主要來源。

正如下面的示例代碼片段：

執行上面的代碼會導致以下錯誤：“Uncaught TypeError: undefined is not a function。” 發生以上錯誤的原因是，當你調用 setTimeout( ) 時，實際上是在調用 window.setTimeout( )，傳遞給 setTimeout( ) 的匿名函數是在窗口對象的上下文中定義的，而該窗口對象沒有 clearBoard( ) 方法。

符合舊版瀏覽器的解決方案是以變量的方式簡單地將引用保存在 this 中，然后通過閉包繼承。例如：

或者，在較新的瀏覽器中，使用 bind( ) 方法傳遞引用：

7. Uncaught RangeError: Maximum Call Stack

這是在很多種情況，Chrome 中發生的錯誤，一種情況是當你調用一個不會終止的遞歸函數時。

如果將值傳遞給超出范圍的函數，也可能會發生這種情況。許多函數只接受特定范圍內的數字輸入值。例如，Number.toExponential( digits ) 與 Number.toFixed( digits) 接受的參數范圍為從0到20，而 Number.toPrecision( digits ) 接受的數字范圍為從1至21。

8. TypeError: Cannot Read Property ‘length’

這是 Chrome 中發生的錯誤，因為讀取了未定義長度屬性的變量。

通常在數組中能夠找到定義的長度，但是如果數組未初始化或變量名在另一個上下文中隱藏，則可能會出現這種錯誤。讓我們用下面的例子來解釋這種錯誤。

當用參數聲明一個函數時，這些參數會成為本地參數。這意味著即使你有名稱變量 testArray，函數中具有相同名稱的參數仍會被視為本地參數。

有兩種方法可以解決這個問題：

1. 刪除函數聲明語句中的參數：

2. 調用傳遞給我們聲明的數組函數：

9. Uncaught TypeError: Cannot Set Property

當嘗試訪問未定義的變量時，總會返回 undefined。我們也無法獲取或設置 undefined 的任何屬性。在這種情況下，應用程序將拋出“Uncaught TypeError cannot set property of undefined”。

例如，在 Chrome 瀏覽器中，如果 test 對象不存在，就會出現這種錯誤：

所以就需要在訪問變量之前，對變量進行定義。

10. ReferenceError: Event Is Not Defined

嘗試訪問未定義的變量或當前范圍之外的變量時會引發此錯誤。

如果在使用事件處理系統時遇到此錯誤，請確保使用傳入的事件對象作為參數。IE 這樣的瀏覽器提供了全局變量事件，Chrome 會自動將事件變量附加到處理程序中，Firefox 則不會自動添加事件變量。

JavaScript 開發工具推薦

SpreadJS 純前端表格控件是基于 HTML5 的 JavaScript 電子表格和網格功能控件，提供了完備的公式引擎、排序、過濾、輸入控件、數據可視化、Excel 導入/導出等功能，適用于 .NET、Java 和移動端等各平臺在線編輯類 Excel 功能的表格程序開發。

結論

事實證明很多這些 null 或 undefined 的錯誤是普遍存在的。一個類似于 Typescript 這樣的好的靜態類型檢查系統，當設置為嚴格的編譯選項時，能夠幫助開發者避免這些錯誤。

最后也希望通過本文，可以幫助開發者更好避免或是應對以上的10種錯誤。

歡迎點擊關注GermsTech，這里有最酷的IT、互聯網資訊～

在線咨詢

上一篇：2023年焦作市中考成績開始查詢！查詢方式→
下一篇：全流程網上辦案系統電子訴訟服務平臺常見問題答疑

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商