整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
譯：h4d35
預(yù)估稿費：120RMB
投稿方式：發(fā)送郵件至linwei#360.cn，或登陸網(wǎng)頁版在線投稿
前言
本篇文章主要介紹了在一次漏洞懸賞項目中如何利用配置錯誤挖到一個認(rèn)證繞過漏洞。
從JS文件中發(fā)現(xiàn)認(rèn)證繞過漏洞
本文內(nèi)容源自一個私有漏洞賞金計劃。在這個漏洞計劃中，接受的漏洞范圍限于目標(biāo)網(wǎng)站少數(shù)幾個公開的功能。基于前期發(fā)現(xiàn)的問題（當(dāng)我被邀請進(jìn)這個計劃時，其他人一共提交了5個漏洞），似乎很難再挖到新的漏洞。同時，在賞金詳情中提到了這樣一句話：
如果你成功進(jìn)入管理頁面，請立即報告，請勿在/admin中進(jìn)行進(jìn)一步的測試。
然而，目標(biāo)網(wǎng)站中存在一個僅限于未認(rèn)證和未經(jīng)授權(quán)的用戶訪問的管理頁面。當(dāng)我們訪問/login或/admin時會跳轉(zhuǎn)到https://bountysite.com/admin/dashboard?redirect=/。
對登錄頁面進(jìn)行暴力破解也許是一個可行方案，但是我并不喜歡這種方式。看一下網(wǎng)頁源碼，沒什么有用的內(nèi)容。于是我開始查看目標(biāo)網(wǎng)站的結(jié)構(gòu)。似乎目標(biāo)網(wǎng)站的JS文件都放在少數(shù)幾個文件夾中，如/lib、/js、/application等。
有意思！
祭出神器BurpSuite，使用Intruder跑一下看能否在上述文件夾中找到任何可訪問的JS文件。將攻擊點設(shè)置為https://bountysite.com/admin/dashboard/js/*attack*.js。注意，不要忘記.js擴(kuò)展名，這樣如果文件能夠訪問則返回200響應(yīng)。確實有意思！因為我找到了一些可訪問的JS文件，其中一個文件是/login.js。
訪問這個JS文件https://bountysite.com/admin/dashboard/js/login.js，請求被重定向至管理頁面:) 。但是，我并沒有查看該文件的權(quán)限，只能看到部分接口信息。
但是我并沒有就此止步。這看起來很奇怪，為什么我訪問一個.js文件卻被作為HTML加載了呢？經(jīng)過一番探查，終于發(fā)現(xiàn)，我能夠訪問管理頁面的原因在于*login*。是的，只要在請求路徑/dashboard/后的字符串中含有*login*（除了'login'，這只會使我回到登錄頁面），請求就會跳轉(zhuǎn)到這個管理接口，但是卻沒有正確的授權(quán)。
我繼續(xù)對這個受限的管理接口進(jìn)行了進(jìn)一步的測試。再一次查看了頁面源碼，試著搞清楚網(wǎng)站結(jié)構(gòu)。在這個管理接口中，有其他一些JS文件能夠幫助我理解管理員是如何執(zhí)行操作的。一些管理操作需要一個有效的令牌。我試著使用從一個JS文件中泄露的令牌執(zhí)行相關(guān)管理操作，然并卵。請求還是被重定向到了登錄頁面。我發(fā)現(xiàn)另外一個真實存在的路徑中也部署了一些內(nèi)容，那就是/dashboard/controllers/*.php。
再一次祭出BurpSuite，使用Intruder檢查一下是否存在可以從此處訪問的其他任何路徑。第二次Intruder的結(jié)果是，我發(fā)現(xiàn)幾乎不存在其他無需授權(quán)即可訪問的路徑。這是基于服務(wù)器返回的500或者200響應(yīng)得出的結(jié)論。
回到我在上一步偵察中了解到的網(wǎng)站結(jié)構(gòu)中，我發(fā)現(xiàn)這些路徑是在/controllers中定義的，通過/dashboard/*here*/進(jìn)行訪問。但是直接訪問這些路徑會跳轉(zhuǎn)到登錄頁面，似乎網(wǎng)站對Session檢查得還挺嚴(yán)格。此時我又累又困，幾乎都打算放棄了，但是我想最后再試一把。如果我利用與訪問管理頁面相同的方法去執(zhí)行這些管理操作會怎么樣呢？很有趣，高潮來了:) 我能夠做到這一點。
通過訪問/dashboard/photography/loginx，請求跳轉(zhuǎn)到了Admin Photography頁面，并且擁有完整的權(quán)限！
從這里開始，我能夠執(zhí)行和訪問/dashboard/*路徑下的所有操作和目錄，這些地方充滿了諸如SQL注入、XSS、文件上傳、公開重定向等漏洞。但是，我沒有繼續(xù)深入測試，因為這些都不在賞金計劃之內(nèi)，根據(jù)計劃要求，一旦突破管理授權(quán)限制，應(yīng)立即報告問題。此外，根據(jù)管理頁面顯示的調(diào)試錯誤信息可知，我之所以能夠訪問到管理頁面，是因為應(yīng)用程序在/dashboard/controllers/*文件中存在錯誤配置。期望達(dá)到的效果是：只要請求鏈接中出現(xiàn)*login*，就重定向至主登錄頁面，然而，實際情況并不如人所愿。
后記
總之，這是有趣的一天！我拿到了這個漏洞賞金計劃最大金額的獎勵。
程語言都會需要完善的錯誤處理策略使得應(yīng)用程序更為合理的操作錯誤。錯誤處理在服務(wù)端的處理較為完善，但是瀏覽器端進(jìn)展較為緩慢，不同瀏覽器的錯誤處理方式也不同，且默認(rèn)的錯誤處理方式對用戶也不友好。因此，必須理解各種捕獲和處理錯誤的方式。而在 ECMA-262 的第3版中增加了 try-catch 語句塊和 throw 語句來處理錯誤，以及一些錯誤類型來描述錯誤。
ECMA-262 新增的錯誤處理方式與 Java 相似，將可能出錯的代碼放在 try 子句中，而處理錯誤的代碼放在 catch 子句中：
try {
// Possible error code
} catch (e) {
// Error Handler
}catch 子句中捕獲到的錯誤對象包含發(fā)生錯誤的相關(guān)信息，通過該錯誤對象可以獲取錯誤類型的 name 屬性和保存錯誤消息的 message 屬性，e.message 即可調(diào)用。
在使用 try-catch 語句塊時，要知道什么時候使用最好。如果發(fā)生無法控制的錯誤上，就需要使用 try-catch 語句塊來處理錯誤；如果明確知道代碼會發(fā)生某種錯誤，就要采用相應(yīng)的操作來防止錯誤發(fā)生，而不是使用 try-catch 語句塊來處理錯誤。
在 try-catch 語句塊中，無論是 try 子句執(zhí)行完，還是 catch 子句執(zhí)行完，都可以接著執(zhí)行 finally 子句中的代碼，try 與 catch 都無法阻止，包括 return 語句。
function test(){
try {
return 1;
} catch (e){
throw e;
} finally {
return false;
}
}上面的方法，最后會返回 false。
注意：主要代碼中包含了 finally 子句，try 塊或 catch 塊中的 return 語句就會被忽略，理解這一點很重要。在使用 finally 時一定要仔細(xì)確認(rèn)代碼的行為。
使用 throw 拋出錯誤是另一種錯誤處理方式。throw 拋出任意表達(dá)式。如下所示：
throw "Not Value Error"; // String type error
throw 31; // Number type error
throw false; // Boolean type error
throw { name: "JavaScript" }; // Object type error也可以調(diào)用 Error 構(gòu)造函數(shù)來生成一個錯誤對象拋出，接收的值為錯誤消息。如下所示：
throw new Error("Null value Error.");也可以調(diào)用特定的錯誤類型生成一個錯誤對象并拋出。如 SyntaxError、TypeError 等。使用 ES6 中的繼承語法創(chuàng)建錯誤類型也可以，這樣需要提供 name 屬性和 message 屬性。如下所示：
class CustomError extends Error {
constructor(message) {
super(message);
this.name = "CustomError";
this.message = message;
}
}
throw new CustomError("Null Value Error.");這種方式有助于在捕獲錯誤時更精準(zhǔn)地區(qū)分錯誤。
Error 錯誤類型是基本類型，其它錯誤類型基本都是繼承該類型。Error 提供了一個構(gòu)造方法用來創(chuàng)建實例對象，當(dāng)發(fā)生錯誤時，Error 通過構(gòu)造方法創(chuàng)建實例對象并被拋出。
throw new Error("Null Value Error.");Error 錯誤類型提供了三個屬性：
ECMA-262 總共定義了 8 種錯誤類型，除了 Error 通用的錯誤類型外，還有如下幾種類型：
瀏覽器很少會拋出 Error 類型的錯誤，主要是開發(fā)者拋出的自定義錯誤。而其它錯誤類型可以使用 instanceof 進(jìn)行判斷。如下所示：
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
}
}沒有被 try-catch 捕獲的錯誤都會在 window 對象上觸發(fā) error 事件。該事件會傳入幾個參數(shù)：
window.onerror = (message, url, line, colno, error) => {
// 可以對錯誤的消息進(jìn)行處理，這里打印在控制臺上
console.log(message);
return false; // 這里返回 false 來阻止瀏覽器默認(rèn)報告錯誤的行為
};通過返回 false，函數(shù)實際上變成整個文檔的 try/catch 語句，可以捕獲所有未處理的運(yùn)行時錯誤。適當(dāng)?shù)?try-catch 語句塊意味著不會有錯誤到達(dá)瀏覽器這個 層次，因此就不會觸發(fā) error 事件。當(dāng)返回 true，會阻止執(zhí)行默認(rèn)事件處理函數(shù)。
而有一些資源加載失敗，會觸發(fā)一個 error 事件，這個事件遵循 DOM 格式。因此可以使用 addEventListener 捕獲。
const image = new Image();
image.addEventListener("error", (event) => {
console.log("Image not loaded!");
});
image.src = "resource.gif"; // 不存在，資源會加載失敗。一個設(shè)計良好的錯誤處理對編程語言十分重要。JavaScript 提供的 try-cath 和 throw 兩種處理錯誤的方式。但是兩種錯誤處理方式，有不同的錯誤場景要求。如果編寫的庫或函數(shù)需要知道錯誤發(fā)生的具體原因，就拋出異常；如果確切知道接下來的操作，就捕獲錯誤。而沒有通過 try-catch 處理的錯誤，可以使用 window.onerror 事件來處理。
過統(tǒng)計數(shù)據(jù)庫中的1000多個項目，我們發(fā)現(xiàn)在 JavaScript 中最常出現(xiàn)的錯誤有10個。下面會向大家介紹這些錯誤發(fā)生的原因以及如何防止。
對于這些錯誤發(fā)生的次數(shù)，我們是通過收集的數(shù)據(jù)統(tǒng)計得出的。Rollbar 會收集每個項目中的所有錯誤，并總結(jié)每個錯誤發(fā)生的次數(shù)，然后通過各個錯誤的特征進(jìn)行分組。
下圖是發(fā)生次數(shù)最多的10大 JavaScript 錯誤：
下面開始深入探討每個錯誤發(fā)生的情況，以便確定導(dǎo)致錯誤發(fā)生的原因以及如何避免。
這是 JavaScript 開發(fā)人員最常遇到的錯誤。當(dāng)你讀取一個屬性或調(diào)用一個未定義對象的方法時，Chrome 中就會報出這樣的錯誤。
導(dǎo)致這個錯誤發(fā)生的原因有很多，常見的一種情況是在渲染 UI 組件時，不正確地初始化狀態(tài)。我們來看一個真實的應(yīng)用程序中發(fā)生這種情況的例子。
以上代碼有兩個重要方面：
一是組件的狀態(tài)（例如 this.state），在開始生命周期之前是 undefined 狀態(tài)。
二是當(dāng)通過異步的方式獲取數(shù)據(jù)時，無論是在構(gòu)造函數(shù)中 componentWillMount 中，還是在構(gòu)造函數(shù)中提取 componentDidMount，組件在數(shù)據(jù)加載之前至少會渲染一次。當(dāng)檢測首次渲染時，會發(fā)現(xiàn) this.state.items 是未定義的。此時就會出現(xiàn)一個錯誤 -“Uncaught TypeError: Cannot read property ‘map’ of undefined" in the consol”。
解決的方法很簡單：在構(gòu)造函數(shù)中使用合理的默認(rèn)值進(jìn)行狀態(tài)初始化。
這是在 Safari 中讀取屬性或調(diào)用未定義對象上的方法時發(fā)生的錯誤，這與 Chrome 的上述錯誤基本相同，只是 Safari 使用不同的錯誤消息。
這是在 Safari 中讀取屬性或調(diào)用空對象上的方法時發(fā)生的錯誤。
有趣的是，在 JavaScript 中，null 和 undefined 是兩種不同的類型，這就是為什么會出現(xiàn)兩個不同的錯誤消息。未定義通常是一個尚未分配的變量，而 null 則表示該值為空。要驗證它們不相等，請使用嚴(yán)格的相等運(yùn)算符：
在實際情況中，導(dǎo)致這種錯誤的原因之一是：在元素加載之前，就嘗試在 JavaScript 中使用 DOM 元素。這是因為 DOM API 對于空白的對象引用返回 null。
任何執(zhí)行和處理 DOM 元素的 JS 代碼，都應(yīng)該在創(chuàng)建 DOM 元素之后執(zhí)行。JS 代碼按照 HTML 中的規(guī)定自上而下進(jìn)行解釋。因此，如果在 DOM 元素之前存在標(biāo)簽，則腳本標(biāo)簽內(nèi)的 JS 代碼就會在瀏覽器分析 HTML 頁面時執(zhí)行。如果在加載腳本之前尚未創(chuàng)建 DOM 元素，就會出現(xiàn)這樣的錯誤。
在這個例子中，我們可以通過添加一個事件偵聽器來解決這個問題，事件偵聽器會在頁面準(zhǔn)備就緒時通知我們。一旦 addEventListener 被觸發(fā)，該 init( ) 方法就可以使用 DOM 元素。
當(dāng)未捕獲的 JavaScript 錯誤違背跨邊界原則時，就會發(fā)生腳本錯誤。例如，如果將 JavaScript 代碼托管在 CDN 上，則任何未被捕獲的錯誤（通過 window.onerror 處理程序發(fā)出的錯誤，而不是 try-catch 中捕獲到的錯誤）將僅報告為“腳本錯誤”。這是瀏覽器的一種安全措施，主要用于防止跨域傳遞數(shù)據(jù)的情況出現(xiàn)。
要獲取真實的錯誤消息，需要執(zhí)行以下操作：
Access-Control-Allow-Origin
將 Access-Control-Allow-Origin 設(shè)置為 *， 表示可以從任何域正確訪問資源。* 如有必要，也可以用自己的域名進(jìn)行替換，例如：
Access-Control-Allow-Origin: www.example.com。
以下是在各種環(huán)境中設(shè)置的一些示例：
Apache
在 JavaScript 文件夾中，創(chuàng)建一個 .htaccess 文件，并包含以下內(nèi)容：
Nginx
將 add_header 指令添加到提供 JavaScript 文件的 location block 中：
HAProxy
將以下內(nèi)容添加到提供 JavaScript 文件的靜態(tài)資源配置后端：
在腳本標(biāo)簽上設(shè)置crossorigin =“anonymous”
在你的 HTML 源代碼中，為每一個腳本設(shè)置 Access-Control-Allow-Origin，在設(shè)置 SCRIPT 標(biāo)簽中，設(shè)置 crossorigin="anonymous"。在將 crossorigin 屬性添加到腳本標(biāo)簽之前，請確保正在向腳本文件發(fā)送 header。在 Firefox 中，如果 crossorigin 屬性存在但 Access-Control-Allow-Origin 標(biāo)題不存在，則腳本不會執(zhí)行。
當(dāng)調(diào)用未定義的方法時，IE 中會發(fā)生這樣的錯誤。
這相當(dāng)于 Chrome 中的 “undefined’ is not a function” 錯誤。對于相同的邏輯錯誤，不同的瀏覽器可能會有不同的錯誤消息。
這是在 IE 的 Web 應(yīng)用程序中使用 JavaScript 命名空間出現(xiàn)的一個常見問題。出現(xiàn)這種情況的絕大部分原因是IE無法將當(dāng)前名稱空間內(nèi)的方法綁定到this關(guān)鍵字。例如，如果你有 JS Rollbar 方法的命名空間 isAwesome。通常，如果位于 Rollbar 命名空間內(nèi)，則可以使用以下語法調(diào)用該 isAwesome 方法：
Chrome、Firefox 和 Opera 接受這種語法，IE則不接受。因此，使用 JS 命名空間時最安全的做法是：始終以實際名稱空間作為前綴。
當(dāng)調(diào)用未定義的函數(shù)時，Chrome 中就會發(fā)生這樣的錯誤。
隨著 JavaScript 編碼技術(shù)和設(shè)計模式在過去幾年中變得越來越復(fù)雜，回調(diào)和閉包中的自引用范圍也相應(yīng)增加，這是造成這種混亂現(xiàn)象的主要來源。
正如下面的示例代碼片段：
執(zhí)行上面的代碼會導(dǎo)致以下錯誤：“Uncaught TypeError: undefined is not a function。” 發(fā)生以上錯誤的原因是，當(dāng)你調(diào)用 setTimeout( ) 時，實際上是在調(diào)用 window.setTimeout( )，傳遞給 setTimeout( ) 的匿名函數(shù)是在窗口對象的上下文中定義的，而該窗口對象沒有 clearBoard( ) 方法。
符合舊版瀏覽器的解決方案是以變量的方式簡單地將引用保存在 this 中，然后通過閉包繼承。例如：
或者，在較新的瀏覽器中，使用 bind( ) 方法傳遞引用：
這是在很多種情況，Chrome 中發(fā)生的錯誤，一種情況是當(dāng)你調(diào)用一個不會終止的遞歸函數(shù)時。
如果將值傳遞給超出范圍的函數(shù)，也可能會發(fā)生這種情況。許多函數(shù)只接受特定范圍內(nèi)的數(shù)字輸入值。例如，Number.toExponential( digits ) 與 Number.toFixed( digits) 接受的參數(shù)范圍為從0到20，而 Number.toPrecision( digits ) 接受的數(shù)字范圍為從1至21。
這是 Chrome 中發(fā)生的錯誤，因為讀取了未定義長度屬性的變量。
通常在數(shù)組中能夠找到定義的長度，但是如果數(shù)組未初始化或變量名在另一個上下文中隱藏，則可能會出現(xiàn)這種錯誤。讓我們用下面的例子來解釋這種錯誤。
當(dāng)用參數(shù)聲明一個函數(shù)時，這些參數(shù)會成為本地參數(shù)。這意味著即使你有名稱變量 testArray，函數(shù)中具有相同名稱的參數(shù)仍會被視為本地參數(shù)。
有兩種方法可以解決這個問題：
1. 刪除函數(shù)聲明語句中的參數(shù)：
2. 調(diào)用傳遞給我們聲明的數(shù)組函數(shù)：
當(dāng)嘗試訪問未定義的變量時，總會返回 undefined。我們也無法獲取或設(shè)置 undefined 的任何屬性。在這種情況下，應(yīng)用程序?qū)伋觥癠ncaught TypeError cannot set property of undefined”。
例如，在 Chrome 瀏覽器中，如果 test 對象不存在，就會出現(xiàn)這種錯誤：
所以就需要在訪問變量之前，對變量進(jìn)行定義。
嘗試訪問未定義的變量或當(dāng)前范圍之外的變量時會引發(fā)此錯誤。
如果在使用事件處理系統(tǒng)時遇到此錯誤，請確保使用傳入的事件對象作為參數(shù)。IE 這樣的瀏覽器提供了全局變量事件，Chrome 會自動將事件變量附加到處理程序中，F(xiàn)irefox 則不會自動添加事件變量。
SpreadJS 純前端表格控件是基于 HTML5 的 JavaScript 電子表格和網(wǎng)格功能控件，提供了完備的公式引擎、排序、過濾、輸入控件、數(shù)據(jù)可視化、Excel 導(dǎo)入/導(dǎo)出等功能，適用于 .NET、Java 和移動端等各平臺在線編輯類 Excel 功能的表格程序開發(fā)。
事實證明很多這些 null 或 undefined 的錯誤是普遍存在的。 一個類似于 Typescript 這樣的好的靜態(tài)類型檢查系統(tǒng)，當(dāng)設(shè)置為嚴(yán)格的編譯選項時，能夠幫助開發(fā)者避免這些錯誤。
最后也希望通過本文，可以幫助開發(fā)者更好避免或是應(yīng)對以上的10種錯誤。
歡迎點擊關(guān)注GermsTech，這里有最酷的IT、互聯(lián)網(wǎng)資訊～
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
