第四章 漏洞發(fā)現(xiàn)

作者：Gilberto Najera-Gutierrez
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0

簡介

我們現(xiàn)在已經(jīng)完成了滲透測試的偵查階段，并且識別了應(yīng)用所使用的服務(wù)器和開發(fā)框架的類型，以及一些可能的弱點?，F(xiàn)在是實際測試應(yīng)用以及檢測它的漏洞的時候了。

這一章中，我們會涉及到檢測一些 Web 應(yīng)用中常見漏洞的過程，以及允許我們發(fā)現(xiàn)和利用它們的工具。

我們也會用到 vulnerable_vm 中的應(yīng)用，我們會使用 OWASP Mantra 作為瀏覽來執(zhí)行這些測試。

4.1 使用 Hackbar 插件來簡化參數(shù)分析

在測試 Web 應(yīng)用時，我們需要和瀏覽器的地址欄交互，添加或修改參數(shù)，以及修改 URL。一些服務(wù)器的相應(yīng)會包含重定向，刷新以及參數(shù)修改。所有這些改動都會使對相同變量嘗試不同值的操作非常費時間。我們需要一些工具來使它們不那么混亂。

Hackbar 是 Firefox 插件，它的行為就像地址欄，但是不受由服務(wù)器響應(yīng)造成的重定向或其它修改影響，這就是我們需要測試 Web 應(yīng)用的原因。

這個秘籍中，我們會使用 Hackbar 來簡化相同請求的不同版本的發(fā)送工作。

準(zhǔn)備

如果你沒有使用 OWASP Mantra，你需要在你的 Firefox 上安裝 Hackbar。

操作步驟

  • 1.訪問 DVWA 并且登錄。默認(rèn)的用戶名/密碼組合是admin/admin。

  • 2.在左側(cè)的菜單上選擇SQL Injection（SQL 注入）。

  • 3.在User ID輸入框中輸入數(shù)字，并點擊Submit（提交）。
    現(xiàn)在我們可以按下F9或者點擊圖標(biāo)來顯示 Hackbar。

Hackbar 會賦值 URL 及其參數(shù)。我們也可以開啟修改 POST 請求和 Referer 參數(shù)的選項。后者告訴服務(wù)器頁面從哪里被請求。

  • 4.讓我們做個簡單的改動，將id參數(shù)值從1改成2，并點擊Execute（執(zhí)行）或者使用Alt + X快捷鍵。

我們可以看到，參數(shù)id對應(yīng)頁面上的文本框，所以，我們可以使用 Hackbar 修改id來嘗試任何值，而不需要修改文本框中的User ID并提交它。在測試擁有許多輸入的表單，或者取決于輸入重定向到其它頁面的表單時，這非常便利。

  • 5.我們可以將一個有效值替換為另一個，但是如果我們輸入了一個無效值作為id，會發(fā)生什么呢？嘗試將單引號作為id：

通過輸入應(yīng)用非預(yù)期的字符，我們觸發(fā)了一個錯誤，這在之后測試一些漏洞的時候非常有用。

工作原理

Hackbar 是帶有一些實用特性的第二個地址欄，比如不受 URL 重定向影響，并且允許我們修改 POST 參數(shù)。

此外，Hackbar 可用于向我們的請求中添加 SQL 注入或跨站腳本代碼段，以及哈希、加密和編碼我們的輸入。我們會在這一章后面的秘籍中深入探索 SQL 注入、跨站腳本，以及其他漏洞。

4.2 使用 Tamper Data 插件攔截或修改請求

有時候，應(yīng)用擁有客戶端的輸入校驗機(jī)制，它們通過 JavaScript，隱藏表單或者 POST 數(shù)據(jù)，并不能直接在地址欄中了解或看到。為了測試這些以及其它類型的變量，我們需要攔截瀏覽器發(fā)送的請求并且在它們到達(dá)服務(wù)器之前修改它們。這個秘籍中，我們會使用叫做 Tamper Data 的 Firefox 插件來攔截表單提交并且在它離開計算機(jī)之前修改一些值。

操作步驟

  • 1.從 Mantra 的菜單中訪問 Tools | Application Auditing | Tamper Data。

  • 2.會出現(xiàn) Tamper Data 的窗口?，F(xiàn)在，讓我們?yōu)g覽http://192.168.56.102/dvwa/login.php。我們可以在插件中看到請求會話。

