網絡安全 api 網絡安全 ast技術

隨著應用或者API被攻擊利用已經越來越多，雖然來自開源組件的漏洞加劇了這一現象的發生，但是，其實主要還是在于應用程序或者API本身沒有做好防范，根源在于源代碼本身的質量沒有嚴格把控。AST是指Application Security Testing，主要包括靜態應用測試（SAST）、交互式應用測試（IAST）、動態應用測試（DAST）以及軟件成分分析（SCA）等工具。

應用測試工具AST是專門用于檢測源代碼安全問題的工具，如何有效地將AST工具應用于開發過程中，也是一個比較有挑戰的事情。

將AST工具集成在SDLC中自然是一個比較常用的好方法，可以在開發的過程中盡早地發現代碼中的問題，及時解決，降低又問題帶來的可能的攻擊和損失。這也就是“安全左移”所說的“將安全盡早地應用開發過程的開始階段，不僅僅是在后期測試才開始關注安全”，因為早發現的代價小，影響小，成本也最低。

“安全左移”概念很好，關鍵是要知道什么時候以及如何融入到SDLC過程中，AST啟用的頻率是多少。特別是敏捷開發和DevOps盛行的年代，SAST工具如何能夠自動地集成到流程中至關重要。

根據Gartner的“How to Deploy and Perform Application Security Testing”建議將AST應用到開發階段測試、發布前測試以及產品線測試。在產品開發和發布之前的開發過程中，在build pipeline之中發起SAST與SCA檢測，在產品上線之前，使用IAST/DAST檢測，在產品上線之后，可以使用DAST測試。這樣可以保證應用在部署和使用過程中，是經過充分測試的。當然這里也并不是說非常嚴格地每一段只能做某個一測試，在發布之前，也可以啟用SAST或者SCA看看發布的包的質量到底如何，作為是否可以發布的一個參考，效果會更好。有的產品可以掃描二進制文件，在產品上線之后，也可以定期掃描一下運行產品部署包的安全質量狀態。

在開發過程中，如何有效地利用SAST和SCA也是一個挑戰。使用IDE中的插件，在開發寫代碼時實時檢測，可以在第一時間發現有問題的代碼，及時修復，代價也最低。但是，當開發人員很多的時候，同時提交的代碼比較多，而SAST和SCA的掃描又比較耗資源和時間，當請求超過SAST和SCA的服務器所能承受限度時，就會出現排隊的現象，導致耗時比較長，影響開發效率，即使SAST支持增量開發，有時排隊也會比較長。所以，掃描的頻率太頻繁，也未必是一件好事。

在發布前的測試，可以考慮內部安全團隊使用IAST工具或者DAST工具測試，也可以考慮使用第三方的團隊測試。工具方面，目前還沒有什么特別好的自動化DAST，一般的DAST的測試時間會比較長，對于敏捷開發和DEVOPS而言，有點不適應。使用第三方團隊的好處是他們可以從不同角度來分析系統，能夠發現內部團隊的盲點。雖然有自動化測試工具，這個階段的測試可能更加依賴手工操作，由于發現的問題可能會影響產品的發布，需要建立一個處理嚴重安全問題的機制或者流程，保證在遇到嚴重的安全問題時，各方針對它的處理流程都沒有異議。發布前的測試結果，需要設置一個安全閾值，當某級別的安全問題超過多少時，或者含有某個級別的安全問題時，是不允許發布的，如果緊急需要發布，這就需要一個批準流程，然后，需要考慮后期的如何及時打上補丁。安全閾值的設置很關鍵，必須放到產品的發布標準里，讓每個團隊都了解產品發布的標準。

產品上線之后的測試，就需要注意，因為畢竟產品線已經在運行，在使用DAST工具從監測時，有些測試用例會比較影響產品的正常運行，就需要界定范圍哪些操作是不能做的，特別是注入問題像SQL注入，它有可能會篡改數據庫中的數據，甚至可能刪除數據庫中的數據，導致DOS，現實中就曾有測試人員使用DAST自動化掃描客戶的產品環境，導致產品環境被掃描掛了，最終項目沒有完成，還賠了不少錢。但是，DAST工具可以檢測像XSS這種攻擊，一般都不會導致什么嚴重的問題。產品線上的測試就不能真刀實槍地進行，而是像武林高手比武一樣，要點到為止，使用自動化工具時，就需要設置一下掃描的規則集，防止可能嚴重影響產品環境測試用例。測試時也需要關注在前期階段已經發現的問題是否有可能再次出現。為了以防萬一DAST工具會對產品環境造成影響，建議使用一般的賬號進行DAST測試，而不是使用admin或者權限比較高的用戶進行測試。由此可見，在產品上線之后，再想挖掘問題和修復問題，就需要小心謹慎，而且代價也大。

