數百次滲透測試得出的五條經驗

Web應用是攻擊者成功入侵的首選路徑。Verizon《2022年數據泄露調查報告》揭示，大約70%的數據泄露走的是Web應用路線。

經由300多次Web應用滲透測試之后，Web應用為何是數據泄露最大通途的原因顯露了出來。開發人員一直在犯同樣的安全錯誤，導致漏洞層出不窮。他們往往不使用安全框架，試圖自行編寫安全代碼和身份驗證過程。

有必要指出的是，開發人員承受著將產品快速推向市場的巨大壓力。他們的績效取決于能盡快引入多少功能，而不是能盡可能安全地引入多少功能。這就導致了在安全方面走捷徑，最終在Web應用中留下漏洞的情況。

夯實應用安全的五條經驗

滲透測試人員充當了唱反調的角色，逆向工程應用開發人員創建的東西，顯示攻擊者可以從什么地方以何種方式侵入。滲透測試的結果往往能凸顯出常見的基本錯誤。軟件開發公司可以汲取以下五條經驗，學習如何讓自己的應用更加安全。

1、攻擊者仍然在利用跨站腳本（XSS）。跨站腳本一直都是攻擊者鐘愛的Web應用漏洞。2021年，由于應用開發框架的改進，跨站腳本掉出了開放式Web應用程序安全項目（OWASP）十大漏洞榜單，但仍現身于幾乎每次滲透測試中。

跨站腳本常被認為是低風險的，但也可能引發嚴重風險，比如賬戶接管、數據盜竊和對應用基礎設施的全面破壞。很多開發人員覺得使用成熟的輸入驗證庫并設置恰當的HttpOnly cookie屬性就夠了，但只要用到自定義代碼，就難免出現跨站腳本漏洞。以WordPress站點為例，針對管理員的跨站腳本攻擊就很嚴重，因為拿到此類憑證的用戶可以加載插件，從而在服務器上執行類似代碼的惡意攻擊載荷。

2、自動掃描器不夠深入。如果只用自動化工具掃描Web應用，漏洞很有可能躲過掃描。這類工具采用模糊測試方法，通過向系統注入格式錯誤的數據檢測漏洞，但這種技術可能會產生誤報。

掃描器通常跟不上現代Web開發的速度，針對JavaScript單頁應用、WebAssembly和Graph的掃描結果并不理想。復雜漏洞需要人工精心編制的載荷加以驗證，降低了自動化工具的效率。

必須有人參與才能最為準確細致地分析漏洞和漏洞利用程序，但這些掃描器可以作為快速發現簡單漏洞的補充資源加以利用。

3、自研身份驗證通常太弱了。身份驗證是保護Web應用安全的基礎。試圖創建自己的密碼重置工作流時，開發人員往往沒有用最安全的方式實現。

滲透測試人員常能獲取到其他用戶的信息，或者入手超出自身角色的過多權限。這造成了橫向和縱向訪問控制問題，讓攻擊者得以鎖定用戶賬戶或者破壞應用。

身份驗證最終歸結于這些協議都是怎么實現的。例如，安全聲明標記語言（SAML）身份驗證就是個日漸流行的單點登錄協議，可以提高安全性，但如果未能正確實現，那引入的漏洞可能比堵上的更多。

4、攻擊者瞄準業務邏輯中的缺陷。開發人員檢查各種功能，確定自己是否滿足了客戶的用例。但他們通常不會換個角度看問題，不去確認攻擊者可能通過哪種方式惡意使用這些功能。

電子商務網站的購物車就是個很好的例子。該功能業務關鍵，但往往不夠安全，會產生嚴重的漏洞，例如在結賬時將總數清零、結賬后添加商品，或用其他SKU替換產品。

開發人員專注主要用例而未考慮到其他惡意用途無可指摘。他們的業績看的就是能不能提供所需功能。高管則要看到其他方面，知曉業務邏輯應關聯安全邏輯。具有極高業務價值的功能，如購物車或身份驗證工作流，可能就不適合交給初級開發人員。

5、良好滲透測試不存在“超出范圍”一說。取決于投入多少資源和資產，Web應用很快就會變得十分復雜。我們需要考慮到支持主應用功能的后端API服務器。

有必要讓執行滲透測試的安全審計人員知道所有這些外部資產，了解這些資產如何連接哪些應用。開發人員可能會認為這些資產在“范圍之外”，因而自己無需對此負責，但攻擊者才不會管什么范圍不范圍的。正如滲透測試所顯示的，沒有什么東西是“超出范圍”的。

平衡問題

如果能夠事先了解一些此類常見風險，軟件開發公司就能更好地與安全審計人員溝通，讓滲透測試不那么痛苦。沒有哪家公司會想阻礙開發人員，但在創造力和安全框架之間取得平衡，開發人員就能知道哪些地方可以自由發揮，而哪些地方需要遵從應用程序安全指南。