安全測試速查指南

---

---

安全測試 - 概述

安全測試對於保護系統免受網路惡意活動至關重要。

什麼是安全測試？

安全測試是一種測試技術，用於確定資訊系統是否按預期保護資料並保持功能。安全測試不能保證系統的完全安全，但將安全測試作為測試過程的一部分非常重要。

安全測試採取以下六項措施來提供安全的環境：

• 機密性 - 它防止資訊洩露給意外接收者。

• 完整性 - 它允許將準確和正確的所需資訊從傳送者傳輸到預期的接收者。

• 身份驗證 - 它驗證並確認使用者的身份。

• 授權 - 它指定使用者和資源的訪問許可權。

• 可用性 - 它確保資訊按需隨時可用。

• 不可否認性 - 它確保傳送者或接收者都不能否認已傳送或接收訊息。

示例

發現基於Web應用程式的安全漏洞涉及複雜的步驟和創造性思維。有時，簡單的測試可以暴露最嚴重的安全風險。您可以嘗試對任何Web應用程式進行此非常基本的測試：

• 使用有效的憑據登入Web應用程式。

• 登出Web應用程式。

• 單擊瀏覽器的“後退”按鈕。

• 驗證是否要求您再次登入，或者您是否能夠再次返回登入頁面。

安全測試 - 流程

安全測試可以被視為對系統的受控攻擊，它以現實的方式揭示安全漏洞。其目標是評估IT系統的當前狀態。它也稱為滲透測試或更流行的道德駭客。

滲透測試分階段進行，本章將討論整個過程。每個階段都應進行適當的記錄，以便隨時可以使用複製攻擊所需的所有步驟。該文件也作為客戶在滲透測試結束時收到的詳細報告的基礎。

滲透測試 - 工作流程

滲透測試包括四個主要階段：

• 足跡偵察
• 掃描
• 列舉
• 利用

這四個步驟會多次重複，這與正常的SDLC（軟體開發生命週期）相輔相成。

安全測試 - 惡意軟體

惡意軟體（malware）是任何賦予攻擊者/惡意軟體建立者對系統部分或全部控制權的軟體。

惡意軟體

以下是各種形式的惡意軟體：

• 病毒 - 病毒是一種程式，它會建立自身的副本並將這些副本插入其他計算機程式、資料檔案或硬碟的引導扇區中。成功複製後，病毒會在受感染的主機上造成有害活動，例如竊取硬碟空間或CPU時間。

• 蠕蟲 - 蠕蟲是一種惡意軟體，它會在其路徑中每臺計算機的記憶體中留下自身的副本。

• 木馬 - 木馬是一種非自我複製的惡意軟體，它包含惡意程式碼，執行該程式碼會導致資料丟失或被盜，或可能對系統造成損害。

• 廣告軟體 - 廣告軟體，也稱為免費軟體或pitchware，是一種包含遊戲、桌面工具欄和實用程式商業廣告的免費計算機軟體。它是一個基於Web的應用程式，它收集Web瀏覽器資料以定位廣告，尤其是彈出式廣告。

• 間諜軟體 - 間諜軟體是匿名監控使用者的滲透軟體，它使駭客能夠從使用者的計算機中獲取敏感資訊。間諜軟體利用使用者和應用程式漏洞，這些漏洞通常附加在免費的線上軟體下載或使用者點選的連結中。

• Rootkit（Root工具包） - Rootkit是駭客用來獲取對計算機/網路的管理員級別訪問許可權的軟體，它透過竊取密碼或利用系統漏洞在受害者不知情的情況下安裝。

預防措施

可以採取以下措施來避免系統中出現惡意軟體：

• 確保作業系統和應用程式已安裝最新的補丁/更新。

• 切勿開啟陌生的電子郵件，尤其是有附件的電子郵件。

• 從網際網路下載時，請務必檢查您安裝的內容。不要僅僅單擊“確定”來關閉彈出視窗。安裝應用程式之前，請驗證釋出者。

• 安裝防病毒軟體。

• 確保定期掃描和更新防病毒程式。

• 安裝防火牆。

• 始終啟用和使用瀏覽器和應用程式提供的安全功能。

反惡意軟體軟體

以下軟體有助於從系統中刪除惡意軟體：

• Microsoft Security Essentials
• Microsoft Windows Defender
• AVG Internet Security
• Spybot - Search & Destroy
• Avast! 個人版
• Panda Internet Security
• MacScan for Mac OS and Mac OS X

安全測試 - HTTP協議基礎

理解協議對於掌握安全測試至關重要。當我們攔截Web伺服器和客戶端之間的分組資料時，您將能夠理解協議的重要性。

HTTP協議

超文字傳輸協議 (HTTP) 是一種用於分散式、協作式超媒體資訊系統的應用程式級協議。自1990年以來，它一直是全球資訊網資料通訊的基礎。HTTP是一種通用且無狀態的協議，也可以透過擴充套件其請求方法、錯誤程式碼和標頭用於其他目的。

基本上，HTTP是一種基於TCP/IP的通訊協議，用於透過網路傳遞資料，例如HTML檔案、影像檔案、查詢結果等。它為計算機之間提供了一種標準化的通訊方式。HTTP規範指定了客戶端請求的資料如何傳送到伺服器，以及伺服器如何響應這些請求。

基本特性

以下三個基本特性使HTTP成為一個簡單而強大的協議：

• HTTP是無連線的 - HTTP客戶端（即瀏覽器）啟動HTTP請求。發出請求後，客戶端與伺服器斷開連線並等待響應。伺服器處理請求並重新與客戶端建立連線以傳送響應。