每個瀏覽器產(chǎn)生的請求都會在活動時經(jīng)過 Tamper Data。

  • 3.為了攔截請求并修改它的值，我們需要通過點擊Start Tamper來啟動 Tamper?，F(xiàn)在啟動 Tamper。

  • 4.輸入一些偽造的用戶名密碼組合。例如，test/password，之后點擊Login。

  • 5.在確認(rèn)框中，取消勾選Continue Tampering?并點擊Tamper。Tamper Popup窗口會出現(xiàn)。

  • 6.在彈出窗口中，我們可以修改發(fā)送給服務(wù)器的信息，包括請求頭和 POST 參數(shù)。將username和password改為正確的（admin/admin），之后點擊OK。這應(yīng)該在本書中使用，而不是 DVWA：

在最后一步中，我們在表單中的值由瀏覽器發(fā)送給服務(wù)器之前修改了它們。因此，我們可以以正確的憑證而不是錯誤的憑證登錄服務(wù)器。

工作原理

Tamper Data 會在請求離開瀏覽器之前捕獲請求，并提供給我們時間來修改它包含的任何變量。但是，它也有一些限制，例如不能編輯 URL 或 GET 參數(shù)。

4.3 使用 ZAP 來查看和修改請求

雖然 Tamper Data 有助于測試過程，有時我們需要更靈活的方法來修改請求以及更多特性，例如修改用于發(fā)送它們的方法（即從 GET 改為 POST），或者使用其它工具為進(jìn)一步的目的保存請求/響應(yīng)對。

OWASP ZAP 不僅僅是 Web 代碼，它不僅僅能夠攔截流量，也擁有許多在上一章所使用的，類似于爬蟲的特性，還有漏洞掃描器，模糊測試器，爆破器，以及其它。它也擁有腳本引擎，可以用于自動化操作或者創(chuàng)建新的功能。

這個秘籍中，我們會開始將 OWASP ZAP 用作代理，攔截請求，并在修改一些值之后將它發(fā)送給服務(wù)器。

準(zhǔn)備

啟動 ZAP 并配置瀏覽器在通過它發(fā)送信息。

操作步驟

  • 1.訪問 http://192.168.56.102/mutillidae/。

  • 2.現(xiàn)在，訪問菜單欄中的OWASP Top 10 | A1 – SQL Injection | SQLi – Extract Data | User Info。

  • 3.下一步是提升應(yīng)用的安全等級。點擊Toggle Security?，F(xiàn)在Security Level應(yīng)該是1 (Arrogant)。

  • 4.將test'（包含單引號）作為Name，以及password'作為Password，并且點擊View Account Details。

我們得到了警告消息，告訴我們輸入中的一些字符不合法。這里，單引號被檢測到了，并被應(yīng)用的安全手段中止。

  • 5.點擊OK來關(guān)閉警告。
    如果我們在 ZAP 中檢查歷史，我們可以看到?jīng)]有發(fā)給服務(wù)器的請求，這是由于客戶端校驗機(jī)制。我們會使用請求攔截來繞過這個保護(hù)。

  • 6.現(xiàn)在我們開啟請求攔截（在 ZAP 叫做斷點），通過點擊break on all requests（中斷所有請求）按鈕。

  • 7.下面，我們輸入了有效值Name和Password，就像test和password，并再次檢查細(xì)節(jié)。
    ZAP 會轉(zhuǎn)移焦點，并打開叫做Break的新標(biāo)簽頁。這里是剛剛在頁面上產(chǎn)生的請求，我們可以看到一個 GET 請求，帶有在 URL 中發(fā)送的username和password參數(shù)。我們可以添加上一次嘗試中不允許的單引號。

  • 8.為了繼續(xù)而不會被 ZAP 打斷，我們通過點擊Unset Break按鈕來禁用斷點。

  • 9.通過播放按鈕來提交修改后的請求。



    我們可以看到，應(yīng)用在頂部提供給我們錯誤信息，所以這是它的保護(hù)機(jī)制，它在客戶端檢查用戶輸入，但是在服務(wù)端并沒有準(zhǔn)備好處理非預(yù)期的請求。

工作原理

這個秘籍中，我們使用 ZAP 代理來攔截有效的請求，將它修改為無效或而已請求，之后把它發(fā)給服務(wù)器并且觸發(fā)非預(yù)期的行為。

前三步用于開啟安全保護(hù)，便于應(yīng)用可以將單引號檢測為無效字符。

之后，我們產(chǎn)生測試請求，并證實了會執(zhí)行一些校驗。提示警告的時候，沒有請求通過代理，這告訴了我們檢驗是在客戶端進(jìn)行的，可能使用 JavaScript。知道了這個之后，我們產(chǎn)生了合法的請求，并使用代理來攔截它，這讓我們能夠繞過客戶端的保護(hù)。我們將該請求轉(zhuǎn)換為惡意請求，并把它發(fā)給服務(wù)器，這使它不能被正確處理，并返回錯誤。

