2019年測試指南-源碼審查&滲透測試&平衡方法的必要性

源代碼審查

---

概述
源代碼審查是手動檢查Web應用程序源代碼以解決安全問題的過程。任何其餘形式的分析或測試都沒法檢測到許多嚴重的安全漏洞。正如流行的說法「若是你想知道真正發生了什麼，請直接找到源代碼。」幾乎全部安全專家都認爲實際查看代碼沒有任何替代品。全部用於識別安全問題的信息都在代碼在某處。與測試第三方封閉式軟件（如操做系統）不一樣，在測試Web應用程序時（特別是若是它們是在內部開發的），源代碼應該可用於測試目的。

許多無心但重要的安全問題也很難經過其餘形式的分析或測試發現，例如滲透測試，使源代碼分析成爲技術測試的首選技術。使用源代碼，測試人員能夠準確地肯定發生了什麼（或者應該發生什麼）並刪除黑盒測試的猜想工做。

經過源代碼審查特別有利於發現的問題示例包括併發問題，有缺陷的業務邏輯，訪問控制問題，加密弱點以及後門，特洛伊木馬，復活節彩蛋，定時炸彈，邏輯炸彈和其餘形式的惡意碼。這些問題一般表現爲網站中最有害的漏洞。源代碼分析也能夠很是有效地查找實現問題，例如未執行輸入驗證的位置或可能存在失效打開控制過程的位置。但請記住，操做過程也須要進行審覈，由於部署的源代碼可能與此處分析的源代碼不一樣[13]。

好處：

• 完整性和有效性

• 準確性

• 快速（適合有能力的評審員）

缺點：

• 須要高技能的安全開發人員

• 可能會錯過編譯庫中的問題

• 沒法輕鬆檢測到運行時錯誤

• 實際部署的源代碼可能與正在分析的源代碼不一樣

滲透測試

---

概述
多年來，滲透測試一直是用於測試網絡安全性的經常使用技術。它一般也被稱爲黑盒測試或道德黑客攻擊。滲透測試本質上是遠程測試正在運行的應用程序以查找安全漏洞的「藝術」，而不瞭解應用程序自己的內部工做原理。一般，滲透測試團隊能夠像訪問用戶同樣訪問應用程序。測試人員就像攻擊者同樣，試圖查找和利用漏洞。在許多狀況下，測試人員將得到系統上的有效賬戶。

雖然滲透測試已被證實在網絡安全性方面是有效的，但該技術並不能天然地轉化爲應用程序。在網絡和操做系統上執行滲透測試時，大部分工做涉及查找並利用特定技術中的已知漏洞。因爲Web應用程序幾乎徹底是定製的，所以Web應用程序領域的滲透測試更相似於純粹的研究。已經開發了滲透測試工具來自動化該過程，可是因爲Web應用程序的性質，它們的有效性一般不好。

今天許多人使用Web應用程序滲透測試做爲其主要的安全測試技術。雖然它確實在測試程序中佔有一席之地，但咱們認爲它不該被視爲主要或惟一的測試技術。加里麥格勞[14]總結了滲透測試，他說，「若是你沒有經過滲透測試，你知道你確實有一個很是糟糕的問題。若是你經過滲透測試，你不知道你沒有一個很是糟糕的問題「。可是，有針對性的滲透測試（即嘗試利用先前評論中檢測到的已知漏洞的測試）可用於檢測網站上部署的源代碼中是否實際修復了某些特定漏洞。

好處：

• 能夠快速（所以便宜）

• 須要比源代碼審查相對較低的技能

• 測試實際暴露的代碼

缺點：

• 在SDLC中太晚了

• 僅限正面碰撞測試。

平衡方法的必要性

因爲有許多技術和方法來測試Web應用程序的安全性，所以很難理解使用哪一種技術以及什麼時候使用它們。經驗代表，對於究竟應該使用哪一種技術來構建測試框架的問題，沒有正確或錯誤的答案。實際上，全部技術都應該用於測試全部須要測試的區域。

雖然很明顯沒有單一的技術能夠有效地覆蓋全部安全測試並確保全部問題都獲得解決，但許多公司只採用了一種方法。歷史上使用的方法是滲透測試。滲透測試雖然有用，但沒法有效解決許多須要測試的問題。在軟件開發生命週期（SDLC）中，它只是「太晚了」。

正確的方法是一種平衡的方法，包括從手動審查到技術測試的幾種技術。平衡的方法應涵蓋SDLC全部階段的測試。該方法利用了最合適的技術，具體取決於當前的SDLC階段。

固然，有時候和狀況下只有一種技術是可能的。例如，對已建立的Web應用程序進行測試，但測試方沒法訪問源代碼。在這種狀況下，滲透測試顯然比沒有測試好。可是，應鼓勵測試方質疑假設，例如沒法訪問源代碼，並探索更完整測試的可能性。

平衡的方法取決於許多因素，例如測試過程的成熟度和企業文化。建議平衡測試框架應該相似於圖3和圖4中所示的表示。下圖顯示了覆蓋軟件開發生命週期的典型比例表示。爲了與研究和經驗保持一致，公司必須更加劇視發展的早期階段。