• HTTP是媒體無關的 - 只要客戶端和伺服器都知道如何處理資料內容，任何型別的資料都可以透過HTTP傳送。這要求客戶端和伺服器使用適當的MIME型別來指定內容型別。

• HTTP是無狀態的 - HTTP是無連線的，這是HTTP是無狀態協議的直接結果。伺服器和客戶端僅在當前請求期間知道彼此的存在。之後，它們都會忘記彼此。由於協議的這種性質，客戶端或瀏覽器都不能在Web頁面之間不同的請求之間保留資訊。

HTTP/1.0為每次請求/響應交換使用新的連線，而HTTP/1.1連線可用於一次或多次請求/響應交換。

架構

下圖顯示了Web應用程式的非常基本的架構，並描述了HTTP駐留的位置：

HTTP協議是基於客戶端/伺服器架構的請求/響應協議，其中Web瀏覽器、機器人和搜尋引擎等充當HTTP客戶端，而Web伺服器充當伺服器。

• 客戶端 - HTTP客戶端以請求方法、URI和協議版本的形式向伺服器傳送請求，然後透過TCP/IP連線傳送包含請求修改器、客戶端資訊和可能的正文內容的類似MIME的訊息。

• 伺服器 - HTTP伺服器以狀態行響應，包括訊息的協議版本和成功或錯誤程式碼，然後傳送包含伺服器資訊、實體元資訊和可能的實體正文內容的類似MIME的訊息。

HTTP - 缺點

• HTTP不是一個完全安全的協議。

• HTTP使用埠80作為預設通訊埠。

• HTTP在應用層執行。它需要為資料傳輸建立多個連線，這增加了管理開銷。

• 使用HTTP不需要加密/數字證書。

Http協議詳情

為了深入瞭解HTTP協議，請點選以下每個連結。

• HTTP引數

• HTTP訊息

• HTTP請求

• HTTP響應

• HTTP方法

• HTTP狀態碼

• HTTP報頭欄位

• HTTP安全

安全測試 - HTTPS協議基礎

HTTPS（安全套接字層上的超文字傳輸協議）或HTTP over SSL是由Netscape開發的一種Web協議。它不是一種協議，而只是將HTTP疊加在SSL/TLS（安全套接字層/傳輸層安全）之上的結果。

簡而言之，HTTPS = HTTP + SSL

何時需要HTTPS？

當我們瀏覽時，我們通常使用HTTP協議傳送和接收資訊。因此，這導致任何人都可以竊聽我們的計算機和Web伺服器之間的對話。很多時候，我們需要交換需要保密以防止未經授權訪問的敏感資訊。

Https協議用於以下場景：

• 銀行網站
• 支付閘道器
• 購物網站
• 所有登入頁面
• 電子郵件應用程式

HTTPS的基本工作原理

• HTTPS協議中的伺服器需要公鑰和簽名證書。

• 客戶端請求https://頁面

• 使用https連線時，伺服器透過提供Web伺服器支援的加密方法列表來響應初始連線。

• 作為響應，客戶端選擇連線方法，客戶端和伺服器交換證書以驗證其身份。

• 完成此操作後，Web伺服器和客戶端在確保兩者使用相同的金鑰後交換加密資訊，然後關閉連線。

• 要承載 https 連線，伺服器必須擁有一個公鑰證書，該證書嵌入了金鑰資訊以及對金鑰所有者身份的驗證。

• 幾乎所有證書都由第三方驗證，以確保客戶端金鑰始終安全。

安全測試 - 編碼和解碼

什麼是編碼和解碼？

編碼是將一系列字元（例如字母、數字和其他特殊字元）轉換為專用格式以進行高效傳輸的過程。

解碼是將編碼格式轉換回原始字元序列的過程。它與我們通常誤解的加密完全不同。

編碼和解碼用於資料通訊和儲存。編碼**不應**用於傳輸敏感資訊。

URL 編碼

URL 只能使用 ASCII 字元集透過網際網路傳送，並且在 URL 包含 ASCII 字元以外的特殊字元的情況下，需要對其進行編碼。URL 不包含空格，空格將被加號 (+) 或 %20 替換。

ASCII 編碼

瀏覽器（客戶端）將根據網頁中使用的字元集對輸入進行編碼，HTML5 中的預設字元集是 UTF-8。

下表顯示了字元的 ASCII 符號、等效符號以及最終可在傳遞給伺服器之前用於 URL 的替換字元：

安全測試 - 密碼學

什麼是密碼學？

密碼學是加密和解密資料的科學，它使使用者能夠儲存敏感資訊或將其跨不安全網路傳輸，以便只有預期的接收者才能讀取。

無需任何特殊措施即可讀取和理解的資料稱為明文，而為了隱藏其內容而偽裝明文的方法稱為加密。

加密的明文稱為密文，將加密資料轉換回明文的過程稱為解密。

• 分析和破解安全通訊的科學稱為密碼分析。執行此操作的人也稱為攻擊者。

• 密碼學可以是強烈的或弱的，其強度取決於恢復實際明文所需的時間和資源。

• 因此，需要合適的解碼工具來破譯強加密的訊息。

• 有一些密碼技術，即使是十億臺計算機每秒進行十億次檢查，也不可能破譯文字。

• 隨著計算能力日益增強，必須使加密演算法非常強大，以保護資料和關鍵資訊免受攻擊者的攻擊。

加密是如何工作的？

密碼演算法與金鑰（可以是單詞、數字或短語）結合使用來加密明文，相同的明文使用不同的金鑰加密為不同的密文。

