【51CTO.com原創稿件】自從上一期，我們開始談到滲透測試以后，就有細心的朋友心生疑問的私信我：“上次聊的滲透測試怎么和我們平時接觸到的不太一樣啊?我可能看了假的‘廉環話’嗎?”看來我要趕快出來澄清一下了：朋友，您看得沒錯也問得非常好。因為上次是從完全模擬陌生攻擊者的角度來進行的“黑盒”盲測;而大家平時工作中與審計人員所接觸到比較多的應該是“灰盒”測試。那么為了保持本漫談的完整性，哥對這種“灰帽子”的滲透測試也和大家聊聊吧。借用我當年高中老師們的那句口頭禪：“來，我們直接看重點!”

其中準確性上容易失真的當屬“社會工程學與安全意識”測試了。由于可能事先走漏風聲、或是采集的“樣本”不夠豐富、亦或測試的時間不夠充沛，都可能產生企業員工安全意識強的假象。所以說技術只能幫你發現客觀存在的漏洞，意識則可以決定漏洞如何被利用。就算企業通過了此環節的測試，也只是一個短暫平衡態，或根本就是一個“幸存者偏差”。因此相關培訓和B輪、C輪測試必須成為一種常態。

最近很流行“下半場”的說法，那么廉哥接下來就繼續跟大家來聊滲透測試的下半場—測試報告吧。經過了前面模擬攻擊者的行為測試，我們安全人員需要最終整理出一份測試報告。就像那個經典的說法：“人們想買的不是一個鉆孔機，而是想在墻上打一個孔”一樣，請記住：我們報告不能寫得太文藝、也不能寫得過于學術化，畢竟它只是一個說明企業安全態勢的工具。下面具體我們來看看每個章節應該注意些什么吧。

報告對象

記得猶太文化里有個諺語就說過：世界上最難的有兩件事：一是把別人口袋里的錢拿到自己的口袋里，二是把自己腦袋里的東西塞到別人的腦袋里。這說明達到思想上的認同絕非易事。如果您不知道該報告的受眾和其關注點，那么從報告人自身的角度定義一個報告的脈絡or結構是非常重要的。這樣才會讓讀者有“帶入感”并隨之產生共鳴。

當然，根據我的經驗，至少有兩種類型的人會閱讀我們的測試報告：管理層和IT技術人員。而實際上管理層是不愿通篇閱讀當然也是讀不懂測試報告的。他們只想通過目測漏洞列表條目的數量和測試結論，來快速獲悉“我們現在到底安不安全?”而IT技術人員則對會各條漏洞分析尤為重視。他們時常懷揣著一顆“既覬覦系統在測試后并無重大漏洞;又希望漏洞程度與整改建議能全面且合理”的待嫁之心。所以我們要花時間搞清楚要報告的對象，并設身處地的從他們的角度來換位思考，做到言之有物、言之鑿鑿。能夠實現“老總看了會沉默，IT看了會流淚”那就厲害了。

封面

對沒看錯，我們從封面講起，要注意什么呢?要標明整個報告的“等級標識”和“測試日期”這兩個重要元素。

目錄

記得小時候讀書的時候，語文老師就教育我們：“拿到一本新書的時候要先看目錄，以后長大了去圖書館查找書籍也要如此。”同理，目錄可以讓閱讀此報告的人對報告的整體架構有個宏觀的認識，也可以快速跳躍的到其感興趣的章節和部分。

內容摘要

怎么聽上去有寫論文的趕腳?對，只不過不同的是：一般論文在這里盡量體現其通篇最有技術含量的元素，以便更為方便的被檢索到。但咱們的報告摘要，則應該盡量避免使用專業術語。因為真正會閱讀這部分的管理層金主(非技術類管理人員)可要比技術大牛可多得多哦。當然該部分也可以方便被直接摘錄到PPT里，進而在會議上分析與傳閱。其實全稱應該叫做執行摘要(Executive Summary)，也就是匯總性的告知測試了什么、發現了什么、而且是由于什么所導致的。然后就是所發現的漏洞的一個從高到底列表。當然，這里有個小貼士給大家：雖然測試報告命中注定是匯報IT系統和人員的“缺點”，但如果能在摘要中列舉出抗攻擊成功和安全措施到位的地方，則會在體現測試的客觀性和全面性的同時，也能給報告對象帶有些許安慰或成就感。畢竟誰都不想看到自己的系統和員工是那么的一無是處。而在執行摘要的最后應該是一個結論，即明確指出是該系統是安全還是不安全。