4.4 使用 Burp Suite 查看和修改請求

Burp Suite 和 OWASP ZAP 一樣，也不僅僅是個簡單的 Web 代理。它是功能完整的 Web 應(yīng)用測試包。它擁有代理、請求重放器、請求自動化工具、字符串編碼器和解碼器，漏洞掃描器（Pro 版本中），以及其它實用的功能。
這個秘籍中，我們會執(zhí)行上一個練習(xí)，但是這次使用 Burp Suite 的代理功能來攔截和修改請求。

準(zhǔn)備

啟動 Burp Suite 并讓瀏覽器使用它的代理。

操作步驟

  • 1.瀏覽 http://192.168.56.102/mutillidae/。

  • 2.默認(rèn)情況下，Burp 代理中的攔截器是開著的，所以他會捕獲第一個請求。我們需要打開 Burp Suite 并點擊Proxy標(biāo)簽頁中的Intercept is on按鈕。

  • 3.瀏覽器會繼續(xù)加載頁面。當(dāng)它完成時，我們通過Toggle Security將當(dāng)前的應(yīng)用安全級別設(shè)置為1 (Arrogant)。

  • 4.從菜單欄中訪問OWASP Top 10 | A1 – SQL Injection | SQLi – Extract Data | User Info。

  • 5.在Name輸入框中，對Username輸入user<>（包括符號）。在Password輸入框中，對Password輸入secret<>。之后點擊View Account Details。
    我們會得到警告，告訴我們我們可能向應(yīng)用輸入了一些危險字符。

  • 6.現(xiàn)在我們直到這些符號在表單中并不允許，我們也知道了它是客戶端的校驗，因為代理的HTTP history標(biāo)簽頁中沒有任何請求出現(xiàn)。讓我們嘗試?yán)@過這個保護(hù)。通過點擊 Burp Suite 中的Intercept is off來開啟消息攔截。

  • 7.下一步是發(fā)送有效數(shù)據(jù)，例如user和secret。

  • 8.代理會攔截該請求?，F(xiàn)在我們修改username和password的值，通過添加禁止的字符<>。

  • 9.我們可以發(fā)送編輯后的信息，并通過點擊Intercept is on來禁用攔截，或者我們可能發(fā)酸發(fā)送他并保持消息攔截，通過點擊Forward。對于這個練習(xí)，我們禁用攔截并檢查結(jié)果。

工作原理

就像在上個秘籍中看到的那樣，在請求經(jīng)過由應(yīng)用建立在客戶端的驗證機(jī)制之前，我們使用代理來捕獲請求，并通過添加一些在檢驗中不允許的字符，修改了它的內(nèi)容。

能夠攔截和修改請求，對任何 Web 應(yīng)用滲透測試來說都非常重要，不僅僅用于繞過一些客戶端檢驗，就像我們在當(dāng)前和上一個秘籍中所做的那樣，也能夠用于了解發(fā)送了哪個信息，以及嘗試?yán)斫鈶?yīng)用的內(nèi)部原理。我們可能也需要基于我們的理解來添加、移除或替換一些值。

4.5 識別跨站腳本（XSS）漏洞

跨站腳本（XSS）是 Web 應(yīng)用中最常見的漏洞之一。實際上，它位于 2013 年 OWASP Top 10 的第三名。

操作步驟

  • 1.登錄 DVWA 并訪問反射型 XSS。

  • 2.測試漏洞的第一步是觀察應(yīng)用的正常響應(yīng)。在文本框中輸入名稱并點擊Submit按鈕。我們使用Bob。

  • 3.應(yīng)用會使用我們提供的名稱來拼接代碼。如果我們不輸入有效名稱，而是輸入一些特殊字符或數(shù)字會怎么樣呢？讓我們嘗試<'this is the 1st test'>。

  • 4.現(xiàn)在我們可以看到，我們輸入在文本框匯總的任何東西都會反射到響應(yīng)中，也就是說，它成為了響應(yīng)中 HTML 頁面的一部分。讓我們檢查頁面源代碼來分析它如何展示信息，就像下面截圖中那樣：


    源碼表明了輸出中沒有對任何特殊字符做編碼。我們發(fā)送的特殊字符被反射回了頁面，沒有任何預(yù)處理。<和>符號適用于定義 HTML 標(biāo)簽的符號，我們可能能夠在這里輸入一些腳本代碼。

  • 5.嘗試輸入一個名稱，后面帶有非常簡單的腳本代碼。