因此，加密資料完全取決於幾個引數，例如密碼演算法的強度和金鑰的保密性。

密碼技術

對稱加密 - 常規密碼學，也稱為常規加密，是一種僅使用一個金鑰進行加密和解密的技術。例如，DES、三重 DES 演算法、IBM 的 MARS、RC2、RC4、RC5、RC6。

非對稱加密 - 它是公鑰密碼學，它使用一對金鑰進行加密：一個公鑰用於加密資料，一個私鑰用於解密。公鑰釋出給公眾，同時保持私鑰秘密。例如，RSA、數字簽名演算法 (DSA)、Elgamal。

雜湊 - 雜湊是一種單向加密，它建立無法反轉或至少不容易反轉的混淆輸出。例如，MD5 演算法。它用於建立數字證書、數字簽名、儲存密碼、驗證通訊等。

安全測試 - 同源策略

同源策略 (SOP) 是 Web 應用程式安全模型中的一個重要概念。

什麼是同源策略？

根據此策略，它允許在源自同一站點的頁面上執行的指令碼，該站點可以是以下各項的組合：

• 域
• 協議
• 埠

示例

此行為背後的原因是安全。如果您在一個視窗中擁有 try.com，而在另一個視窗中擁有 gmail.com，那麼您**不希望**來自 try.com 的指令碼訪問或修改 gmail.com 的內容，或代表您在 gmail 上下文中執行操作。

以下是來自同一源的網頁。如前所述，同一源會考慮域/協議/埠。

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

以下是來自不同源的網頁。

• http://www.site.co.uk（另一個域）
• http://site.org（另一個域）
• https://site.com（另一個協議）
• http://site.com:8080（另一個埠）

IE 的同源策略例外情況

Internet Explorer 對 SOP 有兩個主要例外情況。

• 第一個與“受信任區域”有關。如果兩個域都在高度受信任的區域中，則同源策略將完全不適用。

• IE 中的第二個例外與埠有關。IE 不將埠包含在同源策略中，因此 http://website.com 和 http://wesite.com:4444 被認為來自同一源，並且不應用任何限制。

安全測試 - Cookie

什麼是 Cookie？

Cookie 是 Web 伺服器傳送的一小段資訊，用於儲存在 Web 瀏覽器中，以便稍後瀏覽器可以讀取它。透過這種方式，瀏覽器會記住一些特定的個人資訊。如果駭客獲得了 Cookie 資訊，則可能導致安全問題。

Cookie 的屬性

以下是 Cookie 的一些重要屬性：

• 它們通常是小的文字檔案，帶有儲存在您計算機瀏覽器目錄中的 ID 標籤。

• 它們被 Web 開發人員用來幫助使用者高效地瀏覽其網站並執行某些功能。

• 當用戶再次瀏覽同一網站時，儲存在 Cookie 中的資料將被髮送回 Web 伺服器，以通知網站使用者之前的活動。

• 對於擁有龐大資料庫、需要登入、具有可自定義主題的網站來說，Cookie 是不可避免的。

Cookie 內容

Cookie 包含以下資訊：

• 傳送 Cookie 的伺服器的名稱。
• Cookie 的生命週期。
• 一個值 - 通常是一個隨機生成的唯一數字。

Cookie 的型別

• 會話 Cookie - 這些 Cookie 是臨時的，當用戶關閉瀏覽器時會被刪除。即使使用者再次登入，也會為該會話建立一個新的 Cookie。

• 永續性 Cookie - 除非使用者將其清除或它們過期，否則這些 Cookie 將保留在硬碟驅動器上。Cookie 的過期時間取決於它們可以持續多長時間。

Cookie 測試

以下是測試 Cookie 的方法：

• 停用 Cookie - 作為測試人員，我們需要在停用 Cookie 後驗證網站的訪問許可權，並檢查頁面是否正常工作。導航到網站的所有頁面並注意應用程式崩潰。還需要通知使用者需要 Cookie 才能使用該站點。

• 破壞 Cookie - 另一個要執行的測試是透過破壞 Cookie 來進行。為了做到這一點，必須找到站點 Cookie 的位置，並使用虛假/無效資料手動編輯它，這些資料可用於訪問域中的內部資訊，進而可用於入侵站點。

• 刪除 Cookie - 刪除網站的所有 Cookie，並檢查網站對此的反應。

• 跨瀏覽器相容性 - 還必須檢查 Cookie 是否已從寫入 Cookie 的任何頁面在所有受支援的瀏覽器上正確寫入。

• 編輯 Cookie - 如果應用程式使用 Cookie 來儲存登入資訊，那麼作為測試人員，我們應該嘗試將 Cookie 或位址列中的使用者更改為另一個有效使用者。編輯 Cookie 不應允許您登入到其他使用者的帳戶。

檢視和編輯 Cookie

現代瀏覽器支援在瀏覽器本身內檢視/編輯 Cookie 資訊。有一些適用於 Mozilla/Chrome 的外掛，我們可以使用這些外掛成功執行編輯。

• Firefox 的編輯 Cookie 外掛

• Chrome 的編輯此 Cookie 外掛

應執行以下步驟來編輯 Cookie：

• 從此處下載 Chrome 的外掛：此處

• 只需從 Chrome 中訪問“編輯此 Cookie”外掛即可編輯 Cookie 值，如下所示。

安全測試 - 駭客攻擊 Web 應用程式

我們可以使用各種方法/途徑作為執行攻擊的參考。

Web 應用 -滲透測試方法

在開發攻擊模型時，可以考慮以下標準。

