在這個手冊中，我將展示如何用web瀏覽器的內置工具去分析客戶端的源碼。這可能就會有一些奇怪的聲音，可能瀏覽器不是執行這個任務最好的選擇，但是在你更深入之前，我們打開Burp Suite來攔截一下http的請求，或者在這裏或者用alert(1)去尋找無盡的xss，首先去了解你的目標總是很好的主意
這篇文章主要面向的是那些對HTML和JavaScript代碼沒有經驗或經驗很少的賞金獵人，但是我希望更有經驗的黑客也能發現其中有趣的東西。
我最近的一篇介紹基本操作的推文獲得了社區很多的關注後，我就覺得應該寫一篇這樣的文章了。
這個簡單的想法其實冰山的一角，如果我把這些小技巧全都發到推特上，那麼其他人會很容易錯過，所以我決定收集這些小技巧，然後把他們寫成博客。我希望你們能找到一些有用的東西。
好了，讓我們開始吧
工具集
每一個現代瀏覽器都會內置開發者工具，爲了啓動他們，你可以使用Ctrl+Shift+I, CMD+Option+I (macOS)，F12鍵或者在瀏覽器右邊的菜單選項–這依靠你所使用的操作系統和瀏覽器。雖然在這篇文章中，我使用的是最新版本的Chromium，如果你使用Firefox, Safari, Chrome or Edge，他們除了UI，其他的沒有什麼不同。你可以隨便選擇你喜歡的瀏覽器，但是你會發現Chrome 開發者工具是最強大（Chrome開發者工具或者輕量級開發工具可以兼容Chrome, Chromium, Brave, Opera 或者其他基於Chromium 內核的瀏覽器）
你要安裝好IDE（集成開發環境）或者任何一款帶html和JavaScript代碼高亮的編輯器。這些都是基於你自己的喜好，但是我發現Visual Studio Code特別好用（順便說明，我用VSCode做所有的事情，包含我在我的工作中也會使用）。你可以用下面這個鏈接來下載適合你係統的VSCode
https://code.visualstudio.com/
安裝NodeJS也是一個很不錯的主意(只要經常用它就會越來越熟悉的–在互聯網確實有成千上萬的資源)。比較好用的在 https://nodejs.org/en/
python對我來說也是一個必備工具（如果你使用基於*NIX的系統，你就有機會去使用它，並且它已經安裝好了。如果你是windows用戶，你必須自己手動安裝Python）。能用Python寫代碼的能力是無價的，並且我建議那些從來沒有寫過代碼的人可以試着使用一下Python
對於在終端中運行和測試JavaScript代碼NodeJS是非常有用的（你也可以在瀏覽器中實現，但是我們稍後會談論到它們的優點和缺點）。你可以用Python創建你自己的腳本工具，這些工具可以很快的驗證漏洞也可以實際的去利用它–我也會在這篇文章中展示我自己的工具。如果你解釋其他的解釋型語言（像 Ruby, PHP, Perl, Bash等），你也可以使用它們。上面這些語言的主要好處在於它們不用編譯就可以運行,也可以直接用命令行把它們執行起來。它們可以百分之百的跨平臺，而且你可以使用網絡上的很多庫和模塊。
OK，現在終於都弄清楚了
查看HTML源碼
讓我們回到剛纔我引用的那個推文上去。你可能會注意，截屏的網頁似乎沒有內容，似乎僅僅是空白頁面。
但是你要看網頁的源代碼（用CTRL+U 或者在mac上用CMD+Option+U）你會看到大量的代碼（不幸的是，我不能提供截屏中的那個網站的url，因爲那是一個衆測項目的私有項目）。爲什麼那些元素不會展現在瀏覽器中？
重要的事情是，有些HTML標籤不會在頁面中展現任何東西，HTML中有很多這樣的標籤，我在這裏舉一些基本的例子<html>, <head>, <body>, <style> or<script>。並且，css也可以因此一些元素（比如，通過設置元素的高和寬都爲0，或者設置display爲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頁面，它不會顯示任何東西並且你也不會從中看到任何東西。但是當你查看源碼的時候，你會發現很多有趣的東西。
這裏面有很多有價值的信息：urls指向了內部的資源，帶有登錄框頁面的隱藏框架，甚至診斷信息中帶有認證信息，而這些信息可以顯示開發者工具的console中。雖然這個頁面中沒有顯示任何東西。當然，你不要指望你會在每一個網站上面發現這些信息，可是在常見的情況中，很多JavaScript代碼是被註釋掉的，有時你能通過這些代碼發現那些仍然可以被訪問的服務器端api接口。
但是如果只查看源代碼的話不會看到所有的東西，因爲它只會呈現當前的HTML文檔，被<iframe>,<script>等類似的標籤加載的外部資源會包含更多有趣的東西。你會在Chrome開發者工具中看到這些資源的源碼：
樹狀圖最底部的那個按鈕是主HTML文檔，你可以用“查看源”這個選項去查看它們。所有的資源都會以標準的文件夾和文件樹的形式所呈現。如果你點開這些文件，它們的內容就會顯示在右邊。在上面那個截圖中，就是jquery.min.js的文件內容，並且你會經常發現這些JavaScript文件的壓縮版本（從web應用程序的性能角度來看，這是很好的習慣）。但是如果你點擊最下面那個小圖標{}，開發者工具將會“解壓”這些代碼，讓這些代碼變的可讀。
一些網站會使用一種特殊的功能去安排源碼（變形後，真正代碼中的變量名，函數名，對象名會被替換掉，而這個也會被用於代碼壓縮中–你會在 https://developers.google.com/web/tools/chrome-devtools/javascript/source-maps 找到關於源碼映射的資料。通過給對象提供有意義的名字，同時替換掉那些被壓縮的JavaScript變量，可以讓格式化後的代碼更易讀。
另一個更強大的功能是tab中的全局搜索。假設，你發現了一個有趣的函數，你想要找到它在哪裏調用的。可能這個函數中包含eval函數，它的參數來自於url，這樣你就可以用這個url來執行任意JavaScript代碼了。你可以使用CTRL+Shift+F（在mac系統中你可以用CMD+Option+F）去使用全局搜索這樣功能。在下圖這個例子中，我試圖在 AppMeasurement.js中尋找所有引用getAccount函數的地方。你會看到這個函數僅僅被調用了一次，還是在同一個文件中，如果在其他文件中找到這樣的字符串，它就會被顯示在結果列表中:
有時，你會發現搜索結果在非常，非常長的字符串之中（尤其是那種經過壓縮後的JavaScript文件）。你用開發者工具打開這個文件，點下面的{}圖標，之後就會在右邊展示解壓之後的代碼了，即使這個文件有好幾千行都沒有問題。
開發者工具的第二個tab被稱爲Elements。如你所見，對於在(index)中的源碼來說（或者你以源碼模式查看網頁源代碼），Elements這個tab有一點非常大的不同，雖然在Elements中也提供了內容。
前者顯示從服務器端加載的HTML文件，Elements則會顯示你當前的dom樹，包括通過JavaScript代碼創建和添加的元素。爲了明白這點的不同，我會提供一個小的例子，但是首先，我要先介紹一點原理。
DOM(文檔對象模型)實際代表了所有的html節點，dom樹有一個根節點(<html>)，還有兩個重要的子節點<head>和<body>,所有的其他元素要麼是<head>的子節點（像<title>或 <meta>,要麼是<body>的子節點（<div>, <p>, <img>等）
當你在你的瀏覽器中個打開一個url時，HTML文件首先會被加載進來，然後代碼會被瀏覽器引擎所解析。當瀏覽器發現<script>或者<style>標籤時（或者其他帶src屬性的標籤時，像image 文件或者 video 文件時），它會停止解析HTML並且加載那些文件。如果要執行JavaScript代碼時，這些代碼也會被馬上的執行。如果有樣式表的話，css解析器也會把css代碼解析成css樣式規則。所有的事情原理就像下面這張圖一樣（這個圖非常簡單，但是足夠說明這些基本的概念）
Elements所包含的內容和源碼所包含的內容不同之處是什麼呢？像下面這個例子，JavaScript添加一個元素到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>
當你打開瀏覽器並查看源碼時，你會發現所呈現的內容和上面的代碼是一樣的。
在這個非常簡單的例子中，JavaScript添加一個元素到DOM樹中。爲了看清這樣的不同，在開發者工具中使用Elements tab去查看
當你對比Elements標籤的中的內容和查看源代碼中的內容，你會很容易發現它們的不同點。在Elements標籤頁中，你可以看到<p>元素之間的內容，它被添加到了<div id=”container”>元素的子節點中。你源碼模式中不會看到這些元素，因爲它們不存在於源代碼中。
如果你用一些框架處理這些單頁應用，例如AngularJS, React, Vue.js, Ember.js等。你會看到大量的動態內容被添加到標籤之中。這些內容包含變量，還有表單，帶分頁，排序搜索屬性的動態表格或列表。這些元素會造成大量DOM XSS的產生，或者前端模板會解析用戶的輸入（像AngularJS會解析{{ }}）
漏洞的原因在於，應用常常使用來自GET請求，POST請求中，保存在cookie中的數據或者瀏覽器存儲中的數據去渲染網站應用中的內容。並且應用自己也會創建很多東西，所以總是會有機會去發現各種各樣的漏洞。
在我們進入到JavaScript這一章節之前，還有一點非常重要的事情要說，你要注意網頁源代碼中那些沒有被渲染的註釋。你會發現非常多有價值的東西。
查看cookie和瀏覽器存儲
你用開發者工具做的另外一件事情就是去檢查那些存儲在客戶端上的信息。網站應用經常會用到兩個地方。其中最常見的就是cookie–通過名稱來識別的一小片數據（其實cookie就是簡單的鍵-值對數據），通過http請求包和返回包，cookie會在客戶端和服務器端來回交換。
瀏覽器存儲是另一個地方，你會在其中發現很多有價值的東西。它們有兩種存儲形式：本地存儲和session存儲。這兩種存儲方式的不同點在於，當你關閉應用時，session會消失（當你關閉瀏覽器的tab時或者關閉整個瀏覽器時）。而如果你沒有指定時間的話，本地存儲會保存相當一段時間（數據本身沒有過期時間）
你可以使用開發者工具中的Application tab去查看所有存儲在本地的信息。
使用Application tab你不僅僅能看到這些數據的內容，你還可以去修改，刪除，和增加你自己所需要的鍵以及對應的值，修改這些值之後，應用可能會發生一些不可思議的現象，有時甚至會觸發漏洞。通過這樣的方式去修改session token，看會不會導致越權的產生–只要改變維持會話的cookie值就可以了（這僅僅是一個例子，現代web應用程序使用幾種不同的方式去識別用戶並且僅僅改變單個cookie不足以冒充爲其他的用戶）
這個標籤頁上還有一個位置，你可以在那個上面發現JavaScript源碼和web應用程序的關係：Service Workers。你可以在下面這個網站中找到關於Service Workers的介紹 – https://developers.google.com/web/fundamentals/primers/service-workers/
這裏還是有不少新的東西，不僅許多web應用程序會用到，還可以用它分析web應用是如何工作的，尤其在web應用離線時。
分析JavaScript
現在我們來到代碼這一章節，這些代碼會運行在整個web應用之中（HTML和css僅僅只會作爲展示，它們不會包含任何邏輯。但還是有一小部分css的表達式可以運行JavaScript代碼，這種特性會導致xss漏洞–但是在純HTML和css組成的網頁中，這樣的機會不是很多）
有幾種方式去分析JavaScript代碼，我們先用瀏覽器中的工具試試。我已經介紹了關於Sources 標籤和如何使用{}這個功能來讓壓縮後的代碼變的可讀。但是你可以用開發者工具做更多的事情其中最好用的一個就是JavaScript的debugger
使用DevTools debugger
如果你不瞭解debug是什麼，那麼通俗來說，就是讓程序停在某一行代碼上。這讓你可以看到實際的變量值，實際所執行的函數和函數怎麼樣被調用的（這個優點主要得益於調用棧–debugger展示了函數的調用順序，像函數a被函數b調用，在此之前，函數b被另一個函數c調用）。並且debugger允許你單步運行代碼（一條指令），這可以讓你有機會跟蹤程序的每一次改變和其中的狀態。最後一點，debugger可以修改運行時的程序，這意味着，當你修改變量時甚至程序自身的邏輯時，程序將會發生什麼。高效的使用debugger是一種非常好的方式，我認爲這是每一個優秀程序員都應該具備的重要技能。
從賞金獵人的角度來看，debugging可以讓你更好的明白程序是怎樣工作的，你也可以直接測試你的payload。你也可以很輕鬆的直接從程序中分離出有漏洞的代碼，並且可以用debugger給予你的有力工具去測試這些東西。例如，想象一下，你發現了一個有任意重定向漏洞的函數，你想了解這個函數每一次到底做了什麼，這個函數被調用之後瀏覽器就被重定向到了一個外部的資源，當你被重定向之後，你不會重定向之後的頁面裏面看到上一步頁面的代碼。
在重定向函數之前設置一個設置斷點，瀏覽器運行到重定向函數之前就可以停下來，現在你去讀取函數的源代碼，去了解這個函數是如何工作的，想清楚你要如何注入你的payload，是否需要將你的payload進行編碼或者去做其他的事情。
瞭解完原理之後，就去練習一下。
下面這個代碼實現了一個簡單重定向的功能
<html>
<head>
<title>Redirection</title>
</head>
<body>
</div>
<script>
// imagine that read url from GET parameter routine goes here...
// but we just hardcode it for now :)
const url = 'https://hackerone.com'
function redirect() {
// I will redirect you! Now!
if (url) {
location.href = url
} else {
location.href = 'https://company.com/__internal__/supersecretadminpanel'
}
}
setTimeout( redirect, 10000 )
</script>
</body>
</html>
當你用瀏覽器打開這個網站，十秒後，你就會重定向到HackerOne 這個網站中，之後你就再也看不到原始的代碼了，因此，你可以不能看到剛纔發生的事情。
在瀏覽器中打開開發者工具，然後選擇源代碼標籤，然後打開上面的HTML文件。現在你有10秒鐘的時間在源碼的第16行設置斷點(if (url) {)。你只要在左邊那個帶數字的框框上點16那個數字就好了。當十秒過去之後，瀏覽器就會調用redirect()，然後馬上會停到你下斷點的那一行：
當我們向下走一步之後，藍色的那一行就會被執行（藍色那一行現在還沒有執行！這是非常重要的）。你看debugger面板的左側–那裏會展示你現在在哪個位置（調用棧）然後，你如果打開script那個節點，你會看到在執行過程中所有被定義的變量的值（在這個例子中只有url）
現在你需要花費一些時間去閱讀和理解這些代碼。如你所知，如果16行的那個條件語句爲TRUE的時候，我們將會跳轉到HackerOne那個網站
讓我們修改url這個值，我們去修改一些東西，那麼JavaScript中什麼樣的值會讓邏輯判斷語句認爲這是一個false呢（可能是空的字符串，0，布爾 false，或者其他代表false的表達式）。讓我們把他變成false吧（只要點擊變量，然後輸入你想要的值，就可以改變這個變量的值了）
現在讓我們看看發生了什麼樣的改變。我們將繼續走入到下一步，看看debugger面板最頂部上面的圖標：
第一個圖標將讓你繼續運行這個程序，第二個圖標允許你單步運行（我們一會再說這個），第三個圖標允許你跳轉進到被調用的函數之中（只要那裏沒有設置斷點，debugger不會進入到函數中去的，它會執行那一行的函數，然後移到下一行去執行），這裏有一個叫“跳出”的圖標，這個圖標可以讓函數繼續執行，然後跳轉到被調用的那一個點
現在點擊第二個圖標（你會看到url的值已經變成了false），然後你會注意到執行的下一行代碼變成了19行（這是因爲我們在16行判斷語句中設置了false）
如果你按下debugger工具欄上第一個按鈕之後（“Play”按鈕），這次你會注意到應用會跳轉到一個company.com中的一個鏈接裏面去。
你會想到url這個參數可能會是一個漏洞，所以你現在嘗試去利用這個問題去發現任意跳轉漏洞或者反射型xss漏洞，或者更深一步，你會懷疑這個url會存儲在服務器端的某個位置（如果你進一步探索程序內部的邏輯，就能發現你的想法是否是正確的）
用Snippets執行JavaScript
有時，你想執行應用中的一部分代碼。這可能比較困難，特別是遇到要做大量前置準備工作之後才能觸發的代碼，就會特別耗時。在這種情況下，你可以使用Snippets去運行你的代碼。但是要記住，每一次測試都不會很順利，比如當你運行一些需要其他依賴的代碼時，通常像一些變量會來自其他部分的代碼或者代碼片段中包含來自其他文件中函數。
但是讓我們假設，你要檢測一個函數，以檢查它所提供的值是否是正確的，並且你希望你只關注代碼的邏輯部分。
在源碼標籤，你會發現一個叫Snippets的面板
當你點擊它的時候，你會發現一些片段列表（如果你已經創建了所有的東西）然後可以點擊創建new去創建一個新的片段。點擊這個選項，然後在控制面板中間的位置，你會看到一些簡單的示例代碼，這些代碼是可被編輯的而且帶有代碼高亮。你可以把所有的JavaScript代碼放上去運行，當你點擊位於控制面板左下底部的play按鈕（或者你可以用CMD+Enter，在mac系統上你可以用CTRL+Enter）後，你會發現結果會馬上打印到下面的控制檯面板上去。
你可以無限制的修改和運行你的代碼，但是我剛纔提到，代碼在這裏運行時會遇到依賴問題。
Snippets中代碼運行於你打開開發者工具的那個頁面，你可以在snippet創建和運行你的代碼。並且，每一次代碼的運行環境都是相同的，這就意味者你之前定義的所有變量依然沒有被改變，並且會一直保留那些值。
爲什麼這很重要？
想想下面的這個例子：
在JavaScript中，當你使用const關鍵字定義一個常量的時候，你會初始化它的值，並且不會去改變他。如你所見，代碼片段按照預期的行爲去工作，但是你如果試圖改變SOME_CONST的值，再次運行snippet，你會受到下面的這個語法錯誤：
這個錯誤是因爲SOME_CONST這個靜態變量已經被初始化。開發者工具就想，你要在同一個執行環境中繼續執行,你編輯的代碼已經變的不重要了。
所以你如果用debugger停止正在運行的程序（所有通過程序代碼定義的變量，類和函數將會存在於執行環境之中）。如果你試圖使用現有的標誌在同一個標籤頁中創建snippet–有時你要麼會覆蓋原來網頁的代碼，要麼在 重新初始化某些變量時會讓頁面報錯（比如常量）。爲了能夠重新運行snippet，首先你要通過刷新瀏覽器來重新加載頁面，清空執行環境（瀏覽器不會記住web應用的狀態的，只要刷新之後，整個進程會重新加載資源，重建DOM樹，等等）
爲了避免上面的問題，不要使用Snippets（還有有一種比較好的辦法，就是你新開一個瀏覽器標籤頁，然後打開開發者工具並在那裏創建一個新的snippet），你可以使用NodeJS來運行你的JavaScript代碼
你可以把你的代碼放入一個新的JavaScript文件中，然後用在終端中用NodeJS（你要確定你已經安裝好了）運行它：
我將運行三次這個代碼，每一次我都會修改SOME_CONST的值。如你所見，沒有任何報錯，而且每一次執行都會成功，輸出的結果也都是正確的。
這是因爲，你用NodeJS運行這個代碼的時候，它都會創建一個新的執行環境，所以，它不會把一份代碼在相同執行環境中運行兩次。
Sources 和 execution sinks
當你看JavaScript代碼時，首先你要着重注意兩個地方
首先第一個是sources，這個術語描述了，用戶輸入的每一個點都應該被應用程序所處理。GET請求中的url裏面的參數，能被應用程序讀取到的cookie或者應用程序使用到的本地存儲。
第二個被稱爲execution sink，這個術語意味着，所有的JavaScript語法元素或者那些可以執行代碼的HTML API。一個很明顯的例子就是JavaScript中的eval(code_to_evaluate)，這個函數可以通過參數來執行代碼。另一個例子是setTimeout(function_to_execute, timeout_in_miliseconds),可以通過這個函數的第一個參數去執行一個函數，前提是要等到第二個參數的時間到了之後纔可以執行。
在應用程序中發現漏洞的過程就是尋找source和處理此source的execution sink之間的連接。在上面這個例子中，我將展示如何使用debugger，url作爲參數(source) 被直接放入location.href (execution sink) 中。另一個例子是，一個函數會獲取HTML輸入框中用戶輸入的數據（JavaScript能通過DOM API讀取到這些數據，例如document.getElementById(‘input_id’).value,然後把這些值傳遞給一個變量，這也可能會是一個source。）然後這個值會被放入到innerHTML()函數中，之後這個函數會更新瀏覽器中DOM（這就會成爲一個execution sink）
這裏有一個非常棒的視頻，它的作者是@LiveOverflow。我建議你馬上去看看這個視頻以熟悉它概念（這個視頻大概8分鐘長）
在web應用程序中，由於其複雜的業務邏輯，會存在非常多的sources 和 execution sinks（想想那些輸入框，url參數，cookie，瀏覽器存儲，WebSockets等）。但是重要的東西是那些可以被作爲execution sinks的函數。它們也有很多，像location屬性：href or hash, window.open(), document.write()，或者DOM函數：innerHTML 或者 appendChild。它們都可以執行任意代碼，任意跳轉，或者執行其他類型的注入。
爲了識別上面這些代碼特徵，我寫了一個工具nodestructor，這個工具可以檢查JavaScript文件（參數是單個文件或者包含所有JavaScript文件的文件夾），這個工具可以根據特徵尋找execution sinks（或者sources）。不要指望nodestructor會識別每一行代碼或者更容易的去利用–所有的東西都應該依賴於source 和 execution sink（過濾，編碼，解析，將數據轉換爲object，字符串操作等）。這個工具的主要目的是更容易和更快速的在大量代碼中通過規則來尋找有漏洞的代碼。
讓我們用一個例子來快速的展示這個工具吧。首先，我需要一個JavaScript文件。我將檢查來自GM.com 網站的AppMeasurement.js。然後我把這個文件從瀏覽器中複製下來（首先要解壓，並格式化好），然後粘貼到代碼編輯器中，然後後保存在一個臨時文件夾中。
在終端中，我在AppMeasurement.js文件上運行nodestructor（-H參數是讓這個工具去搜索各種HTML5的APIs）
如你所見，這個工具識別了大量潛在的execution sinks。它們中大多數都是誤報，但是讓我們集中精力去看看報告結果中的第二個，它看起來像是直接用location.hostname.toLowerCase() 這個函數的結果來初始化domain這個變量。
如果有可能在這個文件中去跟蹤這些變量所有的引用，看看它是否被用在了execution sink中。你也可以使用Visual Studio Code內置工具像Find all references去尋找所有的domain字符串。
我想進一步來挖掘更多的漏洞，所以不久前，我已經開始用我的工具去做這樣的事情了–這個是一個簡單的JavaScript靜態分析工具，所以它沒有很花哨的名字。這個工具仍處於開發的早期階段（它雖然現在還只是個poc，但其實已經很好用了），當我運行這個工具去查找domain這個變量時，它會很快的給出結果的預覽（到目前爲止，這是唯一可用的選項，正如我所提到的一樣，這個工具僅僅只是一個雛形，所以例如文件名這樣的東西，看上去就像硬編碼在代碼裏面一樣）
如你所見，工具能識別變量在哪裏被定義的，在什麼時候或者什麼地方被怎樣使用的。我希望工具能夠執行更復雜的分析，像是在不同範圍內尋找變量（例如，變量是否是一個函數的參數或者變量是否被當成execution sink中的參數）
總結
web瀏覽器十一個非常強大的工具。有時，你僅僅會用這個工具去讀源代碼和了解應用程序是如果工作的，還可以用瀏覽器尋找漏洞，測試你發現的漏洞，或者僅僅是去了解它是如何工作的並且去了解一些新的東西。
我希望我的文章能讓你瞭解到如何使用瀏覽器開發者工具這一強大功能。你能通過下面的這個鏈接找到更多強大的工具。
https://developers.google.com/web/tools/chrome-devtools/
如果你有任何問題或者對這篇文章有好的建議–不要猶豫，來推特上找我 https://twitter.com/_bl4de
感謝你對閱讀，我希望你能找到更多有價值的漏洞
Happy Hacking!