如何寫好一篇漏洞報告（國外篇）

如何寫好一篇漏洞總結報告，這一直都是一些應用開發公司經常忽略的重要事情，一篇好的漏洞總結報告可以有效幫助開發人員，減少尋找和解決漏洞的時間。

接下來我就開始講述如何該寫好一篇漏洞總結報告，這樣你就可以在看完報告後短時間內解決漏洞問題，同時也可以避免在軟體項目過程中遭遇公關問題。那麼首先來對比一下錯誤和正確的漏洞總結報告。

一個錯誤的漏洞總結報告是什麼樣的？

在開始分析之後，先為大家介紹幾個漏洞基本概念，CVSS(Common Vulnerability Scoring System)即通用漏洞評分系統 是安全內容自動化協議(SCAP)的一部分，分值（0-100)，同時為行業公開標準,其被設計用來評測漏洞的嚴重程度 幫助確定所需反應的緊急度和重要度。CVSS同CVE一同由美國國家漏洞庫(NVD)發布並保持數據的更新，CVE(Common Vulnerabilities and Exposures)為漏洞和暴露確定了唯一的名稱以及一個標準化的描述，同時實現更好的協同工作。

下面我們就來一起分析下錯誤漏洞總結報告，我們就先來看看錯誤漏洞總結報告是什麼樣的。請試著想像這樣一件事情，我們搭建了一個有關球迷的社交網站，在一次網站程序升級檢測之後，質量保證專員在JIRA上填寫漏洞總結報告。下面這張圖片就是例子

第一眼看過去這篇報告似乎一切沒有問題，不是嗎？那麼到底還缺少什麼內容呢？下面我們就一起來分析一下

漏洞編號（ID）：

當你在JIRA網站上填寫漏洞總結報告時，網站會默認分配給你一個編號，這一塊沒有什麼問題。

漏洞摘要：

該信息往往位於編號信息下面，但這篇報告卻沒有一語中的，報告中雖然提及了漏洞影響的用戶類型，但沒有具體說明是哪一種類型的漏洞。如果一個Web開發者看到這樣一篇報告，就會提出很多的問題並要求對方來澄清這些疑問。

漏洞詳述：

很明顯測試人員沒有提供關於應用程序版本和測試環境的任何數據，我們在下面的文章將會詳細描述這一點，至於漏洞優先順序問題，測試人員通常會優先分配優先順序，以後可能會根據實際情況改變優先順序。對於目前國內提交漏洞優先順序，需要說明一下，如下：

1)高危安全問題：

1、直接獲取業務伺服器許可權的漏洞。包括但不限於任意命令執行、上傳獲取webshell、直接導致嚴重的信息泄漏漏洞。

2、包括但不限於核心DB的SQL注入漏洞（涉及用戶數據、訂單數據、交易數據），直接導致嚴重影響的邏輯漏洞。

3、包括但不限於任意帳號密碼更改漏洞。

4、越權訪問，僅限於重要業務線批量獲取訂單類信息的漏洞(敏感數據明文)、用戶數據信息（明文）、繞過驗證直接訪問後台、重要後台登錄弱口令。

2)中危安全問題：

1、需交互才能獲取用戶身份信息的漏洞。

2、包括但不限於任意文件讀、寫、刪除、下載等操作。

3、包括但不限於繞過限制修改用戶資料、執行用戶操作，較嚴重的信息泄漏漏洞

4、包括但不限於批量獲取用戶類、訂單類信息的漏洞。

5、非核心業務SQL注入，不涉及用戶數據、訂單數據、交易數據，按中風險處理

3)低危安全問題：

1、普通邏輯漏洞；普通信息泄露；需交互才能獲取用戶身份信息並且有一定利用難度的漏洞。

2、Discuz 漏洞問題均按低風險處理(discuz非qunar主要業務)

3、批量下訂單、發垃圾簡訊、加關注按低風險處理

4、越權訪問，包含敏感信息且打碼，按低風險處理

5、代理商弱口令及密碼等信息通過雲盤、筆記、QQ群備註等泄漏的按低風險處理

6、代理商及合作方後台地址外泄導致暴力破解，按低風險處理。

7、猜測或遍歷網站註冊用戶，按低風險處理

4)通常忽略的問題：

1、不涉及安全問題的bug，包括但不限於網站產品功能缺陷、頁面亂碼、樣式混編等。

2、不會直接帶來安全問影響，包括但不限於繞過WAF對業務無影響的，Self-XSS，非登錄相關的URL跳轉，非敏感操作的CSRF，非敏感信息的JSON Hijacking，無意義的源碼泄漏、程序出錯而暴露出來無安全影響的信息、內網IP/域名泄漏，以及需藉助中間人攻擊才能實現的問題。

3、無法重現的漏洞、不能直接體現漏洞的其他問題。包括但不限於純屬用戶推測的問題（需要案例）。

4、廠商內部自行發現的，廠商SRC已知的，第三方漏洞平台報告過的漏洞做忽略處理，且廠商提供相應截圖（其中：高危：4小時，中危：14天，低危：28天）。