在以下列表中，OWASP 最活躍，並且有許多貢獻者。我們將重點關注 OWASP 技術，每個開發團隊在設計 Web 應用之前都會考慮這些技術。

• PTES - 滲透測試執行標準

• OSSTMM - 開源安全測試方法手冊

• OWASP 測試技術 - 開放 Web 應用安全專案

OWASP Top 10

開放 Web 應用安全專案團隊釋出了近年來 Web 應用中更普遍存在的十大漏洞。以下是 Web 應用中更普遍存在的安全缺陷列表。

應用 - 實操

為了理解每種技術，讓我們使用一個示例應用程式。我們將對“WebGoat”進行攻擊，這是一個 J2EE 應用程式，它專門為學習目的而開發，其中包含安全漏洞。

關於 WebGoat 專案的完整詳細資訊，請訪問 https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project。要下載 WebGoat 應用程式，請訪問 https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) 並轉到下載部分。

要安裝下載的應用程式，首先確保您沒有在 8080 埠上執行任何應用程式。可以使用單個命令安裝它 - java -jar WebGoat-6.0.1-war-exec.jar。更多詳細資訊，請訪問 WebGoat 安裝

安裝後，我們應該可以透過導航到 https://:8080/WebGoat/attack 來訪問該應用程式，頁面將如下所示。

我們可以使用登入頁面中顯示的 guest 或 admin 憑據。

Web 代理

為了攔截客戶端（瀏覽器）和伺服器（在本例中託管 WebGoat 應用程式的系統）之間的流量，我們需要使用 Web 代理。我們將使用 Burp Proxy，可以從 https://portswigger.net/burp/download.html 下載。

下載 Burp Suite 的免費版本就足夠了，如下所示。

配置 Burp Suite

Burp Suite 是一款 Web 代理，可以攔截瀏覽器和 Web 伺服器傳送和接收的每個資訊包。這有助於我們在客戶端將資訊傳送到 Web 伺服器之前修改內容。

步驟 1 - 應用安裝在 8080 埠，Burp 安裝在 8181 埠，如下所示。啟動 Burp Suite 並進行以下設定，以便在 8181 埠啟動它，如下所示。

步驟 2 - 我們應該確保 Burp 正在監聽安裝應用程式的 8080 埠，以便 Burp Suite 可以攔截流量。此設定應在 Burp Suite 的作用域選項卡上完成，如下所示。

步驟 3 - 然後將您的瀏覽器代理設定設定為監聽 8181 埠（Burp Suite 埠）。因此，我們已配置 Web 代理以攔截客戶端（瀏覽器）和伺服器（Web 伺服器）之間的流量，如下所示 -

步驟 4 - 使用簡單的流程圖顯示配置的快照，如下所示

安全測試 - 注入攻擊

注入技術包括使用應用程式的輸入欄位注入 SQL 查詢或命令。

Web 應用 - 注入

成功的 SQL 注入可以讀取、修改資料庫中的敏感資料，也可以從資料庫中刪除資料。它還使駭客能夠執行資料庫上的管理操作，例如關閉 DBMS/刪除資料庫。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

應用程式在構建以下易受攻擊的 SQL 呼叫時使用了不受信任的資料 -

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

實操

步驟 1 - 導航到應用程式的 SQL 注入區域，如下所示。

步驟 2 - 如練習中所述，我們使用字串 SQL 注入繞過身份驗證。使用 SQL 注入以“Neville”（老闆）的身份登入，而無需使用正確的密碼。驗證是否可以檢視 Neville 的個人資料以及所有功能是否可用（包括搜尋、建立和刪除）。

步驟 3 - 我們將注入一個 SQL，以便我們能夠透過將引數傳送為 'a' = 'a' 或 1 = 1 來繞過密碼。

步驟 4 - 利用完成後，我們能夠以 Neville（管理員）的身份登入，如下所示。

防止 SQL 注入

有很多方法可以防止 SQL 注入。當開發人員編寫程式碼時，他們應該確保相應地處理特殊字元。OWASP 提供了備忘單/預防技術，這絕對是開發人員的指南。

• 使用引數化查詢
• 轉義所有使用者提供的輸入
• 為終端使用者啟用資料庫的最小許可權

測試身份驗證漏洞

當與應用程式相關的身份驗證功能未正確實現時，它允許駭客洩露密碼或會話 ID，或使用其他使用者的憑據利用其他實現缺陷。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

站點的已認證使用者將 URL 轉發給他們的朋友，讓他們瞭解折扣銷售資訊。他透過電子郵件傳送上述連結，卻不知道使用者也在洩露會話 ID。當他的朋友使用該連結時，他們會使用他的會話和信用卡。

實操

步驟 1 - 登入 WebGoat 並導航到“會話管理缺陷”部分。讓我們透過偽造 Cookie 來繞過身份驗證。以下是場景的快照。

步驟 2 - 當我們使用憑據 webgoat/webgoat 登入時，我們從 Burp Suite 中發現 JSESSION ID 為 C8F3177CCAFF380441ABF71090748F2E，而成功身份驗證後的 AuthCookie 為 65432ubphcfx。

步驟 3 - 當我們使用憑據 aspect/aspect 登入時，我們從 Burp Suite 中發現 JSESSION ID 為 C8F3177CCAFF380441ABF71090748F2E，而成功身份驗證後的 AuthCookie 為 65432udfqtb。

步驟 4 - 現在我們需要分析 AuthCookie 模式。前半部分“65432”對於兩種身份驗證都是通用的。因此，我們現在有興趣分析 authcookie 值的最後部分，例如 webgoat 使用者的 ubphcfx 和 aspect 使用者的 udfqtb。