1  Bob<script>alert('XSS')</script>

頁面會執(zhí)行腳本，并彈出提示框，表明這個頁面上存在跨站腳本漏洞。

  • 6.現(xiàn)在檢查源碼來觀察輸入中發(fā)生了什么。

    我們的輸入看起來作為 HTML 的一部分來處理。瀏覽器解釋了<script>標(biāo)簽并執(zhí)行了其中的代碼，彈出了我們設(shè)置的提示框。

工作原理

跨站腳本漏洞在服務(wù)端和客戶端中沒有輸入校驗，并且輸出沒有合理編碼時發(fā)生。這意味著應(yīng)用允許我們輸入用于 HTML 代碼中的字符。一旦它被決定發(fā)送到頁面中，并沒有執(zhí)行任何編碼措施（例如使用 HTML 轉(zhuǎn)義代碼&lt 和>）來防止他們被解釋為源代碼。

這些漏洞可被攻擊者利用來改變客戶端的頁面行為，并欺騙用戶來執(zhí)行它們不知道的操作，或偷取隱私信息。

為了發(fā)現(xiàn) XSS 漏洞，我們需要遵循以下原則：

  • 我們在輸入框中輸入的，準(zhǔn)確來說是被發(fā)送的文本，用于形成在頁面中展示的信息，這是反射型漏洞。

  • 特殊的字符沒有編碼或轉(zhuǎn)義。

  • 源代碼表明，我們的輸入被集成到某個位置，其中它變成了 HTML 代碼的一部分，并且會被瀏覽器解釋。

更多

這個秘籍中，我們發(fā)現(xiàn)了反射型 XSS，也就是說這個腳本在每次我們發(fā)送請求時，并且服務(wù)器響應(yīng)我們的惡意請求時都會執(zhí)行。有另外一種 XSS 類型叫做“存儲型”。存儲型 XSS 可能會在輸入提交之后立即展示，也可能不會。但是這種輸入會儲存在服務(wù)器（也可能是數(shù)據(jù)庫）中，它會在用戶每次訪問儲存數(shù)據(jù)時執(zhí)行。

4.6 基于錯誤的 SQL 注入識別

注入在 OWASP top 10 列表中位列第一。這包含，我們會在這個秘籍中測試的漏洞：SQL 注入（SQLI），以及其它。

多數(shù)現(xiàn)代 Web 應(yīng)用實現(xiàn)了某種類型的數(shù)據(jù)庫，要么本地要么遠(yuǎn)程。SQL 是最流行的語言，在 SQLI 攻擊中，攻擊者向表單輸入或請求中的其它參數(shù)注入 SQL 命令，使應(yīng)用發(fā)送修改后的請求，來試圖不正當(dāng)使用應(yīng)用和數(shù)據(jù)庫通信。其中請求用于構(gòu)建服務(wù)器中的 SQL 語句。

這個秘籍中，我們會測試 Web 應(yīng)用的輸入，來觀察是否含有 SQL注入漏洞。

操作步驟

登錄 DWVA 并執(zhí)行下列步驟：

  • 1.訪問SQL Injection。

  • 2.類似于上一章，我們通過輸入數(shù)字來測試應(yīng)用的正常行為。將User ID設(shè)置為1，并點擊Submit。

我們可以通過解釋結(jié)果來得出，應(yīng)用首先查詢數(shù)據(jù)庫，是否有 ID 等于 1 的用戶，之后返回結(jié)果。

下面，我們必須測試，如果我們發(fā)送一些應(yīng)用的非預(yù)期結(jié)果，會發(fā)生什么。在輸入框中輸入1'并提交該 ID。


這個錯誤信息告訴我們，我們修改了生成好的查詢。這并不意味著這里確實有 SQL 注入，但是我們可以更進(jìn)一步。

  • 4.返回 DWVA/SQL 注入頁面。

  • 5.為了驗證是否有基于錯誤的 SQL 輸入，我們嘗試另一個輸入：1''（兩個單引號）。


    現(xiàn)在，我們要執(zhí)行基本的 SQL 注入攻擊，在輸入框中輸入' or '1'='1
    并提交。

    看起來我們獲取了所有數(shù)據(jù)庫中的注冊用戶。

工作原理

SQL 注入發(fā)生在輸入在用于組成數(shù)據(jù)庫查詢之前沒有校驗的時候。讓我們假設(shè)服務(wù)端的代碼（PHP）拼裝了一個請求，例如：

1  $query = "SELECT * FROM users WHERE id='".$_GET['id']. "'";

