用你的瀏覽器來靜態分析網站源碼——初級漏洞賞金獵人指南(入坑好文)

用你的瀏覽器來靜態分析網站源碼——初級漏洞賞金獵人指南(入坑好文)

source link

本文將教你如何用瀏覽器自帶工具分析web應用的客戶端源代碼。這聽上去有點怪,因爲瀏覽器並不是做這活最好的選擇。但在你開始用burpsuite抓包和到處注入alert(1)來測試XSS之前,好好研究下你的目標總是好的。

本文主要面向初級漏洞賞金獵人或者對HTML、Js代碼分析缺乏經驗的人,但我同樣希望老鳥們能在這裏有所受益。

近期我的一條介紹小技巧的推文在社區引來不少關注,於是我決定寫本文:

twiiterpng

這條推文只是小技巧的冰山一角,我想與其發一堆容易錯過的類似推文,不如發一篇彙總型的博文,希望對你們有用。那就開始吧!

工具集

每個現代瀏覽器都有一組內建工具集。要打開它們,你只需敲Ctrl+Shift+I、CMD+Option+I(macOS系統)、F12或在瀏覽器右邊的菜單欄中找到。本文中我將使用最新版的Chromium,你們也可以使用Firefox、Safari、Chrome、Edge等,隨你便啦,但我覺得Chrome的開發者工具是最強大的(該工具集集成在Chrome、Chromium、Brave、Opera和其他基於Chromium的瀏覽器中)。

另一樣需要安裝的工具是IDE(集成開發環境)或者任意帶HTML、Js語法高亮的代碼編輯器。隨你喜好,我個人推薦Visual Studio Code,VSCode也是我日常工作中唯一使用的IDE。你可以在這裏下載到https://code.visualstudio.com/

NodeJS也值得安裝(並熟練使用它——英特網上有好幾千的資源包),在這裏下載https://nodejs.org/en/

Python解釋器也是必裝神器(如果你在用*nix系統,它已將預裝了。如果是windows用戶,還是要自己裝一下)。會寫Python是一個寶貴的技藝,我也建議沒寫過一行代碼的人去學習一下。

在終端下用NodeJS測試JavaScript代碼是很方便的(瀏覽器也能辦到,我們隨後討論這一方法的優缺點)。Python是個好東西,你可以用它開發工具、寫PoC和利用代碼,下文將展示一些自寫工具。如果你更熟悉其他解釋型語言(Ruby、PHP、Perl、Bash等),你也可以使用它們。這類語言的優勢在於無需編譯、類似於命令行、跨平臺、大量內建庫和第三方模塊。

分析HTML源代碼

先回到我先前發的那條推特,你也許注意到了,截圖裏的網站看上去空白一片,但你若查看它的源代碼,就會發現大量代碼(沒辦法,我不能提供帶網站URL的截圖,因爲這是個私人衆測項目)。爲什麼瀏覽器上看不見這些元素?

重點是頁面中的部分HTML標籤沒有渲染任何內容。最常見的是<html>,<head>,<body>,<style><script>。CSS同樣能隱藏元素(例如,設置它們的寬、高屬性爲0或顯示爲none),例如:

<html>
<head>
    <title>Move along, nothing to see here!</title>
    <style>
    /* note to myself: add CSS from Bob's repo: https://verysecurecompany.com/__internal__/repo/bob/specs.git */
    * {
        font-size:16px;
        color: #c0c0c0;
    }
    </style>
</head>
<body>
    <iframe src="https://verysecurecompany.com/__internal__/loginframe.html" style="width:0;height:0" frameborder="0" id="you-cant-see-me"></iframe>
    <script>
        // a hidden feature
        console.log('Diagnostic message: username is admin and password is password :)');    
    </script>
</body>
</html>

如果你在瀏覽器中打開這個html頁面,它不會渲染任何內容,你也不會看到任何內容。但當你查看源代碼,就會發現一些有意思的東西:

在這裏插入圖片描述

裏面有多出信息泄露:訪問內部資源的URL、隱藏的包含登錄表單的iframe、在控制檯輸出的憑據信息。這些信息不會顯示在頁面中,當然,別指望在每個網站裏都發現這些信息,但帶註解的Js代碼很常見,有時它們會暴露一些app的服務端仍可用的API。

僅僅使用“View Source”功能無法揭露所有的內容,因爲它只展示HTML文檔。更有趣的內容通常由<iframe><script>等標籤揭示,你可以在Chrome開發者工具的“Source”標籤欄中看到它們。

在這裏插入圖片描述

左側的目錄樹最底端的(index)節點就是你在“View Source”中看到的HTML主文檔,其他資源保存在文件夾和文件樹中。如果你點擊這些文件,就會在右側看到它們的內容。截圖中是jquery.min.js文件的內容,它是所有Js文件的通用壓縮版(從性能上說這麼做很不錯)。但如果你點擊底部的“{}”小按鈕,工具集會展開這些代碼來方便閱讀。

在這裏插入圖片描述

有些網站使用sourcemap特性(source map用來映射壓縮版函數、變量、對象名稱到它們在源代碼中的真實名稱及位置,更多詳情)。sourcemap使用對象有意義的名稱來增加格式化代碼的可讀性,而不是Js壓縮軟件產生的標識符。