步驟 5 - 如果我們仔細檢視 AuthCookie 值，最後一部分與使用者名稱長度相同。因此，很明顯使用者名稱使用了某種加密方法。透過反覆試驗/暴力破解機制，我們發現反轉使用者名稱 webgoat 後，我們得到 taogbew，然後使用之前的字母字元作為 AuthCookie，即 ubphcfx。

步驟 6 - 如果我們傳遞此 cookie 值，讓我們看看會發生什麼。在以 webgoat 使用者身份進行身份驗證後，透過執行步驟 4 和步驟 5 為使用者 Alice 查詢 AuthCookie 來更改 AuthCookie 值以模擬使用者 Alice。

預防機制

• 開發強大的身份驗證和會話管理控制，使其滿足 OWASP 應用程式安全驗證標準中定義的所有身份驗證和會話管理要求。

• 開發人員應確保避免可用於竊取會話 ID 的 XSS 漏洞。

測試跨站點指令碼

跨站點指令碼 (XSS) 發生在應用程式獲取不受信任的資料並將其傳送到客戶端（瀏覽器）而無需驗證時。這允許攻擊者在受害者的瀏覽器中執行惡意指令碼，這可能導致使用者會話被劫持、網站被篡改或使用者被重定向到惡意網站。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

XSS 型別

• 儲存型 XSS - 儲存型 XSS 也稱為持久型 XSS，發生在使用者輸入儲存在目標伺服器上（例如資料庫/訊息論壇/評論欄位等）時。然後，受害者能夠從 Web 應用程式檢索儲存的資料。

• 反射型 XSS - 反射型 XSS 也稱為非持久型 XSS，發生在使用者輸入立即由 Web 應用程式在錯誤訊息/搜尋結果中返回時，或者使用者提供的輸入作為請求的一部分，並且無需永久儲存使用者提供的資料。

• 基於 DOM 的 XSS - 基於 DOM 的 XSS 是一種 XSS 形式，當資料的來源在 DOM 中，接收器也在 DOM 中，並且資料流從未離開瀏覽器時。

示例

應用程式在構建時使用了未經驗證的資料。應該轉義特殊字元。

http://www.webpage.org/task/Rule1?query=try

攻擊者修改了瀏覽器中的查詢引數為 -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

實操

步驟 1 - 登入 WebGoat 並導航到跨站點指令碼 (XSS) 部分。讓我們執行儲存型跨站點指令碼 (XSS) 攻擊。以下是場景的快照。

步驟 2 - 根據場景，讓我們以 Tom 身份登入，密碼為“tom”，如場景本身所述。單擊“檢視個人資料”並進入編輯模式。由於 Tom 是攻擊者，讓我們將 JavaScript 注入這些編輯框。

<script> 
   alert("HACKED")
</script> 

步驟 3 - 更新完成後，Tom 收到一個帶有“hacked”訊息的警報框，這意味著該應用程式存在漏洞。

步驟 4 - 現在根據場景，我們需要以 Jerry（HR）身份登入並檢查 Jerry 是否受到注入指令碼的影響。

步驟 5 - 以 Jerry 身份登入後，選擇“Tom”並單擊“檢視個人資料”，如下所示。

從 Jerry 的帳戶檢視 Tom 的個人資料時，他能夠獲得相同的對話方塊。

步驟 6 - 此訊息框只是一個示例，但實際攻擊者可以執行比僅顯示訊息框更多的事情。

預防機制

• 開發人員必須確保根據資料放置到的 HTML 上下文（例如正文、屬性、JavaScript、CSS 或 URL）轉義所有不受信任的資料。

• 對於那些需要特殊字元作為輸入的應用程式，在接受它們作為有效輸入之前，應該有強大的驗證機制。

不安全的直接物件引用

當開發人員公開對內部實現物件的引用（例如檔案、目錄或資料庫金鑰）而沒有任何驗證機制時，可能會發生直接物件引用，這允許攻擊者操縱這些引用以訪問未授權的資料。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

該應用程式在訪問帳戶資訊時使用未經驗證的資料進行 SQL 呼叫。

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

攻擊者修改了瀏覽器中的查詢引數以指向 Admin。

http://webapp.com/app/accountInfo?acct=admin

實操

步驟 1 - 登入 WebGoat 並導航到訪問控制缺陷部分。目標是透過導航到其所在路徑來檢索 tomcat-users.xml。以下是場景的快照。

步驟 2 - 檔案的路徑顯示在“當前目錄是”欄位中 - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en，我們也知道 tomcat-users.xml 檔案儲存在 C:\xampp\tomcat\conf 下。

步驟 3 - 我們需要遍歷當前目錄的所有路徑並從 C:\ 驅動器導航。我們可以使用 Burp Suite 攔截流量來執行此操作。

步驟 4 - 如果嘗試成功，它將顯示 tomcat-users.xml 並顯示訊息“恭喜。您已成功完成本課程。”

預防機制

開發人員可以使用以下資源/要點作為指南，以在開發階段本身防止不安全的直接物件引用。

• 開發人員應該只使用一個使用者或會話進行間接物件引用。

• 從不受信任的來源使用直接物件引用之前，建議檢查訪問許可權。

安全錯誤配置

安全錯誤配置是指安全設定的定義、實現和維護使用預設值的情況。良好的安全措施要求為應用程式、Web伺服器、資料庫伺服器和平臺定義和部署安全的配置。軟體保持最新同樣重要。

示例

一些典型的安全錯誤配置示例如下：