這意味著，id參數(shù)中發(fā)送的數(shù)據(jù)會被集成進(jìn)來，因為它在查詢里面。將參數(shù)的引用替換為它的值，我們能得到：

1  $query = "SELECT * FROM users WHERE id='"."1". "'";

所以，當(dāng)我們發(fā)送惡意輸入，就像之前那樣，代碼行會由 PHP 解釋器讀取，就像：

1  $query = "SELECT * FROM users WHERE id='"."' or '1'='1"."'";

拼接為：

1  $query = "SELECT * FROM users WHERE id='' or '1'='1'";

這意味著“選擇users表中的任何條目，只要用戶id等于空或者 1 等于 1”。然而 1 永遠(yuǎn)等于 1，這就意味著所有用戶都復(fù)合條件。我們發(fā)送的第一個引號閉合了原始代碼中的做引號，之后我們輸入了一些 SQL 代碼，不帶有閉合的單引號，而是使用已經(jīng)在服務(wù)端代碼中該設(shè)置好的單引號。

更多

SQL 攻擊比起顯式應(yīng)用的用戶名，可能導(dǎo)致更嚴(yán)重的破壞。通過利用這些漏洞，攻擊者可能會通過執(zhí)行命令和提權(quán)來控制整個服務(wù)器。它也能夠提取數(shù)據(jù)庫中的所有信息，包括系統(tǒng)用戶名稱和密碼。取決于服務(wù)器和內(nèi)部網(wǎng)絡(luò)的配置，SQL 注入漏洞可能是整個網(wǎng)絡(luò)和內(nèi)部設(shè)施入侵的入口。

4.7 識別 SQL 盲注

我們已經(jīng)看到了 SQL 注入漏洞如何工作。這個秘籍中，我們會涉及到相同類型漏洞的不同變體，它不顯式任何能夠引導(dǎo)我們利用的錯誤信息或提示。我們會學(xué)習(xí)如何識別 SQL 盲注。

操作步驟

  • 1.登錄 DVWA 并訪問SQL Injection (Blind)。

  • 2.它看起來像是我們上一章了解的 SQL 注入。在輸入框中輸入1并點擊Submit。

  • 3.現(xiàn)在我們首次測試1'。


    我們沒有得到任何錯誤信息，但是也沒有結(jié)果，這里可能會發(fā)生一些有趣的事情。

  • 4.我們第二次測試1'。


    ID=1的結(jié)果顯示了，這意味著上一個結(jié)果1'產(chǎn)生了錯誤，并被應(yīng)用捕獲和處理掉了。很可能這里有個 SQL 注入漏洞，但是它是盲注，沒有顯示關(guān)于數(shù)據(jù)庫的信息，所以我們需要猜測。

  • 5.讓我們嘗試識別，當(dāng)用戶注入永遠(yuǎn)為假的代碼會發(fā)生什么。將1' and '1'='2設(shè)置為用戶的 ID。
    '1'永遠(yuǎn)不會等于'2'，所以沒有任何記錄符合查詢中的條件，并且沒有人惡化結(jié)果。

  • 6.現(xiàn)在，嘗試當(dāng) ID 存在時永遠(yuǎn)為真的請求：1' and '1'='1。


    這演示了頁面上的盲注。如果我們的永遠(yuǎn)為假的 SQL 注入得到了不同的響應(yīng)，并且永遠(yuǎn)為真的結(jié)果得到了另一個響應(yīng)，這里就存在漏洞，因為服務(wù)器會執(zhí)行代碼，即使它不顯示在響應(yīng)中。

工作原理

基于錯誤的 SQL 輸入和盲注都存在于服務(wù)端，也就是漏洞的那一段。應(yīng)用在使用輸入生成數(shù)據(jù)庫查詢之前并不過濾輸入。二者的不同存在于檢測和利用上。

在基于錯誤的 SQL 注入中，我們使用由服務(wù)器發(fā)送的錯誤來識別查詢類型，表和列的名稱。

另一方面，當(dāng)我們視圖利用盲注時，我們需要通過問問題來得到信息。例如，"' and name like 'a%"的意思是，“是否存在以'a'開頭的用戶？”如果我們得到了負(fù)面響應(yīng)，我們會詢問是否有以'b'開頭的名稱。在得到正面結(jié)果之后，我們會就會移動到第二個字符："' and name like 'ba%"。所以我們會花費很多時間來檢測和利用。

另見

下面的信息可能有助于更好的了解 SQL 盲注：

4.8 識別 Cookie 中的漏洞