另一個有用特性是全局搜索。假設你已注意到一些有趣的函數並想知道是否存在於源碼中其他地方。也許它是個eval()函數參數來自url(這很可能造成Js代碼執行)。爲了對“Source”標籤中文件做全部搜索,你可以用CTRL+Shift+F快捷鍵(MacOS中:CMD+Option+F)。下例中,我試着在AppMeasurement.js中查找getAccount()的所有引用。如你所見,該函數在同一文件中調用了一次。但若在其他文件中有出現搜索關鍵詞,就會被列出:

在這裏插入圖片描述

有時你會發現搜索結果是一條非常長的字串(尤其是在壓縮過的Js文件中)。點擊字串,工具集就會打開它,點擊“{}”按鈕就會在右側演示擴展版的Js版本(有時會有幾千行),搜索結果也會出現。

另一個查看源代碼的標籤叫“Elements”。“Sources”標籤的(index)文件(或“View Source”功能)與它看似相同,實則差別不小。前者展示的來自服務器的HTML文檔,後者展示的當前DOM樹,所有的節點有Js代碼添加。爲了明白這一區別,我先介紹些原理,然後展示個小示例。

DOM(文檔對象模型)代表真個網頁的HTML節點,它由單個根節點(<html>)和兩個主要子節點(<head><body>)構成。所有其他節點都是二者的子節點,如:<title><meta><head>的子節點,<div><p><img>等是<body>的子節點。

當你在瀏覽器打開一條URL,首先會加載HTML文件,代碼會由瀏覽器引擎執行。當瀏覽器發現<script><style>標籤(或其他帶有src屬性的標籤,如image、video),它會停止解析並加載src所指文件。如果該文件是可執行的Js,它就會被執行。如果是樣式表,CSS規則就會被CSS解析器解析應用。整個過程如下圖示:

在這裏插入圖片描述

但“Elements”和“Sources”標籤又不同在哪裏呢?考慮一下情形,Js添加元素到DOM中:

<html>
<head>
    <title>Dynamic P Application</title>
    <style>
    * {
        font-size:18px;
        font-weight:bold;
        color: #2e2e2e;
    }
    </style>
</head>
<body>
    <div id="container">

    </div>
    <script>
        const el = document.getElementById('container')
        const dynamic_paragraph = document.createElement('p')
        const dp_content = document.createTextNode('Hello from dynamically added <P>aragraph!')

        dynamic_paragraph.appendChild(dp_content)
        el.appendChild(dynamic_paragraph)
    </script>
</body>
</html>

當你打開這一頁面並查看源碼,你會看到如下的內容:

在這裏插入圖片描述

這是Js添加DOM新元素最簡單的示例,當使用“Elements”標籤時會看到:

在這裏插入圖片描述

當你比較“Elements”版本和“View source”版本的區別,你會輕易看到區別:前者有個可見的<p>標籤,作爲<div id="container">的子節點。之前的“Source”中並無該節點,因爲它並不是源碼的一部分。

如果你用AngularJs,React,Vue.js,Ember.js等處理過單網頁應用。你會在“Elements”中看到大量動態生成的內容。這些內容各有不同,但在表單、動態分頁排序列表、搜索項等大量元素中,很容易發現DOM型XSS漏洞,用戶輸入也常在模板表達式中解析(如:AngularJS的{{}})。

原因在於這類應用經常用GET、POST請求,或Cookies、瀏覽器Storage的內容來構建網頁。當然,它們自己會生成大量內容。這裏也容易發現一些薄弱點。

在查看JavaScript之前值得一說的是:一定要讀一讀HTML註解,你會發現不少沒有渲染進頁面的元素,裏面常有意外之喜。

分析cookies和瀏覽器Storage

DevTools也可以用來檢查網站保存在客戶端的信息。有幾處可被web應用利用。最常見的就是cookies——它是一段以名稱定義的數據(你可以認爲它的結構是鍵值對)並在服務器和瀏覽器的HTTP交互中交換。

瀏覽器Storage是另一處你能發現有用信息的地方。有兩種Storage:本地Storage和會話Storage,區別在於會話Storage在關閉應用時(關掉瀏覽器標籤頁或瀏覽器時)會註銷掉。本地Storage將留存很長時間,除非被手動清理(數據沒有過期一說)。

想看到所有的存儲信息,你只需使用工具集的“Application”功能:

在這裏插入圖片描述

使用“Application”功能不僅能看到內容,還能修改、刪除和添加自己的鍵值對,這能引起意想不到的響應甚至發現漏洞。這也是檢查水平越權最容易的辦法,你可以替換會話token或更改cookie中保存身份信息的值來僞裝成其他用戶(這只是個例子,現在的web應用大多用多種方法認證用戶,在多數情況下,更改一個cookie的值不足以劫持其他用戶的會話):

在這裏插入圖片描述

這裏還有另一處可以查看與web應用關聯的Js源碼的地方:“Service Workers”。在網上可以找到該功能更多的介紹https://developers.google.com/web/fundamentals/primers/service-workers/。該功能比較新,沒有很多的web應用使用它。但它們的有些信息還是能揭示應用的工作流程,特別是下線後的行爲。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章