• 如果伺服器上未停用目錄列表，並且攻擊者發現了這一點，則攻擊者可以簡單地列出目錄以查詢任何檔案並執行它。還可以獲取包含所有自定義程式碼的實際程式碼庫，然後查詢應用程式中的嚴重缺陷。

• 應用程式伺服器配置允許將堆疊跟蹤返回給使用者，這可能會暴露底層缺陷。攻擊者會抓住錯誤訊息提供的這些額外資訊，這些資訊足以讓他們滲透進去。

• 應用程式伺服器通常附帶安全性不足的示例應用程式。如果未從生產伺服器中刪除，則會導致伺服器受到攻擊。

實操

步驟 1 - 啟動 WebGoat 並導航到不安全的配置部分，讓我們嘗試解決該挑戰。下面提供了相同的快照：

步驟 2 - 我們可以嘗試我們能想到的儘可能多的選項。我們只需要找到配置檔案的 URL，並且我們知道開發人員遵循某種配置檔案命名約定。它可以是下面列出的任何內容。這通常透過暴力破解技術完成。

• web.config
• config
• appname.config
• conf

步驟 3 - 在嘗試各種選項後，我們發現“https://:8080/WebGoat/conf”成功了。如果嘗試成功，將顯示以下頁面：

預防機制

• 所有環境（例如開發、QA 和生產環境）都應使用每個環境中使用的不同密碼進行相同配置，這些密碼不易被破解。

• 確保採用強大的應用程式架構，該架構可在元件之間提供有效、安全的隔離。

• 還可以透過定期執行自動化掃描和進行審計來最大限度地減少這種攻擊的可能性。

安全測試 - 敏感資料洩露

隨著線上應用程式日益湧入網際網路，並非所有應用程式都是安全的。許多 Web 應用程式無法正確保護敏感使用者資料，例如信用卡資訊/銀行賬戶資訊/身份驗證憑據。駭客最終可能會竊取這些保護薄弱的資料來進行信用卡欺詐、身份盜竊或其他犯罪活動。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

一些典型的安全錯誤配置示例如下：

• 某個網站只是沒有為所有已驗證頁面使用 SSL。這使攻擊者能夠監控網路流量並竊取使用者的會話 Cookie 來劫持使用者會話或訪問其私人資料。

• 一個應用程式以加密格式將信用卡號碼儲存在資料庫中。檢索後，它們會被解密，允許駭客執行 SQL 注入攻擊以明文檢索所有敏感資訊。這可以透過使用公鑰加密信用卡號碼並允許後端應用程式使用私鑰對其進行解密來避免。

實操

步驟 1 - 啟動 WebGoat 並導航到“不安全的儲存”部分。下面顯示了相同的快照。

步驟 2 - 輸入使用者名稱和密碼。現在是學習我們之前討論過的不同型別的編碼和加密方法的時候了。

預防機制

• 建議不要不必要地儲存敏感資料，如果不再需要，應儘快將其清除。

• 務必確保我們結合使用強大且標準的加密演算法，併到位適當的金鑰管理。

• 還可以透過停用收集敏感資料（如密碼）的表單上的自動填充功能以及停用包含敏感資料的頁面的快取來避免這種情況。

缺少函式級訪問控制

大多數 Web 應用程式在使該功能對使用者可用之前都會驗證函式級訪問許可權。但是，如果未在伺服器上執行相同的訪問控制檢查，則駭客能夠在未經授權的情況下滲透到應用程式中。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

這是一個缺少函式級訪問控制的典型示例：

駭客只需強制目標 URL。通常，管理員訪問需要身份驗證，但是，如果未驗證應用程式訪問，則未經身份驗證的使用者可以訪問管理員頁面。

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

實操

步驟 1 - 讓我們首先檢視使用者及其訪問許可權列表，然後以帳戶管理員身份登入。

步驟 2 - 透過嘗試各種組合，我們可以發現 Larry 可以訪問資源帳戶管理員。

預防機制

• 身份驗證機制應預設拒絕所有訪問，併為每個功能提供對特定角色的訪問。

• 在基於工作流的應用程式中，在允許使用者訪問任何資源之前，請驗證使用者的狀態。

跨站點請求偽造 (CSRF)

CSRF 攻擊會強制經過身份驗證的使用者（受害者）傳送偽造的 HTTP 請求，包括受害者的會話 Cookie 到易受攻擊的 Web 應用程式，這允許攻擊者強制受害者的瀏覽器生成請求，以便易受攻擊的應用程式將其視為來自受害者的合法請求。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

這是一個 CSRF 的典型示例：

步驟 1 - 假設易受攻擊的應用程式以純文字形式傳送狀態更改請求，沒有任何加密。

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

步驟 2 - 現在，駭客構建一個請求，透過將請求嵌入儲存在攻擊者控制下的各種網站上的影像中，將資金從受害者的帳戶轉移到攻擊者的帳戶：

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

實操

步驟 1 - 讓我們透過將 JavaScript 嵌入影像來執行 CSRF 偽造。問題的快照列在下面。

步驟 2 - 現在我們需要將轉移模擬到一個 1x1 的影像中，並讓受害者點選它。

步驟 3 - 提交訊息後，訊息將顯示如下所示：

步驟 4 - 現在，如果受害者點選以下 URL，則會執行轉移，這可以透過使用 burp suite 攔截使用者操作來找到。我們可以透過在 Get 訊息中發現它來檢視轉移，如下所示：

步驟 5 - 現在點選重新整理，就會顯示課程完成標記。

預防機制

• 可以透過在隱藏欄位中建立一個唯一令牌來避免 CSRF，該令牌將傳送在 HTTP 請求的主體中，而不是在更容易暴露的 URL 中。

