01 簡介

JavaScript已經(jīng)成為現(xiàn)代Web瀏覽器開發(fā)中最普遍的技術(shù)之一。之前在《PTES-信息收集》中講到源代碼審計(jì)也可能獲取到一些敏感信息，但有的測試人員只審計(jì)html源代碼，而忽略審計(jì)js文件里的源代碼，今天我們就來講一講審計(jì)js文件都能獲取到哪些信息。

02 詳解

通過審計(jì)js文件源代碼能獲取到的信息，我個人將其分為以下四類：敏感信息、業(yè)務(wù)邏輯、加密算法、Ajax請求。

敏感信息

審計(jì)js文件最直觀的就是很有可能獲取到賬號密碼、配置等敏感信息。

HTML定義頁面結(jié)構(gòu)，CSS定義裝修樣式，而JavaScript定義前端工作內(nèi)容，主要是監(jiān)聽事件執(zhí)行動作，比如邏輯判斷，亦或是向服務(wù)器發(fā)送請求等等。而要正確執(zhí)行這些動作，通常都會進(jìn)行一些簡單的配置。

最常見的配置就是設(shè)置網(wǎng)站根路徑，不過也經(jīng)常遇到直接在js文件里配置賬號密碼的情況；更有甚者，有的開發(fā)人員直接在js文件里定義SQL語句，然后由前端發(fā)送到服務(wù)器執(zhí)行。這不僅泄露了數(shù)據(jù)庫信息，也提高了SQL注入漏洞攻擊的風(fēng)險。

以上是獲取敏感信息的一種情況，還有一種情況就是注釋。

為了更好的維護(hù)代碼、調(diào)試代碼，我們經(jīng)常在源碼中見到各種注釋。比如為了方便調(diào)試，直接把賬號密碼寫在Javascript代碼中，調(diào)試完后，只是把這條語句注釋掉而非刪掉；有時候系統(tǒng)更迭，推出一些新的接口，開發(fā)人員把老接口注釋掉使用新的接口，但服務(wù)器端并沒有把老接口關(guān)掉等等。

以上情況不僅讓我們搜集到了更多目標(biāo)信息，也增加了系統(tǒng)攻擊面，只能說：這些開發(fā)人員真他娘的是個人才。

業(yè)務(wù)邏輯

除了能獲取到敏感信息，審計(jì)js文件還可以獲取到Web系統(tǒng)的一些業(yè)務(wù)邏輯。

說到業(yè)務(wù)邏輯，就要牽扯到前端校驗(yàn)。有些系統(tǒng)只做了前端校驗(yàn)，只要響應(yīng)包滿足條件，就會執(zhí)行下一步操作，服務(wù)器端不會再進(jìn)一步檢驗(yàn)接下來的請求是否有問題，我們只要修改響應(yīng)包就可以繞過檢測。

比如輸入錯誤的賬號密碼，響應(yīng)false，要求重新輸入賬號密碼；我們把響應(yīng)包攔截，把false改成true，前端檢測到true，認(rèn)為賬號密碼正確，發(fā)送跳轉(zhuǎn)到系統(tǒng)內(nèi)部的請求，而服務(wù)器沒有再校驗(yàn)請求是否有問題，將系統(tǒng)內(nèi)部頁面響應(yīng)給前端。

要繞過前端校驗(yàn)，像0/1、true/false這種很容易就能猜到該怎么修改，但有些系統(tǒng)可能有十多個響應(yīng)碼，或者響應(yīng)碼有多位，如果我們耐著性子一個一個去試，時間成本會很大。

比如0是用戶名錯誤，1是密碼錯誤，2是驗(yàn)證碼錯誤，9999是登陸成功，如果我們從0開始，一個一個去試，說真的還不一定能試出來。除非先輸入正確的賬號密碼得到正確的響應(yīng)碼，然后輸入錯誤的賬號密碼，再用之前得到的正確響應(yīng)碼替換錯誤的響應(yīng)碼，嘗試看是否存在前端校驗(yàn)的問題。

問題是：如果是安全服務(wù)，客戶還有可能提供賬號密碼，但攻防演練、挖洞一般都是靠自己白手起家，哪里有什么賬號密碼給你。而前端業(yè)務(wù)邏輯通常都由js實(shí)現(xiàn)，基本都可以通過代碼審計(jì)來確定如何構(gòu)造響應(yīng)包來嘗試?yán)@過前端校驗(yàn)。我只想說：信息收集真的很重要。

加密算法

審計(jì)代碼能獲取到的第三類信息就是加密算法。在當(dāng)今的大環(huán)境下，企業(yè)越來越重視安全，運(yùn)用了各種防護(hù)手段來提高系統(tǒng)的安全系數(shù)，提高攻擊者的攻擊成本，其中就有加密機(jī)制。