根據前期階段測試發現的安全問題，進行總結，在結合產品運行環境的防護設備WAF、WAAP或者RASP，修訂這些工具的規則，讓他們可有效地識別前期測試發現的安全問題的類型并且及時阻止相關的攻擊，可以更好地提高產品的防護能力。

由于現在大多數都是用云環境或者數據中心，而且使用微服務部署，一臺機器可能部署多個服務。為了保證所有的產品和服務都在管理和監控的列表里，要有工具經常掃描環境中的資產，防止有些服務在沒有經過嚴格的流程控制就直接部署到產品環境中去。

AST可以有效地提高應用程序自身的安全，不應該是獨立的活動，應該很好地融入到開發流程之中，需要長期跟蹤與改進，讓它能夠長期地高效地融入到流程。

對于一些沒有辦法將“安全左移的產品”，包括遺留系統和外包系統的處理也需要慎重，因為任何一個疏忽都可能被攻擊者利用。遺留系統由于時間長久，使用的技術可能都是比較老的技術和語言，如果有源代碼而且購買的SAST支持這種語言，可以優先考慮使用SAST工具先掃描看一下結果，了解產品的大概的安全狀況。對于Web系統而言，需要針對防護設備WAF等針對遺留系統也要設置好規則，加強防護。對遺留系統而言，可能使用DAST就不太合適，因為遺留系統所能夠承擔的負載不夠大，很容易導致DOS，影響系統正常使用。針對對外的系統或者接口，需要重點人工測試。

當有些組織和單位將開發外包時，因為在開發過程中無法確保AST能夠比較嚴格地進行，就需要在驗收階段把好關卡。可以通過讓開發公司提供相關的報告來說明產品的質量，也需要在驗收時增加安全相關的測試指標，例如：使用SAST掃描發布的二進制包，看報告中的安全問題是否達到可接受的安全標準，這些都需要在外包時就把驗收標準定好。對于購買的商業軟件，也應該像外包軟件一樣對待。

工欲善其事必先利其器，要想推動AST，就必須要有合適的工具，自動化的工具關鍵的是如何誤報率和漏報率的問題，誤報率太高，會影響使用人對工具的使用積極性，漏報太多，又失去了使用工具的意義。自動化工具通常都是針對公共的框架或者開源組件進行定制，但是，針對組織內部使用的自定義的框架就不支持，這就需要工具能夠支持自定義規則的功能，通過自定義的規則可以有效地降低誤報和漏報。【關于如何選擇SAST可以參考：】簡單易懂是推動工具的重要前提，工具能夠提供比較容易懂的說明與解決方案也很重要。為了讓開發更容易理解安全問題的產生原理和如何修復，產品具備比較詳細的修復指導方案與說明，就非常重要，有的產品指導文檔比較難懂，就會導致用起來比較難，還需要人工準備相關材料進行培訓。

AST發現問題之后，如何有效地推動問題的解決是一個不小的挑戰。特別是在敏捷開發流行的時代，開發團隊都有各自的項目的進度安排，當安全問題出現時，他們改如何應對？如果在開發階段能夠實時發現并解決，就不存在這個問題，但是，如果在產品后期發現或者上線之后才發現，開發已經在開發新的版本時已經有了日常的工安排就會有沖突，而且安全問題的推動也需要開發學習一個新的技能，那就是如何正確地解決問題？這就需要一個機制來保證安全問題的推進。我們曾經采用過的方案是：讓每一個團隊都有一個人專門對接安全問題，并且在組織內部定義好這個人的職責，提供相關培訓，提高他的安全意識和知識。當一個項目有安全問題時，首先聯系這個負責人，把問題的來龍去脈講清楚，也提供相對應的解決方案供參考，讓他在團隊內部負責問題的推動與解決。此方案確實效果不錯，但是，有一個問題就是在人員流動比較大的公司，這個角色的人員可能流動比較大，需要及時維護好這個數據列表，同時，新的人進來，要能夠及時培訓到位【關于培訓，如果有在線培訓資料，就可以很好地讓新人自學，再加上定期的開會交流，就可以保證每個人的安全意識和知識，這有需要有人跟蹤與推薦。】，才能有效地推進。當然以項目的方式在公司內部統一推動某一種漏洞類型的整改，也是可以嘗試的，因為成立項目，就需要把每一個團隊里抽掉一個人員參與這個項目，可以統一調研正確的解決方案，也可以及時溝通解決問題中遇到難題。

有時一個安全問題的解決，更是一個挑戰，懂安全的人可能對產品的框架了解的不夠，而開發人員針對安全又了解的不夠徹底，因此一個問題的解決方案不能單純地依賴一些已知的公共的解決方案，需要開發和安全人員一起共同協商解決方案。針對有些框架的問題可以統一解決的，安全團隊和開發人員一起能夠提供一個可以共同使用的庫供所有團隊使用那是最好。不過，需要找到愿意配合的開發人員，或者找到能力比較強的安全人員可以搞定這個庫，這就對安全的人員要求比較高了，首先，安全知識必須過硬，充分與各個團隊溝通，開發出來的庫考慮到了一些可能；其次，必須有充足的開發知識，能夠了解公司的二方庫的開發與發布流程；最后，就是還需要各個團隊溝通協商，推動庫的使用以及后期問題跟蹤與解決。