5、第三方已披露的漏洞（基礎應用0day，開發框架0day等），距離公告期兩天以上且廠商已知曉的。

6、由於已經對關鍵位置實施HttpOnly限制，XSS漏洞暫不接收（後台盲打類xss除外）。

7、無線訂單鏈接越權查看（用戶等信息打碼，不能遍歷）的按低風險處理

漏洞描述：這塊是出現問題最多的地方，在這一部分，測試人員應該按照重新配置、實際結果和預期結果的步驟提供漏洞相關信息。漏洞總結報告就是應該提供有關漏洞的詳細信息，如果質量保證專員不能有效的再現漏洞問題，那麼看到這篇漏洞報告的軟體開發人員就需要多花時間在尋找漏洞問題上。

在看完上面截圖信息之後，Web開發人員將立即詢問負責編寫報告的人使用了哪些登錄憑證，如管理員信息、測試用戶信息以及版主信息（含BBS模板網站常見）。除此之外，還需要知道出現伺服器漏洞（本地環境）問題，簡單來說，這種情況一般出現在測試伺服器（https://testing-bugs.sprinklebit.com），或生產伺服器（https://sprinklebit.com）。還有一個概念大家需要了解，漏洞管理三要素，即準確性、時間以及資源。

測試人員應該提供預期結果，這些細節可以幫助開發人員（有些沒參與其軟體開發人員對於程序細節不清楚）快速解決這個問題，但我們在報告中沒有看到直觀的漏洞數據統計圖形，比如一些附加圖形圖像。

如何將一篇糟糕的漏洞總結報告改進？

請看下面這篇報告的截圖，這篇漏洞總結報告就比之前的那篇好些。

第二篇和第一篇有什麼不同？主要是第二篇的報告對於細節描述更加詳細具體，Web開發人員可以根據報告內容對程序進行修改。下面就來說明一下第二篇報告改進的地方，測試人員在報告中描述了重要細節，「聊天功能——創建臨時會話的群主不能重命名它」，當然這裡面還有其它一些有價值的信息，諸如受影響軟體版本號、運行環境以及修復版本信息。

測試人員提到了檢測出漏洞的應用程序版本，同時還指出當時測試環境，這樣就可以很清楚的了解網站當前運行環境版本。之前描述的步驟中重現是非常重要的，它

可以顯示必要的網站登錄數據、網站相關軟體版本以及按鈕說明。實際結果雖然出現在截圖中，但測試人員並沒有忘記提及預期結果。

在這裡強調的一點是，所有漏洞總結報告都應該按照統一規則編寫，漏洞總結報告在追蹤漏洞方面是非常實用的。

下面我就來介紹一下如何寫好一篇高質量的漏洞總結報告，以方便開發人員更高效的解決漏洞問題，最後當漏洞總結報告上的問題迅速解決的時候，你設計的應用程序將會從中獲益。

寫好一篇高質量漏洞總結報告的訣竅

漏洞總結報告主要是向開發人員澄清一個明確的問題，同時有助於開發人員開發整個項目。在質量保證團隊開始編寫漏洞報告的時候，他們應該了解以下問題的答案

什麼?-應用程序發生了什麼事情？

如何？-我們點擊/運行程序不發生錯誤？

在哪裡？-到底在應用程序哪個位置出現漏洞?網頁/伺服器?

下面就開始講解一種編寫漏洞總結報告的樣板，並拿一個網站舉個例子。

漏洞編號

測試人員可以在 Bugzilla、JIRA等平台編寫報告，如果你選擇在這些平台編寫報告，通常會得到一個編號。另外測試人員也可以手動編寫一個編號，這樣做比填寫完整標題的方案，很顯然前者可以節約開發人員開發時間。

在實際生活中，沒有人會手動編寫一個編號，如果你一定要選擇手動編寫，可以考慮利用應用程序名稱縮寫，SprinkleBit就可以用SB-WEB代替，SB-MOB則表示該應用移動端版本。另外，測試人員需要為漏洞加索引編號。

正確：sb-web-121或sb-mob-231（盡量將應用程序運行哪種環境表達出來）

錯誤：我的網站-#87123或簡單標記#112

開發人員有時需要同時處理多個項目，所以設置一個一目了然的漏洞編號，這樣可以清楚的表達是哪一個應用程序出現問題。

漏洞摘要

在JIRA網站平台編寫報告，需要填寫一個標題，這就需要了解報告摘要內容之後才能做這件事情，摘要可以說是漏洞總結報告最核心的部分。對於初學者，我建議使用簡訊息來填寫標題，漏洞摘要通常是以簡短的語言描述問題的關鍵，JIRA 中的項目進展分級為Epic（史詩）->Story（故事）->Task（任務），Epic 可以說佔用你在JIRA平台報告中大部分信息，如之前聊天或用戶個人資料部分分析，你需要提示測試人員不能帶有自身情緒以及主觀意見，同時以簡短的方式來描述發生了什麼事情。

正確表達方式：關於公司屏幕出現問題，屏幕頂部出現紅色條紋，還有屏幕中的彩色布局不協調問題。