可能很多測試人員在測試的時候，抓包發(fā)現(xiàn)參數(shù)值都是加密的，就這么放過了。但這種前端加密都是可以在js中找到加密算法的，要么在html文件的js中，要么包含在js文件中。

當(dāng)然我們也可以不需要知道加密算法到底是怎么樣的，直接輸入測試的明文Payload，系統(tǒng)自然會利用加密算法輸出對應(yīng)的加密數(shù)據(jù)。這個Payload不行，我們再輸入下一個明文Payload去測試。

以上的方式時間成本會增加很多，而且有時候系統(tǒng)會先檢測輸入的數(shù)據(jù)是否含有非法字符，沒有非法字符才會加密發(fā)送到服務(wù)器端。而只要我們找到了對應(yīng)的加密算法，就可以手工構(gòu)造或者編寫腳本批量生成我們想要的加密數(shù)據(jù)，進(jìn)而去測試系統(tǒng)是否存在漏洞。

據(jù)目前工作經(jīng)歷來看，涉及到加密的參數(shù)，存在漏洞的幾率要高很多。因?yàn)榍岸思用芎?，后端必須解密才能使用。但很多時候，系統(tǒng)的安全檢測只在請求傳過來的時候，加密時沒有檢測到非法字符就繞過了檢測，后端解密之后就可以肆意橫行。

Ajax請求

審計(jì)js文件能獲取到的信息還有Ajax請求，也是漏洞重災(zāi)區(qū)。而Ajax請求的調(diào)用通常很隱蔽，且Ajax請求的觸發(fā)條件無規(guī)律，很容易被遺漏或忽略。

Ajax請求通常是被各個事件觸發(fā)調(diào)用，而這些事件的觸發(fā)往往需要滿足一定條件。但很多時候，即便事件觸發(fā)條件未滿足，我們?nèi)?gòu)造Ajax請求的數(shù)據(jù)包發(fā)送給服務(wù)器端，依然可以得到服務(wù)器的響應(yīng)。

服務(wù)器訪問控制不當(dāng)，并沒有去檢測用戶是否是通過正常業(yè)務(wù)邏輯發(fā)送Ajax請求，也沒有去檢測用戶是否有操作權(quán)限。服務(wù)器認(rèn)為客戶端發(fā)過來的請求都是正確的，這又要提一下安全的本質(zhì)：一切輸入都是不安全的。而且每一個Ajax請求都對應(yīng)一個接口，這又增加了攻擊面，每個請求都可能形成獨(dú)立的攻擊過程。

舉個真實(shí)案例：修改密碼，先要通過短信驗(yàn)證碼校驗(yàn)才能修改新密碼。只有管理員才能修改密碼，修改密碼的Ajax請求由修改密碼功能調(diào)用，普通用戶沒有這個功能。(某些原因，沒有截圖，意淫一下吧)

開發(fā)人員認(rèn)為所有的用戶都會按照系統(tǒng)業(yè)務(wù)邏輯一步一步觸發(fā)請求，先點(diǎn)擊發(fā)送驗(yàn)證碼，然后填寫驗(yàn)證碼進(jìn)行校驗(yàn)，通過校驗(yàn)后跳轉(zhuǎn)到修改密碼的頁面，輸入新密碼，最后修改成功。而且只有管理員有這個功能頁面。

但通過代碼審計(jì)，直接在js文件中找到了修改密碼的Ajax請求，請求參數(shù)只有新密碼?，F(xiàn)在我們已經(jīng)找到了修改密碼的請求，那么我們可以跳過前面一系列的校驗(yàn)和請求，只需要構(gòu)造出修改密碼請求，就可以修改密碼。

而且這個Ajax請求是寫在js文件里的，系統(tǒng)并不會因?yàn)橛脩魴?quán)限的不同而調(diào)用不同的js文件，所以普通用戶也能夠查到到對應(yīng)的js代碼，不存在管理員一說。

03 總結(jié)

本文簡單講述了審計(jì)js文件源代碼能獲取到的四類信息：敏感信息、業(yè)務(wù)邏輯、加密算法、Ajax請求。

當(dāng)然，這也僅僅是我個人的歸類，審計(jì)代碼能獲取到的信息遠(yuǎn)不止這些，需要大家去深入挖掘，我純碎起一個拋磚引玉的作用。

忙里偷閑，差不多半年才寫了一篇文章。這波行動差不多要結(jié)束了，接下來就是國慶重保。國慶重保后不出意外的話應(yīng)該，可能，也許會稍微輕松一點(diǎn)，爭取一個月能寫篇文章吧。感謝大家的關(guān)注！