Cookie 是從網(wǎng)站發(fā)送的小型數(shù)據(jù)片段，它儲存于用戶的瀏覽器中。它們包含有關(guān)于這種瀏覽器或一些特定 Web 應(yīng)用用戶的信息。在現(xiàn)代 Web 應(yīng)用匯總，Cookie 用于跟蹤用戶的會話。通過在服務(wù)端和客戶端保存 Session ID，服務(wù)器能夠同時識別由不同客戶端產(chǎn)生的不同請求。當(dāng)任何請求發(fā)送到服務(wù)器的時候，瀏覽器添加 Cookie并之后發(fā)送請求，服務(wù)器可以基于這個 COokie 來識別會話。

這個秘籍中，我們會學(xué)到如何識別一些漏洞，它們允許攻擊者劫持有效用戶的會話。

操作步驟

  • 1.訪問 http://192.168.56.102/mutillidae/。

  • 2.打開 Cookie Manager+ 并且刪除所有 Cookie。這可以防止與之前的 Cookie 產(chǎn)生混亂。

  • 3.現(xiàn)在，在 Mutillidae II中，訪問OWASP Top 10 | A3 – Broken Authentication and Session Management | Cookies。

  • 4.在Cookies Manager+中，我們會看到出現(xiàn)了兩個新的 Cookie。PHPSESSID和showhints。選項前者并點擊Edit來查看所有參數(shù)。


    PHPSESSID是基于 PHP 的 Web 應(yīng)用的會話默認(rèn)名稱。通過查看 Cookie 中參數(shù)值，我們可以看到它可以經(jīng)過安全和不安全的頻道（HTTP 和 HTTPS）發(fā)送。同樣，它可以被服務(wù)器讀取，以及被客戶端用過腳本代碼讀取，因為它并沒有開啟 HTTPOnly 標(biāo)識。這就是說，這個應(yīng)用的會話可以被劫持。

工作原理

這個秘籍中，我們檢查了 Cookie 的某些之，雖然并不像上一個那么明顯。在每次滲透測試中檢查 Cookie 的配置非常重要，不正確的會話 Cookie 設(shè)置會打開會話劫持攻擊的大門，以及錯誤使用受信任的用戶賬戶。

如果 Cookie 沒開啟HTTPOnly標(biāo)識，他就可以被腳本讀取。因此，如果存在跨站腳本攻擊漏洞，攻擊者就能夠得到有效會話的 ID，并且使用它來模擬應(yīng)用中的真實用戶。

Cookies Manager+ 中的安全屬性，或者Send For Encrypted Connections Only選項告訴瀏覽器只通過加密的頻道發(fā)送或接受該 Cookie（也就是說，只通過 HTTPS）。如果這個標(biāo)志沒有設(shè)置，攻擊者可以執(zhí)行中間人攻擊（MITM），并且通過 HTTP 來得到會話 Cookie，這會使它顯示為純文本，因為 HTTP 是個純文本的協(xié)議。這就再次產(chǎn)生了攻擊者能夠通過持有會話 ID 來模擬有效用戶的場景。

更多