錯誤表達方式：屏幕布局有問題/屏幕出現問題

漏洞詳細信息

我作為經驗豐富的質量保證專員，強烈建議您的測試人員應在報告中，詳細說明應用程序版本以及測試環境，通常情況下，應用程序應每兩到三周更新一次，例如，我們可能每兩周發布一個新版本的應用程序，同時修復老版本錯誤。

具體來說就是已經完成了2.21版本（假設新版本號），就沒有必要在2.01版本（假設舊版本號）創建一個相關漏洞信息的報告。但這裡需要注意的是，你需要讓你的測試人員詳細更新報告，並在報告中指出是哪個應用程序版本出現問題。

根據漏洞類型的不同，測試環境可分為網站版本，操作系統或Web瀏覽器。例如，你有兩個網站www.my-website.com和testing.my-website.com用來測試，但測試環境很顯然是不同的（測試伺服器和生產伺服器），所以導致最終的結果也會不同。因此，測試人員需要在漏洞總結報告中指出詳細網址信息。如果發現是運行環境問題，就需要記下瀏覽器名稱和版本。測試人員在報告中需詳細描述測試環境，同時可以為後來的網站開發人員節約時間，也可以幫助開發人員了解問題的關鍵所在。如果測試人員不在報告中添加這一項，那麼開發人員也會跳過這一個容易被忽略的地方。他們不負責檢測漏洞，並有可能導致任務失敗。

漏洞的嚴重性以及優先順序

這兩項可以單獨列出來，也可以合併為一個參數。而這取決於測試人員使用的漏洞分析平台，漏洞的嚴重性是針對漏洞對於應用程序的影響，從臨界範圍（漏洞關鍵功能）降低（錯誤很難重現）再到主要功能正常，一些不常用功能很可能出現問題。一般情況下，測試人員會使用這種模式。

漏洞優先順序反過來是概述漏洞修復層次結構的工具，項目經理通常設定優先權，漏洞優先順序按漏洞嚴重程度排列，並使得範圍逐漸縮小。簡單來說，如果一個漏洞關鍵問題起作用時，那麼該漏洞優先順序和嚴重程度都會被評為「高危」漏洞。當然漏洞關鍵問題並沒有那麼重要時，我們會指定漏洞的優先順序和嚴重程度，舉個例子，在被測試網站登錄頁面上的一級標題內容出現拼寫錯誤。像這種漏洞危害級別程度很低，而且不影響程序正常功能。網站用戶仍然可以登錄網站，但我們也不應該忽視這樣的漏洞，登錄網站的用戶第一個看的就是網頁內容，所以我們不應該出現這樣低級的錯誤。

在現實中，我們可以在JIRA中指定最初指定的優先順序，然後向Web開發人員和項目經理報告漏洞及其優先順序或嚴重程度。項目經理可以聯繫客戶並告訴他們發生了什麼事。最後，客戶決定是否必須儘快解決這個問題，或選擇等待客戶的意見可能與測試人員所想的不同，因此這些事項順序可以根據客戶意願很容易改變。

漏洞描述

測試人員應該向開發人員提供詳細的漏洞總結報告（重現漏洞問題）。

重現

這個步驟主要是描述漏洞是如何出現的，當然測試人員越多，越好。

產品

應用程序出現問題的詳細描述，測試人員應該提到瀏覽器、它的版本和運行環境系統狀態、用戶類型、用戶狀態、系統初始數據和用戶所在的頁面。

展示

測試人員展示如何出現漏洞

在看完上文後，我為大家總結一下安全檢查列表，主要分為軟體安全漏洞、配置錯誤、產品名稱以及影響度量。

實際結果與預期結果

實際結果是當測試人員重現漏洞時發生的事情，質量保證團隊提供實際結果的截圖，並與預期的結果進行比較。預期的結果是我們在給定條件下預計的正常功能。

下面這兩個信息，一個是錯誤的報告，一個是正確的報告。

正確 錯誤

漏洞已經在 Chrome 47以及火狐瀏覽器（38）測試 打開網站 http://www.hersheys.com

僅在火狐瀏覽器（38）有效 登錄

登錄https://www.hersheys.com/recipes/en_US/products/baking-pieces.html 退出賬戶

選擇Products選項 選擇Reese』s Mini Pieces選項

點擊Baking Pieces 實際結果：從列表中刪除所選項

                                                                                                                             預期結果：應打開Reese"s Mini Pieces選項詳細說明頁

漏洞總結報告的附加信息

這是漏洞總結報告最後的部分，如有必要，測試人員可附上任何相關的附加文件。我們的目標是儘可能多地收集文件，附件可以是，一張截圖、一個日誌文件（log.txt）、詳細描述漏洞文件、測試人員程序介面。在上文已經說明質量保證團隊如何寫報告，由於某些漏洞分析平台不同細節就會有出入，但遵循這些準則應有助於編寫優秀的漏洞總結報告。

*參考來源：rubygarage，飯糰君編譯，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 FreeBuf 的精彩文章: