先說幾句廢話，望大家海涵^_^
（如果你想從頭開始一步步學習安全測試設計，請從我的上一篇文章開始一步步學習下去<點擊打開鏈接>，但如果因爲工作進度很急，可以先跳過下面的”廢話“直接參考總結好的測試方案）
說起安全測試，曾幾何時在我心中一直是一項“高大上”的工作，它涉及軟硬件、系統架構設計、代碼/腳本開發、彙編/反彙編等多個技術層面；相關的技術人才也比較”貴“...從而導致了中小型互聯網企業的產品在提到安全性測試問題時都一籌莫展，誇張一些講，相當一部分小型互聯網創業者的產品都是夭折於”網絡安全“這個亙古不變的話題、最終因產品失去最終用戶信任而走向創業失敗的低谷。那麼，安全性測試就真的難以在中小型企業中普及和進行嗎？
本人有幸從2013年開始，硬着頭皮被公司”逼“到了安全測試領域這塊兒”聖地“（說來慚愧，當時都快急瘋了，呵呵...），經過近兩年的摸爬滾打，將自己的見聞和心得和大家分享一下，尤其希望能幫到想進行安全測試、但又不知道從何下手的小夥伴，讓我們互相學習、共同提高，共同整理出一套能複用於大部分業務系統的安全測試方案，還網絡一片淨土。
先列一下安全測試設計的技能列表（本內容來源於網絡，經過自己整理和親身體會，挑出了感覺對自己有幫助的技能供大家參考）：
A、前期
1、瞭解什麼是hacker，這點看似沒什麼關係，但作爲測試最基本的素質，就是要”換位思考“，你要明白應該以什麼角色去測試要負責的系統；搞明白hacker的基本行爲模式和動機，可以更好的幫我們制定出消減威脅的措施和方案；
2、一些基礎命令，包括DOS命令，以及UNIX / Linux下的命令。
3、遠程掃描、遠程刺探技術。包括通過系統自帶命令的信息刺探以及使用工具掃描等。
4、密碼破解。瞭解現在的密碼破解的適用範圍，以及操作技巧等等。
5、溢出攻擊。溢出工具的使用方法。
6、注入攻擊。注入攻擊只是一個簡稱，這裏還要包括XSS、旁註、遠程包含等一系列腳本攻擊技巧。
7、學會各種編譯工具的使用方法，能編譯ShellCode。
8、學會手動查殺任何木馬、病毒，學會分析Windows操作系統，以使自己百毒不侵。
B、中期
1、學習所有Windows下服務器的搭建步驟（ASP、PHP、JSP）。
2、掌握例如Google hacker、cookies 、網絡釣魚、社會工程學等。
3、學習HTML、JavaScript、VBScript。
4、學習標準SQL語言，以及大多數數據庫的使用。
5、學習ASP，並擁有發掘ASP腳本漏洞的能力。
6、學習PHP，並擁有發掘PHP腳本漏洞的能力。
7、學習JSP，並擁有發掘JSP腳本漏洞的能力。
8、學習掌握最新腳本的特性以及發掘漏洞的方法。
C、後期
1、確定自己的發展方向
2、學習C語言，並嘗試改寫一些已公佈的ShellCode。
3、學習C++，嘗試編寫一個屬於自己的木馬（如果你想自己編寫木馬的話）。
4、學習彙編
5、研究Linux系統內核。
6、學習緩衝區溢出利用技術。
7、ShellCode技術。
8、堆溢出利用技術、格式化串漏洞利用技術、內核溢出利用技術、漏洞發掘分析。
(如果覺得有什麼不對或者紕漏，還望各位不吝賜教)
*下面是後文要用到的術語說明和解釋：
| 名詞 | 解釋 |
| 分類 | 針對測試點的測試優先級分類，分爲S1，S2，S3三類： S1類爲必須滿足的，是核心功能，如果沒有此功能產品不可用或存在重大安全隱患； S2類爲競爭類需求，這些需求的實現能提升產品的競爭力，滿足大部分客戶的安全需求； S3類爲優勢類需求，這些需求的實現能使我們的產品比競爭對手的產品更具安全優勢 |
| 不滿足原因 | 如果不滿足，需要寫清楚不滿足的原因；如果是部分滿足，需要寫清楚哪些是滿足的，哪些是不滿足，不滿足的具體原因是什麼； |
| 測試結果定義分類 | 根據測試結果對滿足度進行說明，值爲“滿足”、“部分滿足”、“不滿足”、“未測試”、“不涉及” |
| 操作員帳號 | 業務系統分配給局方或者廠家人員用於對本業務系統進行業務運作、系統管理以及維護的帳號，如營業廳操作員的帳號等。 |
| 程序帳號 | 由程序使用的帳號，例如在某程序中實現SFTP自動傳輸文件的功能，那麼在這段程序中使用的、爲了實現SFTP自動登錄的帳號即爲程序帳號。 |
| 最終用戶帳號 | 屬於業務範疇的帳號，如手機號、eMail 用戶帳號等。 |
| 安全敏感國家 | 指美國、加拿大、澳大利亞、新西蘭、瑞士和EEA歐洲經濟區，包括這些敏感國家的海外領土和屬地。 其中，當前EEA經濟區覆蓋30個歐洲國家，包括：法國、意大利、荷蘭、比利時、盧森堡、聯邦德國、愛爾蘭、丹麥、英國、希臘、葡萄牙 、西班牙、奧地利、芬蘭、瑞典、波蘭、拉脫維亞、立陶宛、愛沙尼亞、匈牙利、捷克、斯洛伐克、斯洛文尼亞、馬耳他、塞浦路斯、保加利亞、羅馬尼亞、挪威、冰島、列支敦士登。 |
| 貿易禁運國 | 目前貿易合規領域最需要關注的區域主要是美國定義的禁運國家，包括： 伊朗，北蘇丹；古巴；敘利亞；北朝鮮 |
| 客戶網絡數據 | 指所有權歸屬客戶或第三方的、來源於客戶網絡或者與客戶網絡特徵有關的數據，包括：來源於客戶網絡的個人數據、客戶網絡規劃數據、客戶網絡運行數據、客戶網絡運營管理數據、客戶網絡技術服務數據、客戶網絡安全方案數據、客戶網絡資源數據等。客戶網絡含客戶測試網絡、客戶商用前網絡、客戶商用網絡。從法律角度來看，未經客戶授權接入訪問客戶網絡數據或超出客戶授權範圍，採集、轉移、存儲、使用和處置上述網絡數據可能會構成侵權或違約。 不在上述定義範圍內的來源於客戶的其他數據，如客戶經營管理制度、客戶培訓資料、客戶項目運營流程及規定等，需遵從雙方保密協議要求、當地商業祕密保護相關法律法規來收集、處理和保存。 |
| 原始通信內容 | 通信雙方（只要其中一方涉及自然人）之間的實際通信內容，包括語音類、短信/彩信類、傳真類、數據業務（如即時消息、Email、視頻通信、網頁瀏覽等）類等 |
| 合法監聽敏感信息 | 指合法監聽相關的事件信息，如監聽目標（通信參與方）、監聽時間、通信時間、通信時長等，不包括通信內容 |
| 非信任網絡 | 信任網絡與非信任網絡通常是相對而言的，信任網絡通常是指對該網絡內的所有設備和用戶的行爲是可信的網絡，如同一信任域內的設備，非信任網絡則通常指該網絡內的設備和用戶行爲不可控或存在較大安全風險的網絡，如Internet、intranet、與第三方SP/CP的接口等 |
| 匿名化 | 指對個人數據進行的更改（例如單向散列、截短、替換等，如需保留個人數據真實值與替換值之間的對應關係，可以使用對稱加密或映射表方式，但密鑰/映射表必須由產產品對應的客戶控制），使原來有關個人的信息不再能歸屬到一個可識別的自然人，或推理這種歸屬需要耗費過多、不相稱的時間、費用和精力。來源：《德國個人數據保護法》 |
| 安全刪除 | 指對數據刪除之後不可恢復，或者恢復需要付出過多、不相稱的時間、費用和精力。例如：對RAM（內存）用新的數據覆蓋或下電；對磁盤分區進行低格、對磁盤文件重寫三次或以上、對磁盤進行消磁、粉碎；對CD進行物理粉碎等。來源：參考德國合作項目顧問建議 |
| 未公開接口 | 可繞過系統安全機制（認證、權限控制、日誌記錄等）對系統或數據進行訪問的功能（如客戶無法管理的固定口令/隱藏賬號機制、不記錄日誌的非查詢操作等）及產品資料中未向客戶公開的命令/外部接口（如隱藏命令/參數、隱藏端口等接入方式） |
| 遠程訪問 | 通過Internet或局域網遠距離訪問設備的接入方式 |
| 受限公開 | 對於涉及產品知識產權、高危操作、可外部調用的內部接口等不期望向所有客戶人員公開的內容，不在正式發佈的面向所有客戶的產品資料中公開，僅主動向客戶/政府特定人員公開或僅在客戶要求時再公開（與客戶簽署保密協議），以規避因實現細節過度公開而導致的安全風險。在正式發佈的面向客戶的產品資料中需註明受限公開資料的獲取方式/途徑。 |
| 增值服務 | 歐盟2002年58號文——任何要求對數據流（traffic data）或數據流以外的位置數據進行處理的服務，不包括爲了必要的通信傳輸和計費目的所需要處理的數據流。 |
| CPI資料 | Customer Product Information，交付給客戶的產品資料包。 |
| 身份認證 | 驗證用戶身份的真實性。認證方法有基於用戶所知道的、基於用戶所擁有的、基於用戶個人特徵。 常見的用戶身份認證有：口令認證、智能卡認證、動態口令認證、數字證書認證、生物特徵認證等。 |
| 個人數據 | 單獨使用該數據或者結合其他信息可以識別某個活着的自然人的數據，包括：最終用戶姓名、賬號、主叫和被叫號碼、通信記錄、話單、通信時間、定位數據、即時消息、好友關係、在網盤上存儲的個人文件（相片、音頻、視頻、記事本）等。在法律上，判斷某類信息是否是個人數據不是絕對的，必須結合場景與處理目的來判斷。 |
| SSL 協議 | SSL(Secure Socket Layer) 位於應用層和傳輸層之間，它可以爲任何基於 TCP 等可靠連接的應用層協議提供安全性保證。 SSL 協議實現的安全機制包括： 1、 數據傳輸的機密性：利用對稱密鑰算法對傳輸的數據進行加密。 2、 身份認證機制：基於證書利用數字簽名方法對服務器和客戶端進行身份驗證，其中客戶端的身份認證是可選的。 3、 消息完整性驗證：消息傳輸過程中使用基於 MD5 或 SHA 的 MAC 算法來檢驗消息的完整性。 |
| TLS 協議 | TLS 協議設計的具體目標是解決兩個通信實體之間的數據的保密性和完整性等，總體目標是爲了在因特網上統一 SSL 的標準。因此，在協議構成方面，TLS 幾乎與SSL協議一樣，主要分爲 TLS 記錄協議與TLS握手協議。TLS 記錄協議與 SSL 記錄協議基本一致，字段的內容也基本相同。TLS 記錄協議也有4種類型的客戶：握手協議、警告協議、改變密碼規格協議和應用數據協議等。爲了便於 TLS 的擴展，TLS 記錄協議還支持額外的記錄類型。 TLS 建立會話協商的參數、握手協議過程等與 SSL 一致。 |
| 加密協議 | FTP、HTTP、Telnet 協議都是以明文傳輸的應用層協議，傳輸過程中存在被竊聽的安全隱患，SFTP/FTPS、HTTPS、SSH 是分別與之對應的加密應用層協議。 |
| 初始密鑰 | 用來導出主密鑰的密鑰。一般爲操作員輸入或者寫死在代碼中，寫死在代碼中時必須遵循本基線中“加密解密”相關的要求。公司開發的加密庫，其中包含了密鑰導出函數：PKCS5-deriveKey(…)，可以直接調用該函數導出加密的密鑰。Java 中請參考類 PBEKeySpec。 |
| 主密鑰 | 用來加密（使用對稱算法）工作密鑰的密鑰。一般是使用密鑰導出算法對初始密鑰進行計算而得出。某些場景下，主密鑰就是工作密鑰，但一般不建議。 |
| 工作密鑰 | 用來加密（使用對稱算法或者 HMAC 算法）業務中敏感數據的密鑰。一般是隨機生成的。某些場景下，是由用戶/操作員輸入、然後使用密鑰導出算法計算得到。 |
| 敏感數據 | 敏感數據的具體範圍取決於產品具體的應用場景，產品應根據風險進行分析和判斷。典型的敏感數據包括口令、銀行帳號、大批量個人數據、用戶通信內容和密鑰等。 |
| 個人數據 | 單獨使用該數據或者結合其他信息可以識別某個活着的自然人的數據，包括：最終用戶姓名、賬號、主叫和被叫號碼、通信記錄、話單、通信時間、定位數據、即時消息、好友關係、在網盤上存儲的個人文件（相片、音頻、視頻、記事本）等。在法律上，判斷某類信息是否是個人數據不是絕對的，必須結合場景與處理目的來判斷。 比如系統同時採集如下幾種信息： 1.聯繫信息：姓名、email、電話、住址、賬單地址等 2.唯一標識：身份證號、社保號、駕照、指紋、護照 3.統計信息：年齡、性別、種族、宗教信仰、犯罪記錄 4.職業信息：公司、行業、工作頭銜 5.醫療保健信息：計劃、供應商、歷史、保險、遺傳信息 6.金融信息：銀行、信用卡銀行卡、購買記錄、信用記錄 7.在線活動信息：IP地址、cookie、網頁瀏覽數據、用戶聯繫人名單、登錄的信任狀等 8.種族、民族 9.政治觀點 10.宗教信仰 11.身體、精神健康狀況 12.性取向 13.犯罪史 14.是否有被訴訟記錄 |
| EEA | EEA（歐盟經濟保護區）：當前EEA經濟區覆蓋30個歐洲國家，包括：法國、意大利、荷蘭、比利時、盧森堡、聯邦德國、愛爾蘭、丹麥、英國、希臘、葡萄牙 、西班牙、奧地利、芬蘭、瑞典、波蘭、拉脫維亞、立陶宛、愛沙尼亞、匈牙利、捷克、斯洛伐克、斯洛文尼亞、馬耳他、塞浦路斯、保加利亞、羅馬尼亞、挪威、冰島、列支敦士登。 |
| PAN | Primary Account Number:主賬號 |
| SNMP團體串 | 起密碼作用的文本串，用於鑑權在管理站點和SNMP代理之間的信息發送。存在於SNMP管理和SNMP代理之間傳送的數據包裏 |
| 強加密 | 強加密算法是基於業界測試和接受的算法，並具有強密鑰長度及正確的密鑰管理措施。目前業界接受的加密算法標準有：AES（128位及更高版本），TDES（最小雙長度密鑰），RSA（1024及更高版本），ECC（192位及更高版本，ElGamal（1024位及更高版本）。 |
應用安全測試設計
*寫作格式說明
一、父類需求分類
1. 次級需求分類：該子類需求的解釋（這裏附需求“分類”，參考上表第一條）
（1）該類需求的測試細化點一（附可能引入的最早階段）
（2）該類需求的測試細化點二（附可能引入的最早階段）
tips：如果該細化點設計思路較難、會給出一些我自己思考或網上搜集整理的解決辦法，以及相關的工具、技術參考等等。
一、賬號管理
1. 賬號唯一性：系統中的帳號名稱具有唯一性（S1類）
（1）操作員帳號、程序帳號、最終用戶帳號唯一；（引入階段：設計）
（2）是否有可能繞過系統的賬號唯一性校驗；（引入階段：設計和開發）
tips：
開啓webscarab/burpsuit/fiddler之類的代理工具；
訪問賬號註冊/創建界面；
篡改通過頁面校驗的新賬號爲其它已存在賬號、然後放通，看能佔用已存在賬號的權限並使用自己創建的密碼。
2. 帳號不能寫死在代碼中，須提供可管理（或配置）機制。（引入階段：設計和開發）
tips：
通過訪談獲取開發常用賬號定義關鍵字；收集產品常用賬號；打開Search and Replace，使用前兩步中的關鍵字搜索代碼，根據搜索結果分析是否存在硬編碼賬號。任何實際帳號都不能寫死在代碼中，所有賬號均可管理（或可配置）；
二. 身份認證：
1. 當用戶訪問受限資源或請求需要鑑權的操作時，必須先對提出該操作請求的用戶成功地進行認證（引入階段：設計）
檢查應用程序是否提供認證機制（例如：用戶名/口令認證、密鑰認證、證書認證、智能卡認證、USB Key認證、動態口令認證、生物特徵認證、IP認證等）來保護受限訪問的資源。最典型的認證措施就是：提供登錄界面/頁面，需要訪問者輸入用戶名、口令[、驗證碼]，身份認證通過後，才能訪問系統的受限資源。
2. 身份認證必須在服務端進行（引入階段：設計和開發）
（1）對於C/S軟件系統的用戶最終認證處理過程放到服務端進行。此處“客戶端/服務端”軟件系統是相對於單機版軟件系統而言的。不允許以客戶端驗證的結果作爲用戶最終認證結果，必須在服務端進行最終的認證處理（如果採用集中認證，那麼對用戶的最終認證就是放在集中認證服務端進行）。
（2）B/S 應用中，對用戶的最終認證處理過程不允許僅僅通過腳本或其他形式在客戶端進行驗證，必須在應用服務器進行最終認證處理（如果採用集中認證，那麼對用戶的最終認證就是放在集中認證服務器進行）。
tips：設計思路如下：
○在未連接服務器端的情況下是否能認證成功；○在客戶端提交正確的賬號口令，但是攔截不發送到服務器端，是否能認證成功；
○分析整個認證過程，在客戶端提交正確賬號口令，但是攔截後發送錯誤的賬號口令到服務器端，但模擬服務器回覆正確的登錄請求給客戶端，觀察客戶端功能是否開啓
○分析整個認證過程，只發送最後一步消息提交到服務器端，觀察認證是否通過
○分析整個認證過程，觀察是否有可利用之處（好吧，這句純粹爲了湊字數...請大家幫忙補充^_^）
（3）服務器端的認證不能被客戶端關閉
tips：用burpsuite截取到的碼流如果存在的非用戶名口令驗證碼以外的字段：無論刪除或是修改這些字段都不會影響服務器認證
3. 認證失敗不能提示詳細錯誤原因（操作員帳號、最終用戶帳號都要檢查）
tips：可以提示：“用戶名或者口令錯誤，登錄失敗”；不能提示：“用戶名不存在”、“口令錯誤”等等。
4. 爲了防止暴力破解，必須使用驗證碼；且驗證碼是隨用戶名、密碼同時提交到服務器端進行校驗。
tips：或者多次登錄失敗後，必須提供驗證碼。說明：要參照下文的“鎖定策略”，驗證碼和鎖定策略都沒有的情況纔會成爲安全問題。這裏容易漏測的地方是控制檯。如果該系統的控制檯有必要啓用，則必須滿足本文提到的所有安全策略。
5. 驗證碼的機器識別率必須低於5%（現在網上有許多開源的驗證碼識別工具，可以嘗試一下）
6. 3次登錄/認證失敗後使用驗證碼時，原認證表單失效
tips：此測試點僅針對"多次登錄失敗後，才提供驗證碼"場景
1、啓動burpsuite，並配置get和post請求的攔截；
2、訪問登錄/認證界面，輸入正確的帳號錯誤的密碼提交；
3、將WebScarab/burpsuite_v1.4.01攔截的表單內容記錄下來，並點擊“Accept Changes”放通（此時攔截信息不包含驗證碼）；
4、錯誤訪問三次之後，登錄/認證界面彈出驗證碼；
5、使用WebScarab/burpsuite_v1.4.01攔截，並將內容替換成步驟3中記錄下來的表單內容，修改錯誤的密碼爲正確的密碼，點擊“Accept Changes”
備註：本用例屬於產品必須根據實際情況定製的用例，用例設計思路如下：
1、繼續使用原來不帶驗證碼的消息；
2、客戶端清空錯誤次數；
3、繞過業務處理錯誤次數的客戶端參數（如部分產品根據session、ip等記錄錯誤提交次數，可以通過設置session、ip爲變量繞過這一判斷）
4、攔截次數刷新請求（如部分產品通過客戶端提交單獨的錯誤次數，或者錯誤次數達到了由客戶端提交申請舊登錄請求失敗/新登錄請求生效的消息）
7. 驗證碼模塊生成的隨機數不能在客戶端的靜態頁面中的網頁源代碼裏出現（引入階段：開發）
驗證碼模塊生成的隨機數不能在客戶端的靜態頁面中的網頁源代碼裏出現。在客戶端網頁上點擊鼠標右鍵、選擇“查看源文件”時，必須看不到驗證碼模塊生成的隨機數。
8. 驗證碼內容不能與客戶端提交信息相關聯
驗證碼內容不能與客戶端提交的任何信息相關聯。在使用驗證碼生成模塊時不允許接收來自客戶端的任何參數，例如：禁止通過getcode.jsp?code=1234 的 URL 請求，將 1234 作爲驗證碼隨機數。
9. 驗證碼字符串要求是隨機生成（對於 java 語言可以使用類 java.security.SecureRandom 來生成安全的隨機數。）
10. 驗證碼在一次使用後立即失效
11. 驗證碼檢驗通過後才進行用戶名和密碼的檢驗
tips：
1、訪問所有帶有驗證碼的登錄頁面；
2、開啓WebScarab，配置對GET、POST和PUT請求及響應進行攔截（即同時勾選“intercept requests”和“intercept respones）；並在瀏覽器中配置代理服務器IP爲127.0.0.1，端口爲8008；
3、填入錯誤的用戶名和口令，填入錯誤的驗證碼，提交表單；
4、查看系統響應消息及返回的提示信息。
三. 強口令策略
1. 口令長度應可配；（引入階段：設計）
2. 口令包含的字符、也就是複雜度可配；（引入階段：設計和開發）
3. 修改自己的口令需驗證舊口令；（引入階段：設計和開發）
4. 界面上的口令不能明文顯示；（引入階段：設計和開發）
tips：這裏的明文不光指文本框裏面，還包括頁面源代碼和瀏覽器/客戶端的內存中。可以用內存查看工具檢測。
5. 口令輸入框不支持拷出功能；（引入階段：設計和開發）
6. 口令在本地存儲時必須加密；（引入階段：設計和開發）
7. 存儲口令的文件/數據庫表用戶的訪問權限控制；（引入階段：設計和開發）
8. 提供賬號口令清單；（引入階段：資料和開發）
9. 在 B/S 應用中，從服務器端的會話信息中獲取修改口令的用戶帳號（引入階段：設計和開發）
tips：也就是說，修改口令的帳號只能從服務器端的會話信息中獲取，而不能由客戶端指定。可以分析WebScarab攔截的修改口令的請求中是否包含操作員帳號和可能被猜解的身份標識。
10. 非運營商需求中明確要求有修改其它賬號權限的超級管理員賬號不可以修改其它賬號的密碼（引入階段：設計和開發）
11. 操作員不可修改自身帳號以外帳號的口令（引入階段：設計和開發）
12. 口令不能和用戶名相同（引入階段：設計和開發）
13. 內置賬號口令管理（引入階段：設計、資料和開發）
tips：
1、收集應用所使用的所有內置賬號（系統初始化安裝後所存在的帳號，包括OS、DB、應用本身的初始帳號等等。）
2、檢查所有內置帳號的缺省口令是否符合複雜度的要求（是否滿足口令長度、口令包含字符、口令不能和用戶名相同、等等基本要求）。
3、檢查客戶資料中是否提醒用戶修改。
四. 會話管理（引入階段：開發）
1. 防止會話固定：在 B/S 應用中，用戶名和口令認證通過後，必須更換會話標識，以防止會話固定（session fixation）漏洞。
tips：
1、啓動burpsuite，並配置對GET、POST和PUT請求進行攔截；
2、訪問登錄頁面，輸入用戶名、口令、驗證碼，登錄，通過burpsuite攔截登錄請求，查看並記錄其中的jsessionid信息；
3、登錄成功後，再訪問任意功能菜單，並通過burpsuite攔截登錄請求，查看並記錄其中的jsessionid信息；
4、比較步驟2和步驟3獲得的jsessionid是否一致。（也就是登錄前和登錄後，會話標識是否一致）。
2. 會話中不允許修改的信息作爲會話狀態的一部分在服務器端存儲和維護
說明：在 B/S 應用中，會話過程中不允許修改的信息，必須作爲會話狀態的一部分在服務器端存儲和維護。會話過程中不允許修改的信息，例如，當用戶通過認證後，其用戶標識在整個會話過程中不能被篡改。禁止通過隱藏域或URL重寫等不安全的方式存儲和維護。對 JSP 語言，就是應該通過 session 對象進行存儲和維護。
tips：
1、登錄系統；
2、逐個訪問各功能菜單，查看URL或頁面源文件（以hidden關鍵字，在源文件中查找隱藏域）是否包含用戶標識、商品價格等不允許客戶端修改的信息；
3、嘗試通過burpsuite攔截並修改步驟2發現的不允許客戶端修改的信息（比如：把用戶標識改爲其他用戶，或者把商品價格改爲低價格），然後提交給服務器；
4、查看後臺數據庫的相關數據，檢查步驟3的篡改是否起作用。
注：諮詢開發設計，會話中除session以外的信息的用途，並嘗試會話中除session以外的所有信息。
四. 認證失敗後處理（引入階段：設計）
1. 連續登錄失敗鎖定帳號
注：如果已經做了驗證碼防止帳號口令的暴力破解，那麼，不強制遵循本條要求。
2. 連續登錄失敗鎖定策略的“允許連續失敗的次數”可配置
3. 連續失敗次數指同一個帳號從最後一次登錄成功以來登錄失敗的次數的累積值
tips：
1、連續N-1次使用錯誤的口令登錄使帳號鎖定；
2、使用另一個賬號口令正常登錄業務系統並退出；
3、使用步驟1中的賬號再次錯誤登錄
4、使用另外一臺機器，嘗試登錄步驟1中的賬號
4. 鎖定時長可配置
5. 連續登錄失敗鎖定策略執行並在鎖定時間超時後自動解鎖（在鎖定時間內，僅能允許應用安全管理員角色所屬帳號手動解鎖該用戶）
五. 權限鑑別（引入階段：設計和開發）
1. 縱向越權防範：可以從以下幾個方面考慮
在 B/S 應用中，對於每一個需要授權訪問的頁面或servlet的請求都必須覈實用戶的會話標識是否合法、用戶是否被授權執行這個操作，以防止URL越權。防止用戶通過直接輸入URL，越權請求並執行一些頁面或servlet。
（1）基於URL鏈接的縱向越權
（2）基於頁面文件的縱向越權
（3）基於action、dwr等其他形式的的縱向越權
（4）通過客戶端修改權限控制字段：
針對B/S和C/S的Web應用：·以超級管理員/高級用戶身份登錄應用系統；
·啓動burpsuite，並配置對GET、POST請求進行攔截；
·訪問一些低級用戶沒有權限訪問的資源，檢查burpsuite攔截下來的請求中是否存在可能代表權限的參數，將這些參數和參數值及該資源的URL鏈接記錄下來；（如http://www.example.com/modify.do，它的參數裏面有類似privilege、privilegecode、userid、id、level、levelid等等都有可能是權限控制字段，部分產品的權限控制字段或用戶關鍵標識信息可能在Cookie中）
·訪問一些低級用戶沒有權限訪問（主要是低級用戶不可見）的資源，檢查burpsuite攔截下來的請求中是否存在可能代表這些資源標識的參數（如低級用戶可見的資源爲http://www.example.com/viewbook.do，不可見的資源爲http://www.example.com/modifybook.do，這是用URL本身來標識資源。如http://www.example.com/book.do?op=modify，這是用op參數來標識資源，常見可疑參數類似menu、menuid、action、res、resource、interface等等），將這些參數及參數值記錄下來；
·停止burpsuite攔截功能；
·超級管理員/高級用戶退出應用系統的登錄；
·以低級用戶身份登錄應用系統；
·啓動burpsuite，並配置對GET、POST請求進行攔截；
·訪問應用系統任意資源，在burpsuite攔截的請求中，修改URL地址爲步驟3中的URL地址，修改/構造可能代表權限的字段爲步驟3中的權限字段的值（如level的參數值由2修改爲0），檢查低級用戶是否能成功訪問這些資源；
·訪問應用系統任意資源，在burpsuite攔截的請求中，修改URL地址爲步驟4中的URL地址，修改/構造可能代表權限的字段爲步驟4中的權限字段的值，檢查低級用戶是否能成功訪問這些資源
注：不用記錄步驟7之前的cookie中的session，可以嘗試修改cookie中代理權限和用戶級別的字段，但本測試不需要將步驟7之前的session/jsession覆蓋步驟7之後的request中。
（5）繞過按鍵/頁面元素限制的縱向越權：查找系統中是否存在管理員可用而在普通用戶頁面中爲灰色(不可用)的按鍵/頁面元素。如有，將對應的按鍵/頁面元素源代碼改爲可用，此時頁面上對應的按鍵/頁面元素即變爲可用、再正常使用此按鍵/頁面元素,查看服務器是否響應普通用戶的越權請求。
2. 橫向越權防範 （橫向越權，例如：部門經理A和B分別只能查看部門A和B內部人員的信息，部門經理A查詢部門人員A1的信息，提交的參數包含A1的工號A001，這時，部門經理A將A001改爲B001（部門B的員工工號），越權訪問B部門人員的信息，這就是橫向越權。）
六. 禁止使用未向客戶公開的接口（引入階段：設計和開發）
1. 禁止留有後門：禁止存在可繞過系統安全機制（認證、權限控制、日誌記錄）對系統或數據進行訪問的功能。
tips：
1、查看系統的設計文檔、用戶手冊，檢查系統存在可繞過系統安全機制（認證、權限控制、日誌記錄）對系統或數據進行訪問的功能。
2、結合開發人員的訪談，檢查系統是否存在可繞過系統安全機制（認證、權限控制、日誌記錄）對系統或數據進行訪問的功能，例如：固定密碼、隱藏帳戶、隱藏命令、隱藏參數、隱藏軟參，隱藏接口、調試端口/命令等。
*這點對於測試來講實際操作起來有些困難，尤其是對於不懂編程的測試員，很容易漏測。大家有什麼好的方法可以補充。
（1）禁止空口令
（2）對後臺命令、命令行工具、重要文件增加權限控制及管理機制
（3）基於URL鏈接的繞過安全機制對系統或數據訪問
（4）基於頁面文件的繞過安全機制對系統或數據訪問
tips：
此測試點根據不同Web控制檯Web應用存放目錄不同，以下以JBOSS爲例：
該應用發佈兩種服務http://IP:PORT/Web應用/***.***
http://IP:PORT/monitor/test.html
1、登錄Web服務器後臺，訪問Web應用所在的目錄
~/jboss/server/default/deploy/smap.ear>ls
default.war META-INF monitor.war
其中deploy下smap.ear爲產品應用，default.war和 monitor.war目錄分別存放以上兩個URL使用到的文件，http://IP:PORT/monitor/test.html中monitor爲服務名，後面的test.html可被替換拼接URL，
http://IP:PORT/frameset/login.action的服務名爲空，拼接URL時直接替換frameset/login.action
2、查找default.war和 monitor.war目錄以及其子目錄存在的文件（find . -name "*html"，藍色字體可替換爲*bat,*dat，*lic等 ）
3、根據查詢到的文件列表，嘗試構造通過Web訪問的URL，不經登錄直接通過預覽器訪問這些文件：
a.~/jboss/server/default/deploy/smap.ear/monitor.war>ls
db.jsp test.html WEB-INF
則可通過http://IP:PORT/monitor/db.jsp以測試db.jsp
b.~/jboss/server/default/deploy/smap.ear/default.war/license>ls
license.dat
則可通過http://IP:PORT/license/license.dat以測試license.dat
（5）基於action等其他形式的繞過安全機制對系統或數據訪問
（6）對於現網維護期間不會使用的命令/參數、端口等接入方式，必須刪除。
（7）接口認證（禁止不經認證直接訪問系統的接口）
2. 禁止隱祕訪問方式
（1）非查詢操作日誌記錄：保證每一個非查詢操作有日誌記錄。
3. 禁止不可管理的認證/訪問方式
（1）用戶清單與密碼修改指南
（2）對於人機接口以及可遠程訪問的機機接口，不得存在用戶無法修改的口令（含程序中的硬編碼口令）。
4. 禁止使用隱藏或未文檔化的接入方式
（1）控制檯安全測試
tips：產品根據實際情況進行用例設計，測試設計思路如下：
方式一：根據端口構造訪問入口
1、登錄服務器查看系統開啓端口（或者使用nmap掃描）
2、根據端口對應的服務類型，使用對應的協議訪問該端口
3、B/S架構的採用http://ip:port/的方式訪問該port（C/S根據實際情況使用測試樁或者模擬器）
4、觀察步驟2、3的結果，如果訪問成功，則檢查其是否有防暴力破解策略；如果沒有訪問成功，觀察返回結果，如果不是因爲端口問題導致的響應失敗，則繼續嘗試構造登錄入口。由於不同的應用可能目錄有所差異，如果訪問不到，可以登陸後臺服務器以find命令查找，比如find / -name “*console*”，find / -name “*admin*”，看看實際的URL應該是什麼，再次嘗試。也可以從網上搜索獲取類似路徑。
方式二：根據系統類型&配置等信息設計
1、蒐集業務所在的操作系統的維護端/控制檯/管理入口信息
2、蒐集業務所在的平臺的維護端/控制檯/管理入口信息
3、蒐集業務所加載外部包/庫/模塊/容器的維護端/控制檯/管理入口信息
4、蒐集業務第三方部件的維護端/控制檯/管理入口信息
5、嘗試構造訪問
備註：常見的控制檯訪問入口（如有發現新的，請補充刷新）：
Tomcat控制檯URL：http://www.example.com/manager/html
Jboss控制檯URL：http://www.example.com/jmx-console/
Jboss控制檯URL：http://www.example.com/web-console/
WebSphere控制檯URL：http://www.example.com/ibm/console/logon.jsp
WebLogic控制檯URL：http://www.example.com/console/ （一般console的端口爲7001）
Apache控制檯URL：http://www.example.com/server-status
Axis2控制檯URL：http://www.example.com/axis2-admin/
iSAP控制檯URL：http://www.example.com/admin/login.jsp
Virgo控制檯URL：http://www.example.com/admin
uniportal控制檯URL：http://www.example.com/mc/zh/login.jsp
Resin3.0控制檯URL：http://www.example.com/admin_manage/
Resin3.1及更新版本的控制檯URL：http://www.example.com/resin-admin/
“普元”管理控制檯URL：http://www.example.com/eosmgr/
在瀏覽器地址欄中輸入Web服務器對應的URL。
七. 權限管理（引入階段：設計和開發）
1. 採用基於角色的帳號權限管理模型
tips：以系統管理員登錄系統，訪問系統的權限管理模塊，檢查系統的權限管理是否基於以下步驟：
1、創建角色
2、爲角色分配權限
3、創建帳號並指定其所屬角色（注意，權限不能直接和賬號相關聯）
4、帳號自動繼承角色所擁有的權限
2. 授權和用戶角色數據存放在服務器端
在測試過程中，通過burpsuite代理攔截各種get和post請求，查看cookie和隱藏域中是否包含角色、權限、系統及其他敏感信息。
*注：本測試用例主要是爲了檢查權限關鍵數據存放位置。
八. 敏感數據（引入階段：開發）
1. 禁止在代碼中存儲明文的敏感數據：用Search and replace或者Fortify掃描代碼中的username,admin,passwd,password,userid等開發常用關鍵字，確保代碼中沒有明文敏感數據。
2. 敏感數據加密傳輸
tips：
1.在非信任網絡之間進行敏感數據的傳輸採用安全傳輸通道或者加密後傳輸，有標準協議規定除外。
2.避免密文與密鑰一起傳輸、傳輸口令的SHA256摘要(數據庫中存儲的也是SHA256摘要)等等實際不能達到防止黑客攻擊(重放攻擊)效果的設計
3.在非加密傳輸通道中傳輸的密文，被wireshare抓包後獲取後可以直接使用也不滿足本用例要求（例如登錄時不知口令原文直接在消息體裏放密文也可以登錄成功。）
說明：系統不同節點間的通信如果中間網絡經過Internet，則需要考慮敏感數據加密傳輸
（1）安全傳輸協議：
所使用的傳輸協議的版本符合以下要求：SNMPv3、SSH V2、SSL3.0、TLS1.0 及以上版本。
注：SSH協議爲1.99表示同時支持V1和V2，產品需默認使用V2
3. 使用帶服務器端證書的 SSL 傳遞敏感數據
tips：
只提供本地接入或本地登錄，用來做設備管理使用的場景可以不測，windows嗅探工具使用Wireshark，Suse使用tcpdump， solaris使用snoop。
1、啓動Wireshark進行嗅探；
2、訪問操作員登錄頁面，輸入用戶名和口令進行登錄；
3、查看Wireshark的嗅探記錄，選擇目的IP爲服務器IP）的記錄，右鍵並點擊“Follow TCP Stream”，檢查是否能夠看到明文的口令/密碼。
4. 禁止在 URL 中攜帶會話標識
由於瀏覽器會保存 URL 歷史記錄，如果 URL 中攜帶會話標識，則在多人共用的 PC 上會話標識容易被其他人看到，一旦該會話標識還在其生命有效期，則惡意用戶可以冒充受害用戶訪問 Web 應用系統。
5. 對銀行賬號等敏感數據的訪問要有認證、授權和加密機制。（引入階段：設計）
九. 隱私保護（引入階段：設計和開發）
1. 個人數據過濾或匿名化處理
tips：
1.檢查系統是否存在非正常業務流程之外的出於於測試、維護、定位目的的採集並存儲個人數據、導出個人數據的場景
場景包含不限於：日誌、消息跟蹤、導出工具、維護工具、維護界面、過程文件等
2.檢查這些個人數據採集和處理模塊是否有安全保護機制：
（1）調用這些功能是否需要先通過認證：web管理和接口通過認證，腳本工具通過權限控制，其他場景根據實際情況分析
（2）是否有日誌記錄這些功能的調用處理過程；
（3）web管理和接口：不具備調用權限的普通用戶是否能非法調用這些功能；腳本工具至少-非同組用戶不可讀寫和執行
3.檢查個人數據存儲是否有安全保護機制：
（1）物理/內存數據庫：用戶認證授權
（2）文件：權限控制根據業務需求，如果同組用戶必須讀取也可以容許，至少保證其他用戶無法讀取；
（3）其他形式：根據產品實際情況分析保護機制
4.檢查個人數據需要導出客戶網絡時有匿名化機制
2. 個人數據處理功能公開
tips：
滿足以下條件之一：
1、系統不存在涉及個人數據的採集/處理的功能。
2、允許產品正常業務（建立通信連接及計費）的需要，採集、處理、存儲個人數據，但必須提供必要的安全保護機制，導出客戶網絡有匿名化機制，以防止個人數據被泄漏、丟失、破壞。
必須在產品CPI（客戶資料）中對產品涉及用戶隱私的功能進行描述和聲明：
- 描述：該功能處理用戶個人數據的目的、範圍、處理方式、時限
- 聲明：要求客戶使用該功能時遵從當地適用的法律法規。
十. 加密解密
1. 禁止使用沒有專利的安全標準加密算法（引入階段：設計和開發）
tips：
已經被證明不再安全的公開加密算法包括：DES、RC2、MD5、SHA1、HMAC-MD5、HMAC-SHA1；
對稱加密算法建議使用：AES；
密鑰交換算法建議使用：DH；
數字簽名算法建議使用：DSA、ECDSA；
非對稱算法建議使用：ECC、RSA；
HASH（哈希）算法建議使用：SHA；
HMAC（基於哈希的消息驗證碼）算法建議使用：HMAC-SHA；
建議的各算法建議採用如下的加密強度：
| 加密算法 | 最小強度 | 建議的默認強度 | 要求更高強度時建議的 |
| AES | 128 | 128 | 192、256 |
| DH | 1024 | 1024 | 2048 |
| DSA | 1024 | 1024 | 1024 |
| ECC | 192 | 192 | 216 |
| ECDSA | 192 | 192 | 216 |
| RSA | 1024 | 1024 | 2048 |
| SHA | 224 | 256 | 384、512 |
| HMAC | HMAC-SHA224 | HMAC-SHA256 | HMAC-SHA384、HMAC-SHA512 |
*注：如需要與第三方系統對接或兼容老系統，產品不得不使用不安全密碼算法時，應在產品CPI資料中提示風險。
2. 禁止寫死傳輸密鑰（引入階段：設計和開發）
測試方法：
1根據對系統所有接口得了解，分析那些接口涉及敏感數據密文傳輸（或者結合紅線條目“口令加密存儲”“禁止私有算法”用例一起測試：檢查產品數據庫、配置文件、內存、腳本等中所有加密場景（口令加密、文件加密等）梳理該場景是：僅用於本地加密還是用於敏感數據加密傳輸。），檢查用於敏感數據加密傳輸的算法之密鑰是否可配置
2.檢查代碼中密鑰敏感字符串（key、sharekey、encrypt、enc、dec、decrypt等）。
並結合開發人員人工訪談&分析，並且確認初始密鑰是否使用工具生成。
預期結果：
用於敏感數據加密傳輸的密鑰，禁止硬編碼在代碼中，需要加密保存在配置文件或者數據庫中。
3. 密鑰不能明文存儲
十一. 業務安全
1. 不使用不安全的服務和協議
系統的管理功能和近端維護終端、網管維護終端間，支持使用合適的安全協議（如SSH v2/TLS1.0/SSL3.0/IPSec/SFTP/ SNMPv3等）；支持關閉不安全協議（FTP、Telnet）。
tips：
1、參考被測系統的設計文檔或者登陸被測操作系統，檢查是否使用Telnet、FTP、NFS、Samba、RPC、TFTP、r 服務、Netbios、X-Windows、Snmp V1.0/V2.0 等不安全的服務和協議：
a.Telnet、FTP、TFTP、NFS、r 服務(rlogin/rsh等)：SUSE使用chkconfig命令，AIX使用lssrc -a命令
b.SUSE和AIX：X-Windows：netstat -an|grep 端口是否開啓(注：請查看/etc/services中X Window System對應實際端口)
c.Netbios：cmd--->nbtstat -A 被測服務器ip或者cat /etc/services查看該服務監聽的端口是否開啓）
d.Samba：SUSE上對應SMB、NMB服務
e.檢查通信矩陣中是否含以上服務
2、如果存在則關閉這些服務和協議，觀察被測系統是否仍正常運行。
注：支持多操作系統的都要測試
2. 跨站請求僞造防範：
對於B/S應用：
1、檢查系統是否有“自動登錄/記住我”功能
2、檢查重要的管理事務或重要的交易事務如充值、餘額
、添加用戶、開啓業務等，是否有二次認證
3、檢查重要的管理事務或重要的交易事務如充值、餘額
、添加用戶、開啓業務等，按要求輸入相應的數據，並提交；通過burpsuite攔截請求，查看整個交互過程中（有可能一個操作涉及多個步驟）客戶端提交參數是否包含隨機信息或者動態口令、驗證碼的信息。
3. 管理功能和業務功能相互獨立部署
十二. 協議與接口防攻擊
1. 關閉非必須的端口：
tips：
1.登錄被測主機通過如下命令掃描端口
tcp端口掃描：
netstat -an|grep tcp(WINDOWS使用 netstat -an|findstr "TCP")
udp端口掃描:
netstat -an|grep udp(WINDOWS使用 netstat -an|findstr "UDP")
或者通過Nmap對各服務器進行端口掃描：
tcp端口掃描：
Nmap -P0 -sS -n -p 1-65535 -oX tcp.xml -sV 服務器IP
udp端口掃描:
Nmap -P0 -sU -n -p 1-65535 -oX udp.xml -sV
服務器IP
SCTP掃描：
nmap -sY -scan_delay 250 -p 1-65535 -v -n -oX SCTP.xml 服務器IP
2.排查系統是否涉及以下單機測試環境不能測試的端口-如果可被NMAP掃描出的話也需要公開：
使用find . -name "*" | xargs grep -i "port"命令搜索服務器上由於業務特性未開啓暫未啓動的端口
如果系統涉及集羣則檢查數據庫RAC雙機端口、雙機管理軟件端口、集羣軟件端口
如若產品還集成別的第三方組件端口也需要公開
3.確認每個端口的使用場景
4.將步驟一、二中端口與通信舉證文檔對比
備註：Linux環境下使用nmap掃描UDP端口時間過長，可以通過如下操作解決：
echo "0" > /proc/sys/net/ipv4/icmp_ratemask
5 關於通訊矩陣
1） 通訊矩陣Authentication Mode列檢查：安全域最低需要IP認證，如果在跨安全域需要安全認證方式，標準的協議不支持認證需要說明。
2） 通訊矩陣目的端口（監聽）列檢查：同一目的端口在所屬平面列既是管理平面又是業務平面不行
3） lsof -i -n|egrep 'COMMAND|LISTEN' 掃描運行環境，*:port和0.0.0.0:port均代表端口所有IP監聽，需要安全理由。
2. 管理訪問接入認證要求
管理通信端口測試步驟：
預置條件：產品通信矩陣描述正確
1、梳理通信矩陣文檔中：所有平面中涉及的可以對系統或系統數據進行管理（增刪改）的端口
2、剔除協議標準定義中無認證機制的
3.檢查管理端口是否有接入認證機制
管理通信協議測試步驟：
1.根據產品描述or其他設計文檔，梳理產品內部接口/對外接口中屬於可以對系統或系統數據進行管理（增刪改）的接口協議
2.檢查管接口協議是否有接入認證機制
注：口令認證是最小的接入認證機制
常見的非標準協議或者產品需要定製開發接口的管理端口和協議舉例：MML、SOAP、HTTP/HTTPS、本公司自研協議管理訪問接入認證要求
3. 近端訪問認證要求(設備外部可見的能對系統進行管理的物理接口必須有接入認證機制。)
tips：1、檢查設備是否存在能對系統進行管理的物理接口（如串口、USB接口、管理網口等）；
2、如果存在，檢查這些物理接口是否是外部可見的；
3、如果外部可見，訪問這些接口，檢查是否有接入認證機制；
4. 協議畸形報文攻擊測試（健壯性測試，Codenomicon）
十三. 安全日誌
1. 對安全事件及操作事件記錄日誌
tips：1、分別進行以下操作：
1、登錄和註銷；
2、增加、刪除用戶和用戶屬性（帳號、口令等）的變更；
3、用戶的鎖定和解鎖（管理員解鎖和自動解鎖），禁用和恢復；
4、角色權限變更；
5、系統相關安全配置（如安全日誌內容配置）的變更；
6、重要資源的變更，如某個重要文件的刪除、修改;對系統配置參數的修改；
對系統進行啓動、關閉、重啓、暫停、恢復、倒換；
對業務的加載、卸載；
軟件的升級操作，包括遠程升級和本地升級；
對重要業務數據（特別是與財務相關的數據，包括：卡號、餘額、話單、費率、費用、訂單、出貨、帳單等）的創建、刪除、修改；
所有帳戶的命令行操作命令。
2、檢查系統是否對以上所有操作記錄相應的日誌記錄,包括用戶ID(包括關聯終端、端口、網絡地址或通信設備）、時間、事件類型、被訪問資源的名稱、訪問結果等。
注:根據實際情況，分別測試以上活動中成功和失敗的場景
十四. Web安全開發
1. 輸入校驗：
tips：1、必須對所有用戶產生的輸入進行校驗，一旦數據不合法，應該告知用戶輸入非法並且建議用戶糾正輸入。
說明：用戶產生的輸入是指來自 text、password 或 textareas 表單域的數據；必須假定所有用戶產生的輸入都是不可信的，並對它們進行合法性校驗。
2、必須對所有服務器產生的輸入進行校驗。
說明：服務器產生的輸入是指除用戶產生的輸入以外的輸入，例如來自 hidden fields、selection boxes、check boxes、radio buttons、cookies、HTTP headers、熱點鏈接包含的 UR L參數的數據或客戶端腳本等；必須假定所有服務器產生的輸入都是被篡改過的、惡意的，並對它們進行合法性校驗，如果不合法，說明有人惡意篡改數據。舉例：假如用戶資料填寫表單中的“性別”爲必填項，用 radio button（‘男’和‘女’對應實際值分別爲‘1’和‘0’）來限制用戶的輸入，如果應用程序收到的“性別”值爲‘2’，那麼可以斷定有人惡意篡改數據。
3、不能依賴於客戶端校驗，必須使用服務端代碼對輸入數據進行最終校驗。
說明：客戶端的校驗只能作爲輔助手段，減少客戶端和服務端的信息交互次數。
4、禁止未經嚴格輸入校驗、直接使用客戶端提交的參數動態構建xpath語句。
2. 防止SQL注入：百度百科裏有詳細的解釋，這裏偷個懶，就不多說了。
3. 文件上傳限制：防止攻擊者上傳JSP、PHP等獲取WebShell控制服務器。
4. 上傳、下載路徑限制：
建議對寫/上傳文件的路徑或文件名採用隨機方式生成，或將寫/上傳文件放置在有適當訪問許可的專門目錄。對讀/下載文件採用映射表（例如，用戶提交的讀文件參數爲1，則讀取file1，參數爲2，則讀取file2）。防止惡意用戶構造路徑和文件名，實施目錄跨越攻擊。
5. web可訪問的文件約束
禁止將敏感文件（如日誌文件、配置文件、數據庫文件等）存放在Web內容目錄下。
說明：Web內容目錄指的是：通過Web可以直接瀏覽、訪問的目錄，存放在Web內容目錄下的文件容易被攻擊者直接下載。應該放到Web瀏覽不到的目錄（如：WEB-INF）。
6. 刪除調試代碼
歸檔的程序文件中禁止保留調試用的代碼。
說明：這裏的“調試用的代碼”是指開發過程中進行臨時調試所用的、在Web應用運行過程中不需要使用到的Web頁面代碼或servlet代碼。例如：在代碼開發過程中爲了測試一個添加帳號的功能，開發人員臨時編寫了一個JSP頁面進行測試，那麼在歸檔時，該JSP頁面必須刪除，以免被攻擊者利用。
十五. Webservice安全
1. 對 Web Service 接口的調用要進行認證
認證就是確定誰在調用 Web Service，並且證實調用者身份。可以用WSDigger，是一款開源免費的工具。不過有些應用用不了...，如果大家有更好的辦法、請賜教^_^
2. 對 Web Service 提交的參數進行輸入校驗
十五. DWR安全防護
1. 關閉DWR 調試功能
tips：
1、在被測應用所在服務器上檢查是否應用到dwr：
find ./ -name "dwr.*"
如果存在dwr.xml和dwr.jar兩個文件，則說明應用存在DWR，進行下一步
2、 檢查對應的web.xml有沒有如下配置，如果有則表明網站肯定使用了DWR，再執行步驟3
<servlet-name>dwr-invoker</servlet-name>
3、檢查該web.xml中dwr對應debug值是否爲false：
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
2. 對DWR接口的調用必須進行認證，對DWR提交的參數進行輸入校驗，對DWR接口的調用必須進行鑑權（無法越級訪問）
很遺憾，市面上沒發現有專門針對dwr接口的測試工具；公司內部使用的東西還不讓外泄...
*至此，應用安全測試部分結束。接下來準備一下、開始寫《軟件安全測試之系統安全測試》