就像PHPSESSID是 PHP 會話 Cookie 的默認(rèn)名稱那樣，其它平臺也擁有名稱，例如：

  • ASP.NET_SessionId是 ASP.NET 會話 Cookie 的名稱。

  • -JSESSIONID`是 JSP 實現(xiàn)的會話 Cookie。

OWASP 有一篇非常透徹的文章，關(guān)于保護(hù)會話 ID 和會話 Cookie。
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

4.9 使用 SSLScan 獲取 SSL 和 TLS 信息

我們在某種程度上，假設(shè)當(dāng)一個連接使用帶有 SSL 或 TLS 加密的 HTTPS 時，它是安全的，而且任何試圖攔截它的攻擊者都只會得到一些無意義的數(shù)字。但是，這并不絕對正確：HTTPS 服務(wù)器需要正確配置來提供有效的加密層，并保護(hù)用戶不受 MITM 攻擊或密碼分析。一些 SSL 協(xié)議的實現(xiàn)和設(shè)計上的漏洞已經(jīng)被發(fā)現(xiàn)了，所以，我們在任何 Web 應(yīng)用滲透測試中都要測試安全連接的強(qiáng)制性。

這個秘籍中，我們會使用 SSLScan，它是 Kali Linux 所包含的工具，基于服務(wù)器的安全通信來分析服務(wù)器的配置文件（從客戶端的角度）。

操作步驟

OWASP BWA 虛擬機(jī)已經(jīng)配置好了 HTTPS 服務(wù)器，為了確保它正常工作，訪問 https://192.168.56.102/，如果頁面沒有正常加載，你可能需要在繼續(xù)之前檢查你的配置文件。

  • 1.SSLScan 是個命令行工具（內(nèi)建于 Kali），所以我們需要打開終端。

  • 2.基本的sslscan命令會提供給我們服務(wù)器的足夠信息。

1  sslscan 192.168.56.102

輸出的第一部分告訴我們服務(wù)器的配置，包含常見的安全錯誤配置：重協(xié)商、壓縮和 Heartbleed，它是最近在一些 TLS 實現(xiàn)中發(fā)現(xiàn)的漏洞。這里，一切看起來都很好。


在第二部分中，SSLScan 會展示服務(wù)器接受的加密方式。正如我們看到的那樣，它支持 SSLv3 和一些例如 DES 的方式，它現(xiàn)在是不安全的。它們以紅色文字展示，黃色文字代表中等強(qiáng)度的加密。

最后，我們看到了首選的加密方式，如果客戶端支持它，服務(wù)器會嘗試用于通信。最終，服務(wù)器會使用有關(guān)證書的信息。我們可以看到，它將中等強(qiáng)度的算法用于簽名，并使用 RSA 弱密鑰。密鑰是弱的，因為他只有 1024 位的長度，安全標(biāo)準(zhǔn)推薦至少 2048 位。

工作原理

SSLScan 通過創(chuàng)建多個到 HTTPS 的鏈接來工作，并嘗試不同的加密方式和客戶端配置來測試它接受什么。

當(dāng)瀏覽器鏈接到使用 HTTPS 的服務(wù)器時，它們交換有關(guān)瀏覽器可以使用什么以及服務(wù)器支持什么的信息。之后它們在使用高度復(fù)雜的算法上達(dá)成一致。如果配置不當(dāng)?shù)?HTTPS 服務(wù)器上出現(xiàn)了 MITM 攻擊，攻擊者就可以通過聲稱客戶端值支持弱加密算法來欺騙服務(wù)器，假如是 SSLv2 上的 56 位 DES。之后攻擊者會攔截使用該算法加密的通信，通信可能會在幾天或幾小時之內(nèi)使用現(xiàn)代計算機(jī)破解。

更多

就像我們之前提到的那樣，SSLScan 能夠檢測 Heartbleed，這是一個最近在 OpenSSL 實現(xiàn)中發(fā)現(xiàn)的有趣漏洞。

Heartbleed 在 2014 年四月被發(fā)現(xiàn)。它由一個緩沖區(qū)導(dǎo)致，多于允許的數(shù)據(jù)可以從內(nèi)存中讀出，這是 OpenSSL TLS 中的情況。

實際上，Heartbleed 可以在任何未裝補(bǔ)丁的支持 TLS 的 OpenSSL （1.0.1 到 1.0.1f 之間）服務(wù)器上利用。它從服務(wù)器內(nèi)存中讀取 64 KB 的純文本數(shù)據(jù)，這能夠重復(fù)執(zhí)行，服務(wù)器上不會留下任何蹤跡或日志。這意味著攻擊者可以從服務(wù)器讀取純文本信息，包括服務(wù)器的的私鑰或者加密正是，會話 Cookie 或 HTTPS 請求會包含用戶的密碼或其它敏感信息。更多 Heartbleed 的信息請見維基百科。

另見

SSLScan 并不是唯一從 SSL/TLS 獲取加密信息的攻擊。Kali 中也有另一個工具叫做 SSLyze 可以用作替代，并且有時候會提供額外信息給攻擊者。

1  sslyze --regular www.example.com

SSL/TLS 信息也可以通過 OpenSSL 命令獲得：

1  openssl s_client -connect www2.example.com:443

4.10 查找文件包含

文件包含漏洞出現(xiàn)在開發(fā)者使用請求參數(shù)的時候，在服務(wù)端的代碼中，參數(shù)可以被用戶修改來動態(tài)選擇加載或包含哪個頁面。如果服務(wù)器執(zhí)行了所包含的文件，這種漏洞可能導(dǎo)致整個系統(tǒng)的淪陷。

這個秘籍中，我們會測試 Web 應(yīng)用來發(fā)現(xiàn)是否含有文件包含漏洞。

操作步驟

  • 1.登錄 DVWA 并訪問File Inclusion。

  • 2.我們需要編輯 GET 參數(shù)來測試包含。讓我們嘗試index.php。


    看起來目錄中沒有index.php文件（或者它為空），也可能這意味著本地文件包含（LFI）可能出現(xiàn)。

  • 3.為了嘗試 LFI，我們需要了解本地真正存在的文件名稱。我們知道了 DVWA 根目錄下存在index.php，所以我們對文件包含嘗試目錄遍歷，將頁面遍歷設(shè)置為../../index.php。


    這樣我們就演示了 LFI 可能出現(xiàn)，并且路徑遍歷也可能出現(xiàn)（使用../../，我們就遍歷了目錄樹）。

  • 4.下一步是嘗試遠(yuǎn)程文件包含，包括儲存在另一個服務(wù)器的我呢間，而不是本地文件，由于我們的測試虛擬機(jī)并沒有連接互聯(lián)網(wǎng)（或者它不應(yīng)該聯(lián)網(wǎng)，出于安全因素）。我們嘗試帶有完整 URL 的本地文件，就像它來自另一個服務(wù)器那樣。我們也會嘗試包含 Vicnum 的主頁?page=http://192.168.56.102/vicnum/index.html，通過提供頁面的 URL 作為參數(shù)，就像下面這樣：


    我們能夠通過提供完整 URL 使應(yīng)用加載頁面，這意味著我們可以包含遠(yuǎn)程文件，因此，存在遠(yuǎn)程文件包含（RFI）。如果被包含文件含有服務(wù)端可執(zhí)行代碼（例如 PHP），這種代碼會被服務(wù)端執(zhí)行。因此，攻擊者可以執(zhí)行遠(yuǎn)程命令，這樣的話，整個系統(tǒng)很可能淪陷。

工作原理

如果我們使用 DVWA 的View Source按鈕，我們可以看到服務(wù)端代碼是：

1  <?php
2  $file = $_GET['page']; //The page we wish to display 
3  ?>

這意味著page變量的值直接傳給了文件名稱，之后它被包含在代碼中。這樣，我們可以在服務(wù)端包含和執(zhí)行任何我們想要的 PHP 或 HTML 文件，只要它可以通過互聯(lián)網(wǎng)訪問。存在 RFI 漏洞的情況下，服務(wù)器一定會在配置文件中打開allow_url_fopen和allow_url_include。否則它只能含有本地文件包含，如果文件包含漏洞存在的話。

更多

我們也可以使用本地文件包含來顯示主機(jī)操作系統(tǒng)的相關(guān)文件。例如，試著包含../../../../../../etc/passwd，之后你就會得到系統(tǒng)用戶和它們的主目錄，以及默認(rèn) shell 的列表。

4.11 識別 POODLE 漏洞

就像上一章提到的那樣，使用 SSLScan 獲得 HTTPS 參數(shù)在一些條件下是可能的，尤其是中間人攻擊者降級用于加密通信的安全協(xié)議和加密算法的時候。

POODLE 攻擊使用這種條件來將 TLS 通信降級為 SSLv3 并強(qiáng)制使用易于被攻破的加密算法（CBC）。

這個秘籍中，我們會使用 Nmap 腳本來檢測這種漏洞在測試服務(wù)器上是否存在。

準(zhǔn)備

我們需要安裝 Nmap 并下載特定為檢測此漏洞而編寫的腳本。

  • 1.訪問http://nmap.org/nsedoc/scripts/ssl-poodle.html。

  • 2.下載ssl-poodle.nse文件。

  • 3.假設(shè)它下載到了你的 Kali 中的/root/Downloads中。下載打開終端并將它復(fù)制到 Nmap 的腳本目錄中：

1  cp /root/Downloads/ssl-poodle.nse /usr/share/nmap/scripts/

操作步驟

一旦你安裝了腳本，執(zhí)行下列步驟：

  • 1.打開終端并運行：
nmap --script ssl-poodle -sV -p 443 192.168.56.102


我們告訴了 Nmap 要掃描192.168.56.102（我們的 vulnerable_vm）的 443 端口，識別服務(wù)版本并在它上面執(zhí)行 ssl-poodle 腳本。一次你，我們可以斷定，服務(wù)器有漏洞，因為它允許 使用TLS_RSA_WITH_ AES_128_CBC_SHA
加密算法的 SSLv3 。

工作原理

我們下載的 Nmap 腳本和測試服務(wù)器建立了安全通信，并判斷他是否支持 SSLv3 上的 CBC 加密算法。如果支持，它就存在漏洞。漏洞會導(dǎo)致任何攔截的信息都能被攻擊者在很短的時間內(nèi)解密。

另見

為了更好理解這個攻擊，你可以查看一些這個加密實現(xiàn)最基本的解釋。

版權(quán)聲明：本文轉(zhuǎn)載自wizardforcel的專欄，如有侵權(quán)，請與本人聯(lián)系。
專欄鏈接：http://blog.csdn.net/wizardforcel

原文鏈接：http://blog.csdn.net/wizardforcel/article/details/52774750

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容