上述這些都是報告開篇的重要部分，應當能夠脈絡清晰的呈現在一頁A4紙上，讓“讀者”一目了然的知道接下來要做什么。

測試流程

在E文里，這個部分有個美麗的名字叫做“Technical Storyline”。對，就是最近熱播劇《West Word》里，老戲骨們爭得頭破血流的storyline。我們可以畫出帶有各種條件判斷和步驟框圖的測試Flow Chart，它既可以體現咱們的專業水平，又能彰顯測試思維的縝密性。另外，我們還可以在必要時闡述一下涉及到評判標準之類的方法論，以增強邏輯性。

工具列表

這里主要包括版本和功能的簡要描述。其好處是：如果有人要重現您的測試，則他們可以籍此確切的找到您使用的工具，實現測試的可重復性。

報告主體

這一部分在整個報告中的技術成分含量最高，報告的正文應當包括所有檢測到的漏洞細節。即：如何發現到漏洞、漏洞可以如何利用、以及其被利用的可能性有多大。并且還應該盡可能的逐條給出切實貼合的修復建議。在表述順序上可以有如下幾種“打開”方式：

· 以嚴重等級：從高到低，例如：從SQL的注入漏洞一直羅列到源代碼中留存的，盡管被注釋掉的信息。

· 以網絡架構：從外到內，例如：可以參考我們前面各期漫談所遞進介紹的網絡拓撲結構的順序哦。

· 以系統功能：從點散開，例如：將系統中所有涉及到偵聽、嗅探的各種測試都描述到位之后，再描述所有涉及密碼破解的測試結果。

哥本人喜歡用的方式是以填表的形式予以呈現，比如在每個表格里都固定包含的表項信息有：漏洞名稱、等級程度、被利用的可能性、危害范圍和建議等。而且要善用rich formatting(即不同顏色、字體、字號和效果等)，以達到醒目和易記憶的效果。當然也可以通過軟件來自動生成一些餅圖或柱狀圖，以體現各種占比。畢竟有圖有真相、圖文并茂，才更有說服力。

附錄

這里可以添加一些未盡之言的內容。比如：一些測試原理與依據的支撐材料，參加測試人員的資歷和項目經驗，以及一些必要的且包含有時間戳和系統特征信息的佐證截屏，甚至是一些術語說明列表等。

免責聲明

正如《阿甘正傳》里的那句：“生活就像一盒巧克力，你永遠不知道下一顆是什么味道。”我們在愉快的提交了測試報告后，是無法知道它被用來做什么以及會給自己的工作帶來什么的。所以如果你是作為第三方involve到這個測試中的話，最好是在最后或是扉頁處撰寫一個免責聲明，必要時可以附上有高層簽署的該滲透測試同意書。

那天哥陪一個小小孩下四分之一的圍棋盤。孩子一開始就口中念叨著“金角銀邊草肚皮”那句口訣。這使我突然頓悟到：我們信息安全與下圍棋也有相通之處啊。系統的安全同樣也是從邊界防護開始著手的(曾記否?咱們漫談就是從邊界講起的哦。);而滲透測試則更像是我們平時“打棋譜”一樣，不斷通過模擬攻防、揣摩改進以培養對整體系統安全的全局掌控能力。另外，與要把對方的攻擊性棋子消滅干凈并將死才為勝利的象棋不同，圍棋講求的是：無不同職能棋子的區分，雙方棋子尚在棋盤上的情況下，只要在數量上達到可預見的制衡，便可判定勝負。因此，對于各種攻擊，我們做信息安全的也無法完全阻止，更不存在一勞永逸之法;我們只能將“魔高一尺，道高一丈”動態化且常態化。想著、想著我居然連輸了孩子兩盤……

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】