目前隨著各大企業對安全的重視，Web的攻擊成本逐漸高于了防御成本，導致業務中Web安全漏洞的逐漸減少，甚至常規漏洞的消亡。當然，一個漏洞的消亡必會有新的漏洞或者攻擊手法的出現，攻擊的入門門檻隨之而然逐漸的提高。攻防只有前進，沒有倒退，即使目前Web安全的攻擊成本高于防御成本，防御Web攻擊的軟件再多，我們也不能放松每一個防御點。
Web攻擊現狀
DDoS攻擊和Web應用攻擊是當今互聯網面臨的較為突出的兩大安全威脅，DDoS是非漏洞型攻擊，我們暫且不談。Web應用攻擊占了網絡攻擊的主流，由于其地位，這是事實。由于目前國內某些原因，導致以前以技術為主導的現狀不在，現在相對于過去封閉，當前往往一個新的攻擊手法出現，很長時間都沒有人知道，只在某一小圈子里流傳。所以在Web防御逐漸完善的過程中，我們可以感覺的到，滲透一個網站越來越吃力，而是Web這個東西，目前已知的漏洞挖掘方向點就那么多，針對這些漏洞點的防御軟件又多如牛毛，防御者把這些走已知常規漏洞路給堵死了，一般的攻擊者可能無能為力，但是對于一些高水平的攻擊者來說，也許并不是無路可走。
所以，依照現狀來看，目前的Web漏洞利用走向開始往邏輯漏洞方面走，如黑產最喜歡的薅羊毛就是一個例子，現在想要拿到Web站點服務器系統權限不容易，不過利用邏輯漏洞拿到用戶數據信息倒是不難。目前常規的攻擊手法已很難能夠攻破防護做的比較好的企業，所以，為了了解最新攻擊技術或漏洞，我們需要搭建蜜罐系統來捕獲攻擊樣本，獲取自家產品的0day漏洞或更新現有落后技術。
常見漏洞防護
一些常規的漏洞防護就不說了，防護的軟件已經有很多了，漏洞掃描器都可以掃出來，掃不出來的，好一點的防護軟件也是可以識別的。按道理來講，我們應用部署安全監控軟件是可以防護常見漏洞的，當然，我們企業自身也可以通過漏洞攻擊指紋進行攻擊特征識別，攻擊者繞過防護軟件進行攻擊這個也是我們防護不了的也是不可避免的，只要按照標準化安全編程手冊，出現常規漏洞的點會很少，至少顯性漏洞不可見。這里主要講講邏輯漏洞問題。
邏輯問題層出不窮，其他的常規漏洞防范已經有了規范化流程，而邏輯漏洞到目前還沒有一個流程化的防護方案，因為其特殊性，所以我們也得特殊對待。
邏輯漏洞常出現在用戶交互和信息展示之處，當然還有與系統進行交互的地方，下面列幾點
驗證碼
驗證碼是我們常見的一種應對暴力攻擊的方式之一，主要是為了區分人和非人的產物，驗證碼經歷了多次改版，幾乎每個網站的驗證碼都不盡相同，驗證碼在應對繞過和攻擊識別時變得越來越復雜，用戶體驗也越來越不好。
拿以前的12306的驗證碼為例。
請點擊下面所有的熟雞蛋，鬼都不知道哪個雞蛋是熟雞蛋，怎么猜?
當然了，這個只是個笑話，但是也恰恰說明了問題，我們不僅要做好驗證碼，而且還要讓用戶不感到體驗效果差。
驗證碼經過了長期的變化，目前主要分為以下這幾類，我們來了解下
靜態驗證碼
此類驗證碼是比較古老的，應該說是最初的驗證碼了，靜態驗證碼從以前的文本型過度到了現在的圖片型，雖然目前靜態驗證碼加了很多抗干擾加花等等操作，但是目前能夠識別靜態驗證碼的手段還是很多的，大多數的靜態驗證碼比較容易被ocr軟件識別，通過打碼平臺等，還有就是當前火熱的機器學習，通過訓練機器，其靜態驗證碼的識別率可以達到80%以上，所以現在很多站點都開始棄用此類驗證碼了
Gif動畫驗證碼
有的網站提供GIF動態的驗證碼圖片，由于在Gif驗證碼中，有多個驗證碼圖層，這些都是隨機的，使得識別器不容易辨識哪一個圖層是真正的驗證碼圖片，可以更有效得防止識別器的識別。但是也是有弊端的，Gif在顯示的最后都會暫停供用戶識別，只要識別出最后暫停的那張圖層，就可以像識別靜態驗證碼那樣識別Gif驗證碼了。
手機短信驗證碼
手機驗證碼是通過發送驗證碼到手機，這個是比較好的驗證手段，目前使用這類驗證碼的站點還是很多的。
手機語音驗證碼
這個驗證碼的成本比較高，一般用于金融等站點的驗證碼，不過效果還是很好的。
視頻驗證碼
視頻驗證碼中隨機組合而成的驗證碼動態嵌入到MP4，flv等格式的視頻中，增大了破解難度。驗證碼視頻動態變換，隨機響應，可以有效防范字典攻擊、窮舉攻擊等攻擊行為。攻擊者可以通過抓屏的方式進行識別，但是效果不是很好。
滑動驗證碼
這種驗證碼是最近幾年流行起來的，這個驗證碼需要與用戶進行交互，采用拼圖或滑動左右模式進行驗證。應對此類驗證碼攻擊者一般是通過網站的驗證碼接口找突破，或者采用如鼠標模擬等操作進行驗證碼識別。
點擊驗證碼
此類驗證碼一般是給出一張圖片讓用戶進行識別，如12306的驗證碼識別。應對此類驗證碼攻擊者一樣可以通過鼠標模擬等操作進行驗證碼識別。
智力驗證碼
顧名思義就是，給用戶出一道題，讓用戶把答案算出來進行驗證。此類驗證也是存在一定的弊端的，因為驗證碼大多數是以圖片的形式出現的，而相對于比較低級的算數題類驗證碼，攻擊者可以用靜態驗證碼識別的手段進行問題提取，繼而進行算數運算，從而達到識別此類驗證碼的目的。
交互驗證碼
此類驗證應該算是目前前端驗證碼驗證比較安全的驗證碼了。
在有客戶端的站點上應用比較廣泛，首先要登錄站點，需要客戶端進行授權，如掃碼登錄，客戶端驗證后，服務端把登錄信息發送前端進行登錄操作。
當然還有其他的驗證碼驗證手段，這里就不一一介紹了，具體使用什么驗證碼還得看站點的特性和業務的類型，沒全有最好最安全的驗證碼，只有最適合的驗證碼。
交互邏輯
交互邏輯漏洞雖然不像常規漏洞那么厲害，可以直接拿下系統權限，但是給企業造成的損失卻是很大的。我們經?？梢钥吹揭恍┬侣?，說某某網站由于出現支付漏洞，導致損失多少錢。因為邏輯漏洞是不可避免的，它不像常規漏洞可以容易的被漏洞掃描器掃出，它更多的是需要測試人員代碼審計或黑盒測試找出。所以這個交互邏輯漏洞也是比較難以防控的一個點。
通常出現交互邏輯漏洞的點為登錄處、支付處、用戶信息交互處和與數據庫交互處。因為網站程序的某些交互接口或者數據交互接口信息驗證邏輯問題，對提交的數據參數審計不嚴格，造成交互邏輯漏洞，下面列出比較常見的交互邏輯漏洞。
登錄交互邏輯
在登陸處，一般的測試會測試站點是否嚴格控制登錄交互，
攻擊者通過抓包查看提交參數，查看是否有可以利用的交互邏輯漏洞，有些站點在登錄參數，也就是帳號密碼傳過來后，會驗證帳號密碼是否正確，然后返回true或者返回false，即使使用錯誤的帳號密碼，當返回false時，那么我們就可以改返回數據包為true，那么就直接登錄了，更有勝者當用戶名正確后，無論密碼是否正確，都直接返回正確的帳號密碼。有人可能會想，即使你改掉包，不是還有cookie或者token嗎?話雖沒錯，但是某些站點的cookie是直接在前端生成，或者在我們改掉包后，服務器端會把正確的cookie給你返回回來。
還有在找回密碼處，通過找回密碼這個交互邏輯漏洞，攻擊者可以重置任意賬戶密碼，從而達到自己的目的，這對于金融行業和電商行業等用戶量大的站點，造成用戶信息泄漏或者資金被盜甚至對用戶造成詐騙等后果，這對企業的聲譽和發展都會造成影響和損失。
在找回密碼處，攻擊者一般通過驗證郵箱或者手機號找回密碼，如果帳號匹配，服務器一般會發送短信驗證碼或者郵箱驗證碼到用戶手里，那么這個過程如果服務器端驗證不嚴格就有可能會造成交互邏輯漏洞的發生。
重置密碼的攻擊邏輯常見的有如下幾點
- 攻擊者通過修改返回包，繞過驗證步驟，直接到達修改密碼處
- 攻擊者通過修改返回包，把當前重置帳號(如手機號，郵箱地址)，修改為自己的帳號(如手機號，郵箱地址)，那么在服務器沒有對帳號進行嚴格驗證的情況下，服務器端會直接把重置驗證憑證發送到攻擊者的手里
- 攻擊者通過抓取返回包，由于服務器端的自身邏輯問題，可能會把帳號密碼等等與當前重置帳號的相關信息給返回過來，不用重置，就知道了用戶密碼
- 站點找回密碼設計問題，當重置密碼后，服務器會發送新的密碼到用戶手中，而這個密碼是幾位的純數字，攻擊者是可以通過暴力窮舉的方式知道重置的密碼，更有趣的是，某些站點直接是重置密碼為固定的密碼字符串
- 網頁驗證不嚴格，可通過url直接到達修改密碼處
- 某些通過郵件找回的，其重置密碼的鏈接是可以猜測和預知的
還有就是驗證碼邏輯問題，某些驗證碼雖然在前端進行了驗證，但是在后端卻沒有進行很嚴格的檢查，攻擊者可以通過刪除驗證碼或者驗證碼是不變的，可有可無的，那么攻擊者就可以實施撞庫或這暴力破解用戶帳號密碼了。在用手機或郵箱或其他接收攻擊接收登錄或重置密碼時，可能出現驗證碼交互邏輯漏洞。我們知道，一般情況下，站點發送的驗證碼是有時間限制的，通常為幾分鐘，如果驗證碼在后端發送邏輯有問題的話，就會出現問題。如，當攻擊者在爆破時，驗證碼過期時間為5分鐘，時間快到了時，攻擊者再發送一次請求，因為后端沒有做失效控制策略，就又會收到一次一模一樣的驗證碼，而且時間又是5分鐘，那么想要爆破某一個帳號的密碼就不再是什么難事了。當然還有站點直接返回驗證碼的，或者驗證碼是在前端生成通過后端直接發送到用戶手中的。
想要防護登錄交互邏輯此類的漏洞也很簡單，就是要對相關的參數做個嚴格的驗證，如
- 登錄的邏輯不返回前端，由后端管控，前端進行調用
- 驗證碼失效時間進行嚴格控制，驗證碼不能多次使用，為一次性驗證碼，獲取驗證碼的時間也要有時間限制，由后端管控，預防被用于短信轟炸
- 所有的賬戶重置信息都不返回給前端
- 生成的重置密碼連接是不可預知的，隨機的
當然，防護手端多種多樣，最主要的只有一點，那就是嚴格檢查參數，對參數進行嚴格的校檢，預防此類漏洞就只能是提高驗證邏輯。
支付邏輯
支付漏洞可以說是比較嚴重的邏輯漏洞了，畢竟是涉及到錢這個問題。一個支付漏洞有可能會對企業造成巨大的損失。
支付漏洞的產生符合邏輯漏洞特點，都是其修改自身邏輯達到欺騙的效果。
支付的一般流程為：確認信息=>提交訂單=>支付=>支付成功
主要的漏洞點如下
1.修改參數屬性值
參數的屬性值有
- 支付金額
- 代金卷
- 積分
- 其他
這幾個屬性值也是最為基礎和常見的支付邏輯漏洞發生點，攻擊者一般的攻擊手法為修改支付金額的多少來進行測試，出現漏洞的支付步驟一般在提交訂單時或提交訂單之后，通過把支付的金額修改成低價格或者修改為負數，如果后端判斷邏輯有問題，那么就會出現支付邏輯漏洞了。
所以，在后端進行判斷時，要對相關參數進行綁定，即使在前端修改了，后端也是可以初始化參數的。
2.修改數量值
這個和修改參數屬性值差不多，也是把商品數量修改為負數達到支付金額成負數的效果，當然還有一種就是商品差價修改，用一種低價格商品的數量總金額去支付高價格商品的數量總金額，如果后端邏輯有問題，那么就可以低價格購買高價格商品了。
3.越權支付
越權一般發生在支付環節，攻擊者可以通過修改自身ID為其他用戶的ID值，如果沒有嚴格的支付密碼或驗證碼的話，就可以達到用他人賬戶為自己的商品買單的效果，當然還有其他的越權支付手段，如越權支付他人賬單，越權提現他人現金等。
4.條件競爭
條件競爭這個詞我們在Web漏洞或是其他系統漏洞中都是可以看到的，條件競爭利用其高并發線程，利用時鐘延遲(后臺處理延遲)達到多出或或高于現有正常結果。如LFI漏洞，通過不斷寫入tmp文件，達到getshell的目的。同樣，如提現功能來說，如果我們把要提現的金額分成多份，通過高并發線程，如果后端處理能力或者邏輯判斷能力存在缺陷的話，那么我們就可以提現高于提現次數的金額。
5.支付狀態
通常在我們支付成功后，服務器會返回一個支付成功或支付失敗的結果，如果在后端沒有對支付狀態和訂單號進行綁定的話，那么攻擊者只需要修改返回狀態為True就會成功購買商品，而無論支付是否成功。
支付邏輯漏洞主要是代碼層方面的防護，如果后端對提交的參數進行了綁定，那么無論前端怎么的修改，后端都是可以判斷和初始化參數的;對于支付接口來說，如果調用第三方支付接口的話，也是要對接口進行綁定，最好對訂單號進行綁定，避免用不存在的支付接口支付成功。
對于此類支付漏洞來講，我們能做的就是提高風控手段，所有的支付結果要進行延時處理，把支付結果與訂單之前的結果進行對比，查看是否異常，必要時加入人工審核，以此來減小事故發生幾率。
越權
對于越權，越權也是屬于邏輯漏洞的一種。
越權漏洞的存在環境，在Web環境中的不同而不同，拿有登錄操作的站點來聊聊。在這類站點中，越權一般出現在個人信息處，如我們點擊個人信息，通常在個人信息鏈接數據包里會帶有用戶userid，不出意外的話，我們修改其userid為其他用戶userid會出現其他用戶的信息。這個漏洞的產生是后端對用戶的權限或登錄狀態判斷不嚴造成的，對于此類漏洞站點一般的做法是添加用戶token或附帶其他什么亂七八糟的驗證，對于越權也算是比較好的防范了。
當然，邏輯漏洞遠不止上面提到的這么多，邏輯漏洞的防范是一個長期的過程，隨著站點的業務和功能的拓展，其邏輯復雜度也在增加，只要企業把控好權限、驗證、輸出這三個點，邏輯漏洞出現的幾率也就小了許多。
系統錯誤配置
某些站點的安全管控做的非常好，但是細節卻處理的不好，其中不乏一些大的廠商，站點不出現漏洞，但是支持站點運行的服務器軟件由于站點管理員的違規操作可能會導致大的漏洞產生。如Apache開放了PUT功能，權限管控不到位所導致的目錄遍歷操作，IIS的短文件名漏洞等。所以按照規范定期進行服務器基線檢查是非常有必要的。
數據庫漏洞
數據庫漏洞一般就是弱口令或未授權訪問，其余的如REC等漏洞或多或少還是需要點權限的，隨著企業的安全意識提高，建站一般會使用站庫分離的做法，這樣做可以很好的保護數據庫服務器和提高站點服務器的系統資源利用率，提高站點安全性。當然，站點的權限如非必要，最好還是進行降權賬號登錄，很多的數據庫漏洞都是因為暴露在公網導致的被入侵，如果權限較低的話，那么被攻下的難度就很高了。
從站點的SQL注入漏洞來講，這本身就不屬于數據庫漏洞了，屬于站點自身的漏洞，所以SQL注入的根源在于站點代碼，而非數據庫。
薅羊毛
薅羊毛這個雖不能算是漏洞(也可以說和漏洞危害差不多)，但是對企業造成的損失還是很大的，目前薅羊毛現已經成為了一個產業鏈，羊毛黨利用網站漏洞或者人員條件(黑產)等其他優勢，合法占用企業資源，使企業的宣傳或活動達不到預期的效果，浪費企業資源，甚至造成損失。
當企業辛辛苦苦策劃出來的活動被羊毛黨利用，企業投入了大量物力換來的是羊毛黨的流量，那么，我們有什么方法能減少被薅羊毛額幾率呢?
防范羊毛黨可以從以下幾個方面著手
- 嚴控注冊流程，阻止非法注冊
- 定期清理垃圾帳號
- 提高參加活動的門檻
- 對參加活動的用戶進行嚴格的資格審核，提高用戶真實性
- 平臺漏洞：嚴控相關活動的接口調用邏輯，確保通過了安全檢測后上線
- 延遲活動獎勵的時限
- 增加和提高合法用戶真實性(人機用戶)驗證機制
當然，具體的防范措施也不是依照以上幾種防范措施就能完全杜絕薅羊毛的行為，所謂完善的安全管控體系，都是建立在具體實踐的基礎上的，防范管控經驗都是在經歷了”具體事故“才能很完美的總結出來，這樣才能對企業自身或者具體業務量身定制一套薅羊毛應對措施，往大了說還能通用于某一行業的所有產品。
第三方程序管控
一個企業里面，用到的Web程序不敢說都是自己開發的,或多或少會用到其他企業的開源或收費的Web程序，那么這些Web程序又該如何管控呢?
對于此類應用來說，上線和自身產品差不多，都是需要經過安全評估的，通過了安全評估以后，進行備案上線。后續需定期關注官網補丁并及時進行補丁更新，如果Web程序存在0day漏洞的話，結合當前服務器的安全策略進行管控。
權限管控
權限這個問題是站點被攻破后的最后一道防御點，如果站點權限出現問題，那么整個站點就真的淪陷了。
在Web的滲透測試中，攻擊者在拿到了可以操控站點的權限時(如后臺登錄權限)，首先想到的就是上傳腳本木馬來控制服務器，然后利用腳本木馬來進行提權操作，最后內網滲透等等。
所以在攻擊者有了操作站點權限的這個節點時是企業管控Web這最后一道防線的關鍵點，下面我們來討論下權限問題。
站點的啟動一般不用最高權限啟動，一般管理員會新建一個低權限的賬號來啟動Web站點服務，用低權限啟動的Web服務權限有限，無法執行創建修改或刪除文件等高權限操作，所以對腳本木馬的寫入有一定的防范作用;但是有一些站點因為要使用某些第三方庫，或者需要執行某些合法的敏感操作，可能會要求請求高權限啟動，這個時候權限管控就會有一定風險存在了，企業能做的就是對整個站點進行旁路權限管控，如：
- 上傳目錄的腳本解析和執行權限
- 站點的命令執行權限
- 跨目錄權限
所以，權限最大的問題在于執行上，如果控制了執行權限，那么無論你怎么上傳，上傳什么文件，都執行不起來。
權限管控是一個老生常談的問題，權限和業務有著比較矛盾的問題，因為有些情況下需要開啟高權限來支撐站點的某一功能，但是在該功能的高權限開啟情況下又會出現安全問題。所以說，權限管控并不難，難就難在要配合具體業務場景而又不要出現安全問題上。
日常監控
監控站點是一種了解當前站點運行狀態的必要手段，也是一種獲取攻擊和威脅情報的來源之一。
監控的手段一般為
- 日志監控
- 通信流量監控
- 文件監控
- 系統操作監控
通過監控手段，企業可以獲取大量有用的信息，能夠幫助企業改善產品、獲取威脅情報、調查取證等方面有著很大的幫助。
日志監控主要是針對于Web服務器和站點所產生的日志情況，提取日志中所產生的異常并針對性的進行處理。
通信流量監控主要是針對Web站點的所有流量進行的監控，在通信流量里面一般會包含攻擊行為，那么對于匹配性的攻擊行為進行預警，篩選出攻擊流量進行分析，如果可靠的話，我們有一定的幾率可以獲得新的攻擊技巧、0day漏洞或者發現站點新的漏洞等。對于某些攻擊流量來說，一個站點存在命令執行，在流量中會出現系統命令或其他第三方命令等特征字符。
文件監控是站點監控里比較重要的監控之一了，因為攻擊者攻擊站點時一般都會對文件進行操作，文件的變動可以讓被入侵的站點快速定位入侵點，從而應急及時，減小損失;文件監控對于權限管控不到位而造成的安全問題有著比較好的支撐，對于那些正常文件被寫入腳本木馬的文件來說，我們可以知道寫入的代碼是否為木馬代碼，是否為正常代碼，是否為非法寫入。
系統操作監控主要為針對Web站點所執行的系統操作，在系統操作監控里面，我們可以看到Web站點和系統的所有交互行為，通過監控日志，我們可以分析得出，Web站點的哪些文件在與系統進行交互，執行的行為是否為正當合法的行為(和syslog取證差不多)。
通過監控的手段，我們可以清楚的了解到站點服務器都做了些什么，它們所做的事情是否是正當的。監控手段所帶來的好處就是，如果出現安全問題能夠在第一時間找出問題所在，監控手段在檢測到疑是攻擊行為時，可以進行有效的攻擊阻斷，即使是Web站點存在漏洞情況下。這一點就和WAF的功能有相識之處了。
WAF
權限管控是Web安全的最后一道防線，那么WAF(Web Application Firewall)可以說是Web安全中的第一道防線。
在目前互聯網的Web站點中，無論網站大小或多或少會安裝WAF來保護網站，在安裝了WAF的網站比不安裝WAF的網站安全性要高，站點安裝了WAF提高了攻擊的門檻，可以防范一般的(沒有什么技術能力的)攻擊者。隨著技術的發展和安全攻防的交鋒加劇，WAF的功能也從以前的功能單一逐漸變為現在的多功能WAF，不僅能夠攔截過濾還能殺毒等。
當然，不得不說的就是現在常用的加速器CDN(Content Delivery Network)了，CDN發展也是差不多，以前只是單一個給網站加個速，發展到現在，CDN有了WAF的功能，能夠代替WAF做一些攻擊攔截的事情，當然不是有了CDN就能完全代替WAF了，如果攻擊者繞過了CDN找到了服務器的真實IP地址呢，又當如何?
在Web安全的建設中，WAF不能說必不可少，但是有了WAF，站點的安全性能夠提高到一個檔次，不僅能夠擋掉一些普通攻擊者的攻擊，還能夠提高高級攻擊者的攻擊成本，即使網站淪陷了，不是還有其他的防護手段嗎?都是擺設?沒錯，其他的防護手段就是擺設。
安全建設就是這樣，防護做的再好，如果沒有從根源解決問題，攻擊者只要有心，那么一切的防護手段繞過只是時間問題，這個就和擒賊先擒王是一個道理了。所以，Web漏洞的根源就是站點代碼，只要代碼層顯性漏洞不存在，加上代碼層的其他安全防護措施做到位，那么站點就能做到相對安全，而能夠讓站點做到相對安全的就是“代碼安全審計”。
代碼安全審計
代碼審計作為安全測試中重要的一環，代碼審計能夠發現一些潛在的漏洞，幫助企業更好的完善Web程序，減少被攻擊的風險。
如上文所述，站點服務器的防護做的再好，如果站點的程序代碼存在問題的話，那么一切的防護措施可能成為擺設。作為一個負責的企業，要對自己和自己的用戶負責，那么Web產品在發布或新版本更新時，就需要進行代碼審計，以最大的可能減小漏洞發生的幾率。
對于Web程序來講，代碼審計一般特別針對常規高危漏洞，因為對于常規漏洞一般的掃描器都是可以掃的出來的，而對于那些需要特定條件才能觸發的漏洞(如CSRF，埋雷攻擊)，產品能做的就是盡可能的控制各個交互的權限分離和綁定(加強驗證)。
目前市面上免費的和收費的代碼審計產品有很多，大多數都是基于靜態分析，所以誤報率還是比較高的，審計工具它只能是個參考，具體的邏輯分析還是需要專業的安全技術人員跟進。那么代碼審計也有一定的盲區，因為隨著一個產品的功能增加，代碼量的加大，有時候一個產品的代碼就有幾萬行，大小幾十上百兆，不可能說完全依靠人工能夠審計的完的，就算審計完了，質量還是得不到保證。在這個情況下，工具就有了用武之地，代碼審計可以以白加黑的方式進行，審計效率可以提升很多。
在我們代碼審計無法觸及之處，其余的漏洞就只能交由網絡白帽子來進行發現了。
安全眾測
眾測是最近幾年火起來的，在網上也有許多的眾測平臺，在這些平臺上，企業可以花比較少的錢就能把Web安全做的上個大的檔次。由于人的精力和攻擊知識面不同，在企業內部代碼審計和滲透測試無法再找到漏洞時，拿去進行一次眾測，不出意外的話，一定可以收到不一樣的效果。正所謂“山外青山樓外樓”，白帽子發現的漏洞和其獨特的利用姿勢可以作為Web產品安全的完善方向。而對于比較小型的網站來說，眾測就顯得沒有什么必要了。
業務風控
一個web系統的安全性如果做的很好了，常規漏洞一般是不會出現的，那么由于攻擊手法的不確定性，如果有新型的漏洞或者更高級的攻擊手法出現，那么一個web系統將面臨高風險。所以企業需要自身有一套完善的風控制度，一旦發生安全問題，能夠在第一時間以最快速度解決問題，降低損失。整個風控的方面可以從：社會影響、內部影響、經濟損失等方面著手，建立起完善的災備恢復體系。著重加強縱深防御，防止外部威脅擴大到內部。
Web安全建設總結
在Web安全中，攻擊利用的手法多變，它不像系統漏洞那樣，只要管控好端口，那么遠程攻擊就會失效。Web雖然簡單，但是漏洞的成因還是很復雜的，不是我們把可能存在的漏洞點堵上就能沒事的，反之，Web以一個小小的錯誤都有可能會導致所有的防御失效。攻擊者攻擊Web程序只需要一個點，而防御者卻需要防御的是整個面，在Web攻防中，一直以來Web的防御都是處于被動的局面，企業想要改變這一局面，只能是任重而道遠。
鑒于Web漏洞防御和漏洞成因的復雜性，Web安全建設不是本篇文章能夠說的清的，也不是企業把握好文章中的幾個點就能把Web安全建設的好的，這樣的話只能說筆者站著說話不嫌腰疼了。Web安全的體系建設不僅僅是安全漏洞的管控，當然還包括了其他的方方面面，攻擊者可能利用合法的網站功能來干一些不可描述的事情，如果Web安全的建設是很簡單的話，就不會出現眾多安全專家都頭疼的事情了。
所以，具體的Web安全建設各個企業不同，所屬業務不同，自然所做的建設方案也會有所不同，能夠建設起來非常棒的Web安全體系，企業都是經過了眾多實踐積累下來的經驗。
不過，對于Web防御重要的幾個點，倒還是比較通用的。
權限問題
權限在Web安全中是很重要的，因為攻擊者有了操控站點的權限后，就會想方設法的拿到服務器的權限，進而完成更深入的滲透。權限的管控在于當前業務所屬類型決定，權限分制能夠讓權限得到更好的管控。
主動防御問題
主動防御就是一些WAF等審計系統了，主動防御不是萬能的，使用不當還可能會對自身業務產生影響，主動防御會被繞過的幾率還是有的。
監控問題
監控這一部分是比較難的點，因為由于攻擊手法的不確定性，監控規則不夠靈活等方面，造成了監控可能會有遺漏的地方。
代碼安全審計問題
代碼的安全審計是Web安全之根本，如果沒有審計過的程序上線的話，可能存在的高風險就會比審計過的程序多，所以，代碼審計是Web程序正式發布版本前的必要工作。
作者：mosin
