一、滲透測試是什么
滲透測試(PenetrationTest)是對安全情況最客觀、最直接的評估方式，主要是模擬黑客的攻擊方法對系統和網絡進行非破壞性質的攻擊性測試，在保證整個滲透測試過程都在可以控制和調整的范圍之內盡可能的獲取目標信息系統的管理權限以及敏感信息，並將入侵的過程和細節產生報告給用戶，由此證實用戶系統所存在的安全威脅和風險，並能及時提醒安全管理員完善安全策略。
滲透測試是工具掃描和人工評估的重要補充。工具掃描具有很好的效率和速度，但是存在一定的誤報率，不能發現高層次、復雜的安全問題；滲透測試需要投入的人力資源較大、對測試者的專業技能要求很高（滲透測試報告的價值直接依賴於測試者的專業技能），但是非常准確，可以發現邏輯性更強、更深層次的弱點。
二、滲透測試的流程
三、滲透測試內容
《代碼層安全》
應用程序及代碼在開發過程中，由於開發者缺乏安全意識，疏忽大意極為容易導致應用系統存在可利用的安全漏洞。一般包括SQL注入漏洞、跨站腳本漏洞、上傳漏洞、CSRF跨站請求偽造漏洞等。
1) SQL注入漏洞
SQL注入漏洞的產生原因是網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，導致應用程序存在安全隱患。SQL注入漏洞攻擊就是利用現有應用程序沒有對用戶輸入數據的合法性進行判斷，將惡意的SQL命令注入到后台數據庫引擎執行的黑客攻擊手段。
2) 跨站腳本漏洞
跨站腳本攻擊簡稱為XSS又叫CSS (Cross Site Script Execution)，是指服務器端的CGI程序沒有對用戶提交的變量中的HTML代碼進行有效的過濾或轉換，允許攻擊者往WEB頁面里插入對終端用戶造成影響或損失的HTML代碼。
3) 會話管理漏洞
會話管理主要是針對需授權的登錄過程的一種管理方式，以用戶密碼驗證為常見方式，通過對敏感用戶登錄區域的驗證，可有效校驗系統授權的安全性，測試包含以下部分：
4) 用戶口令易猜解
通過對表單認證、HTTP認證等方式的簡單口令嘗試，以驗證存在用戶身份校驗的登錄入口是否存在易猜解的用戶名和密碼
5) 是否存在驗證碼防護
驗證碼是有效防止暴力破解的一種安全機制，通過對各登錄入口的檢查，以確認是否存在該保護機制
6) 是否存在易暴露的管理登錄地址
某些管理地址雖無外部鏈接可介入，但由於采用了容易猜解的地址（如：admin）而導致登錄入口暴露，從而給外部惡意用戶提供了可乘之機
7) 是否提供了不恰當的驗證錯誤信息
某些驗證程序返回錯誤信息過於友好，如：當用戶名與密碼均錯誤的時候，驗證程序返回“用戶名不存在”等類似的信息，通過對這一信息的判斷，並結合HTTP Fuzzing工具便可輕易枚舉系統中存在的用戶名，從而為破解提供了機會。
會話管理主要是針對驗證通過之后，服務端程序對已建立的、且經過驗證的會話的處理方式是否安全，一般會從以下幾個角度檢測會話管理的安全性：
8) Session是否隨機
Session作為驗證用戶身份信息的一個重要字符串，其隨機性是避免外部惡意用戶構造Session的一個重要安全保護機制，通過抓包分析Session中隨機字符串的長度及其形成規律，可對Session隨機性進行驗證，以此來確認其安全性。
9) 校驗前后Session是否變更
通過身份校驗的用戶所持有的Session應與其在經過身份驗證之前所持有的Session不同
10) 會話儲存是否安全
會話存儲是存儲於客戶端本地（以cookie的形式存儲）還是存儲於服務端（以Session的形式存儲），同時檢測其存儲內容是否經過必要的加密，以防止敏感信息泄露
11) 不安全的對象引用
不安全的對象引用是指程序在調用對象的時候未對該對象的有效性、安全性進行必要的校驗，如：某些下載程序會以文件名作為下載程序的參數傳遞，而在傳遞后程序未對該參數的有效性和安全性進行檢驗，而直接按傳遞的文件名來下載文件，這就可能造成惡意用戶通過構造敏感文件名而達成下載服務端敏感文件的目的。
12) 跨站請求偽造
跨站請求偽造（Cross-site request forgery，縮寫為CSRF），也被稱成為“one click attack”或者session riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性。
《應用層安全》
由於應用系統和數據庫系統開發配置的具體過程中，可能由於管理員缺乏安全意識或疏忽大意導致應用層存在安全隱患。
1) 弱口令
弱口令通常有以下幾種情況：用戶名和密碼是系統默認、口令長度過短、口令選擇與本身特征相關等。系統、應用程序、數據庫存在弱口令可以導致入侵者直接得到系統權限、修改盜取數據庫中敏感數據、任意篡改頁面等。
2) 敏感信息泄露
敏感信息泄露漏洞指泄露有關WEB應用系統的信息，例如，用戶名、物理路徑、目錄列表和軟件版本。盡管泄露的這些信息可能不重要，然而當這些信息聯系到其他漏洞或錯誤設置時，可能產生嚴重的后果。例如：某源代碼泄露了SQL服務器系統管理員賬號和密碼，且SQL服務器端口能被攻擊者訪問，則密碼可被攻擊者用來登錄SQL服務器，從而訪問數據或運行系統命令。
3) 安全配置錯誤
某些HTTP應用程序，或第三方插件，在使用過程中由於管理人員或開發人員的疏忽，可能未對這些程序或插件進行必要的安全配置和修改，這就很容易導致敏感信息的泄露。而對於某些第三方插件來說，如果存在安全隱患，更有可能對服務器獲得部分控制權限。
4) 鏈接地址重定向
重定向就是通過各種的方法將各種網絡請求重新定個方向轉到其它位置（如：網頁重定向、域名的重定向、路由選擇的變化也是對數據報文經由路徑的一種重定向）。
而某些程序在重定向的跳轉過程中，對重定向的地址未進行必要的有效性和安全性檢查，且該重定向地址又很容易被惡意用戶控制和修改，這就可能導致在重定向發生時，用戶會被定向至惡意用戶事先構造好的頁面或其他URL，而導致用戶信息受損。
《移動安全》
| 測試類型 |
測試項 |
測試項描述 |
| 安裝包 |
反編譯 |
測試app安裝文件是否能被反編譯 |
| 重打包 |
測試app安裝文件是否能被重打包並簽名發布 |
|
| 本地存儲 |
內存修改 |
測試app內存是否可被修改，比如修改內存中的金額 |
| 明文存儲 |
測試app是否在本地明文存儲敏感文件，如：帳號、協議結構等 |
|
| 數據傳輸 |
封包篡改 |
測試app數據包被攔截下來后修改內容重新發送，服務端是否能識別 |
| 封包重放 |
測試app數據包被攔截下來后重復發送，服務端是否能識別 |
|
| 業務相關 |
驗證碼繞過 |
測試app的驗證碼是否能被繞過 |
| 暴力破解 |
測試app的登錄口是否能進行暴力破解、撞庫攻擊。 |
|
| 訂單篡改 |
測試app的訂單是否能被篡改，比如：訂單被新增、修改、刪除等。 |
|
| 訂單重放 |
測試app的訂單是否能被重放，比如：轉帳訂單數據包重新提交，是否能再一次轉帳。 |
|
| 邏輯安全 |
測試app是否存在邏輯上的安全漏洞，比如：付款金額為負數，實際上不但沒有扣款，反而給買家增加了余額。 |
|
| 自我保護 |
完整性校驗 |
測試app相關組件是否能被篡改，有無完整性校驗機制。 |
| 動態調試 |
測試app能否被IDA等工具動態調試；有無加殼保護 |
|
| 軟件源替換 |
測試app更新源是否可被替換，比如：修改hosts文件將域名定位到指定IP；修改升級文件為自定義文件。 |
|
| 鍵盤記錄 |
測試app密碼是否能被鍵盤記錄工具明文記錄 |
|
| 服務端安全 |
web安全 |
測試app服務端是否存在web安全漏洞 |
| 接口安全 |
測試app連接的接口是否存在安全漏洞 |