• 強制使用者重新進行身份驗證或證明他們是使用者以保護 CSRF。例如，CAPTCHA。

存在漏洞的元件

當應用程式中使用的元件（例如庫和框架）幾乎總是以完全許可權執行時，就會發生這種威脅。如果利用了易受攻擊的元件，則會使駭客更容易造成嚴重的資料丟失或伺服器接管。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

以下示例是使用具有已知漏洞的元件：

• 攻擊者可以透過未能提供身份令牌來以完全許可權呼叫任何 Web 服務。

• 透過基於 Java 的應用程式的 Spring Framework 引入了具有表示式語言注入漏洞的遠端程式碼執行。

預防機制

• 識別 Web 應用程式中使用的所有元件及其版本，而不僅僅限於資料庫/框架。

• 使所有元件（例如公共資料庫、專案郵件列表等）保持最新。

• 為本質上易受攻擊的元件新增安全包裝器。

未驗證的重定向和轉發

網際網路上的大多數 Web 應用程式經常將使用者重定向和轉發到其他頁面或其他外部網站。但是，如果沒有驗證這些頁面的可信度，駭客可以將受害者重定向到網路釣魚或惡意軟體網站，或者使用轉發來訪問未經授權的頁面。

讓我們藉助簡單的圖表瞭解此缺陷的威脅代理、攻擊載體、安全弱點、技術影響和業務影響。

示例

一些未經驗證的重定向和轉發的典型示例如下：

• 假設應用程式有一個頁面 - redirect.jsp，它接受引數 *redirectrul*。駭客新增一個惡意 URL，該 URL 會重定向執行網路釣魚/安裝惡意軟體的使用者。

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

• 所有 Web 應用程式都用於將使用者轉發到站點的不同部分。為了實現相同的目的，某些頁面使用引數來指示如果操作成功，則應將使用者重定向到的位置。攻擊者會建立一個 URL，該 URL 透過應用程式的訪問控制檢查，然後將攻擊者轉發到攻擊者無權訪問的管理功能。

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

預防機制

• 最好避免使用重定向和轉發。

• 如果不可避免，則應在不涉及使用者引數重定向目標的情況下進行。

AJAX 安全性

非同步 JavaScript 和 XML (AJAX) 是用於開發 Web 應用程式以提供豐富的使用者體驗的最新技術之一。由於它是一項新技術，因此還有許多安全問題尚未完全確定，以下是 AJAX 中的一些安全問題。

• 攻擊面更大，因為需要保護更多輸入。

• 它還公開了應用程式的內部功能。

• 未能保護身份驗證資訊和會話。

• 客戶端和伺服器端之間只有一條非常細的界限，因此有可能犯下安全錯誤。

示例

這是一個 AJAX 安全性的示例：

2006 年，蠕蟲病毒利用 XSS 和 AJAX 感染了雅虎郵件服務，利用了雅虎郵件的 onload 事件處理中的漏洞。當開啟受感染的電子郵件時，蠕蟲會執行其 JavaScript，將其副本傳送給受感染使用者的全部雅虎聯絡人。

實操

步驟 1 - 我們需要嘗試使用 XML 注入將更多獎勵新增到您允許的獎勵集中。以下是場景的快照。

步驟 2 - 確保我們使用 Burp Suite 攔截請求和響應。如下所示相同的設定。

步驟 3 - 輸入場景中給出的帳號。我們將能夠獲得我們有資格獲得的所有獎勵的列表。我們有資格獲得 5 個獎勵中的 3 個。

步驟 4 - 現在讓我們點選“提交”，看看我們在響應 XML 中得到了什麼。如下所示，我們有資格獲得的三個獎勵作為 XML 傳遞給我們。

步驟 5 - 現在讓我們編輯這些 XML 並新增另外兩個獎勵。

步驟 6 - 現在所有獎勵都將顯示給使用者供他們選擇。選擇我們新增的獎勵並點選“提交”。

步驟 7 - 將出現以下訊息：“*恭喜。您已成功完成本課程。*

預防機制

客戶端 -

• 使用 .innerText 代替 .innerHtml。
• 不要使用 eval。
• 不要依賴客戶端邏輯來保證安全。
• 避免編寫序列化程式碼。
• 避免動態構建 XML。
• 切勿將秘密傳輸到客戶端。
• 不要在客戶端程式碼中執行加密。
• 不要在客戶端執行影響安全性的邏輯。

伺服器端 -

• 使用 CSRF 保護。
• 避免編寫序列化程式碼。
• 使用者可以直接呼叫服務。
• 避免手工構建 XML，使用框架。
• 避免手工構建 JSON，使用現有的框架。

安全測試 - Web 服務

在現代基於 Web 的應用程式中，Web 服務的使用是不可避免的，它們也容易受到攻擊。由於 Web 服務請求來自多個網站，因此開發人員必須採取一些額外的措施以避免駭客的任何滲透。

實操

步驟 1 − 導航到 Webgoat 的 Web 服務區域，然後進入 WSDL 掃描。我們現在需要獲取其他帳戶的信用卡詳細資訊。場景快照如下所示。

步驟 2 − 如果我們選擇名字，則會透過 SOAP 請求 xml 呼叫 'getFirstName' 函式。

步驟 3 − 透過開啟 WSDL，我們可以看到也存在一個用於檢索信用卡資訊的方法 'getCreditCard'。現在讓我們使用 Burp Suite 篡改輸入，如下所示 −

步驟 4 − 現在讓我們使用 Burp Suite 修改輸入，如下所示 −