為了有效地解決問題，就需要AST工具能夠具備bug跟蹤系統集成的能力，當AST工具發現問題可以自動將問題提交到bug系統跟蹤，開發只需要在bug系統一個地方跟蹤所有問題，可以減少開發團隊和安全團隊之間的隔閡。當然，在提交到bug系統之前，需要確保誤報的問題能夠很好地解決，在提交之前有一個審查并且根據審查的結果改進掃描規則，可以幫助降低誤報。例如，有些工具掃描之后，發現的問題處在一個初始狀態，當經過人的審查之后，將安全問題改為確認狀態，這時就可以將問題同步到Bug跟蹤系統，解決誤報的問題。自動化的腳本根據工具的SDK或者API將問題及時同步到Bug系統，就可以提高效率。

AST在研發過程中是必須要具備的，因為它可以達到以下幾點目標：

減少在線運行產品的漏洞數量；
在產品早期發現問題，降低解決漏洞的成本和帶來的風險；

最近，安全界又出現了Application Security Orchestration and Correlation（ASOC）工具，它是一個通過自動化工作流來簡化漏洞的測試與修復，它結合多種源頭的數據（SAST、IAST、DAST以及SCA等）來實現測試自動化。ASOC工具通過關聯和分析發現的問題來集中并優先考慮使用什么補救措施，它充當了應用開發和安全測試工具之間的管理層，大大提高漏洞修復的效率。

有時為了能夠主動發現產品上的安全問題，也可以啟用漏洞獎勵計劃，發起眾多安全愛好者幫助企業發現產品線上的問題。集思廣益，固然可以發現眾多問題。但是也要注意不同的人員的安全知識背景殘差不齊，提交的漏洞質量也很多，需要有人及時過濾。有時一些比較嚴重的問題的發現可能比較耗時，可能有些人會嘗試通過發現大量的低級別的漏洞來獲得獎勵。這種低級別的漏洞可能對系統不會造成什么直接的影響，但是數量一旦瞬間多了起來，內部團隊的應急響應的負擔就會重，反而可能會影響一些嚴重級別的漏洞響應時間。所以，在發布漏洞獎勵計劃時，最好能夠劃分一下大概的漏洞類型范圍，針對漏洞的嚴重級別和對應的獎勵有一個明確的定義，或者在某一個時間段，限定漏洞的類型，這樣集中發現問題，統一來解決。由于參與測試漏洞獎勵的人，可能會更多關注一些容易發現問題的接口和一些容易發現的漏洞類型（例如：XSS），因此，測試的覆蓋范圍沒有辦法保證，不能用漏洞獎勵這種活動代替內部的安全測試，它只是一個補充而已。

總之，AST應該在開發階段就充分利用來發現代碼的安全問題并及時修復；在發布前的階段可以根據前一階段的結果進行有針對性地測試，最好使用不同的工具，這樣可以發現不同的安全問題；在產品發布之后，需要關注的配置和使用的組件的漏洞，及時打上補丁。針對對外開放的應用無論是自研的還是購買的，必須要結合幾種方法和工具深入檢測，防止未經過測試的代碼的系統就對外開放使用。

網絡安全學習路線

對于從來沒有接觸過網絡安全的同學，我們幫你準備了詳細的學習成長路線圖。可以說是最科學最系統的學習路線，大家跟著這個大的方向學習準沒問題。

同時每個成長路線對應的板塊都有配套的視頻提供：

需要網絡安全學習路線和視頻教程的可以在評論區留言哦~

最后

如果你確實想自學的話，我可以把我自己整理收藏的這些教程分享給你，里面不僅有web安全，還有滲透測試等等內容，包含電子書、面試題、pdf文檔、視頻以及相關的課件筆記，我都已經學過了，都可以免費分享給大家！

給小伙伴們的意見是想清楚，自學網絡安全沒有捷徑，相比而言系統的網絡安全是最節省成本的方式，因為能夠幫你節省大量的時間和精力成本。堅持住，既然已經走到這條路上，雖然前途看似困難重重，只要咬牙堅持，最終會收到你想要的效果。

黑客工具&SRC技術文檔&PDF書籍&web安全等（可分享）

結語

網絡安全產業就像一個江湖，各色人等聚集。相對于歐美國家基礎扎實（懂加密、會防護、能挖洞、擅工程）的眾多名門正派，我國的人才更多的屬于旁門左道（很多白帽子可能會不服氣），因此在未來的人才培養和建設上，需要調整結構，鼓勵更多的人去做“正向”的、結合“業務”與“數據”、“自動化”的“體系、建設”，才能解人才之渴，真正的為社會全面互聯網化提供安全保障。