步驟 5 − 我們可以獲取其他使用者的信用卡資訊。

預防機制

• 由於 SOAP 訊息是基於 XML 的，因此所有傳遞的憑據都必須轉換為文字格式。因此，在傳遞必須始終加密的敏感資訊時，必須非常小心。

• 透過實現諸如應用於確保資料包完整性的校驗和之類的機制來保護訊息完整性。

• 保護訊息機密性 - 應用非對稱加密來保護對稱會話金鑰，在許多實現中，這些金鑰僅在一個通訊中有效，之後會被丟棄。

安全測試 - 緩衝區溢位

當程式嘗試將比其預期容納的更多資料儲存到臨時資料儲存區（緩衝區）中時，就會出現緩衝區溢位。由於緩衝區是為包含有限數量的資料而建立的，因此額外資訊可能會溢位到相鄰的緩衝區，從而破壞其中儲存的有效資料。

示例

這是一個經典的緩衝區溢位示例。它演示了一個簡單的緩衝區溢位，該溢位是由第一個場景引起的，該場景依賴於外部資料來控制其行為。無法限制使用者輸入的資料量，程式的行為取決於使用者輸入的字元數量。

   ...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

實操

步驟 1 − 我們需要使用姓名和房間號登入以獲取網際網路訪問許可權。以下是場景快照。

步驟 2 − 我們還將在 Burp Suite 中啟用“顯示隱藏表單欄位”，如下所示 −

步驟 3 − 現在，我們在姓名和房間號欄位中輸入內容。我們還嘗試在房間號欄位中注入一個很大的數字。

步驟 4 − 隱藏欄位如下所示。我們點選接受條款。

步驟 5 − 攻擊成功，由於緩衝區溢位，它開始讀取相鄰的記憶體位置並顯示給使用者，如下所示。

步驟 6 − 現在讓我們使用顯示的資料登入。登入後，將顯示以下訊息 −

預防機制

• 程式碼審查
• 開發人員培訓
• 編譯器工具
• 開發安全函式
• 定期掃描

安全測試 - 拒絕服務攻擊

拒絕服務 (DoS) 攻擊是駭客試圖使網路資源不可用的嘗試。它通常會暫時或無限期地中斷連線到網際網路的主機。這些攻擊通常針對託管在關鍵任務 Web 伺服器上的服務，例如銀行、信用卡支付閘道器。

DoS 的症狀

• 網路效能異常緩慢。
• 特定網站不可用。
• 無法訪問任何網站。
• 接收到的垃圾郵件數量急劇增加。
• 長期無法訪問 Web 或任何網際網路服務。
• 特定網站不可用。

實操

步驟 1 − 啟動 WebGoat 並導航到“拒絕服務”部分。場景快照如下所示。我們需要多次登入，從而突破最大資料庫執行緒池大小。

步驟 2 − 首先，我們需要獲取有效登入列表。在這種情況下，我們使用 SQL 注入。

步驟 3 − 如果嘗試成功，則會向用戶顯示所有有效憑據。

步驟 4 − 現在，在至少 3 個不同的會話中使用這些使用者中的每一個登入，以使 DoS 攻擊成功。眾所周知，資料庫連線只能處理兩個執行緒，透過使用所有登入名，它將建立三個執行緒，從而使攻擊成功。

預防機制

• 執行徹底的輸入驗證。

• 避免高度佔用 CPU 的操作。

• 最好將資料磁碟與系統磁碟分開。

安全測試 - 惡意檔案執行

開發人員經常直接使用或將可能存在漏洞的輸入與檔案連線，或者假設輸入檔案是真實的。如果資料未正確檢查，這可能導致 Web 伺服器處理或呼叫易受攻擊的內容。

示例

一些經典示例包括 −

• 將 .jsp 檔案上傳到 Web 樹。
• 上傳 .gif 以調整大小。
• 上傳大型檔案。
• 上傳包含標籤的檔案。
• 將 .exe 檔案上傳到 Web 樹。

實操

步驟 1 − 啟動 WebGoat 並導航到惡意檔案執行部分。場景快照如下所示 −

步驟 2 − 為了完成本課程，我們需要將 guest.txt 上傳到上述位置。

步驟 3 − 讓我們建立一個 jsp 檔案，以便在執行 jsp 時建立 guest.txt 檔案。jsp 的命名在此上下文中不起任何作用，因為我們正在執行 jsp 檔案的內容。

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

步驟 4 − 現在上傳 jsp 檔案並在上傳後複製其連結位置。上傳需要影像，但我們上傳的是 jsp。

步驟 5 − 導航到 jsp 檔案時，不會向用戶顯示任何訊息。

步驟 6 − 現在重新整理您上傳 jsp 檔案的會話，您將收到訊息“*恭喜。您已成功完成本課程”。

預防機制

• 使用網站許可權保護網站。
• 採取網路應用程式安全防禦措施。
• 瞭解 IIS 7.0 中的內建使用者和組帳戶。

安全測試 - 自動化工具

有各種工具可用於執行應用程式的安全測試。有些工具可以執行端到端安全測試，而有些工具則專門用於發現系統中特定型別的缺陷。

開源工具

一些開源安全測試工具如下所示 −

特定工具集

以下工具可以幫助我們發現系統中特定型別的漏洞 −

商業黑盒測試工具

以下是一些商業黑盒測試工具，它們可以幫助我們發現我們開發的應用程式中的安全問題。

免費原始碼分析器

商業原始碼分析器

這些分析器檢查、檢測並報告原始碼中的弱點，這些弱點容易受到漏洞的影響 −