讀書筆記——吳翰清《白帽子講Web安全》

時間 2019-11-09

標籤讀書筆記白帽子講Web安全欄目 HTML 简体版

原文原文鏈接

目錄php

第一篇世界觀安全html

一個人安全世界觀前端

第二篇客戶端腳本安全html5

一瀏覽器安全
二跨站腳本攻擊（XSS）
三跨站點請求僞造（CSRF）
四點擊劫持（ClickJacking）
五 HTML5 安全java

第三篇服務端應用安全mysql

一注入攻擊
二文件上傳漏洞
三認證與會話管理
四訪問控制
五加密算法與隨機數
六 Web框架安全
七應用層拒絕服務攻擊
八 PHP安全
九 Web Server配置安全程序員

第四篇互聯網公司安全運營 web

一互聯網業務安全
二安全開發流程（SDL）
三安全運營正則表達式

第一篇世界觀安全算法

一個人安全世界觀

1.安全問題的本質是信任的問題。

2.安全是一個持續的過程。

3.安全三要素：機密性（Confidentiality）、完整性（Integrity）、可用性（Availability），簡稱CIA。

機密性要求保護數據內容不能泄露，加密是實現機密性要求的常見手段。
完整性要求保護數據內容是完整的，沒有被篡改的。
可用性要求保護資源是「隨需而得」。
擴展：可審計性，不可抵賴性。

4.如何實施安全評估？4個階段：資產等級劃分-->威脅分析-->風險分析-->確認解決方案。

（1）資產等級劃分

互聯網安全的核心問題，是數據安全的問題。因此，對互聯網公司的資產等級劃分，就是對數據作等級劃分，而後要劃分信任域和信任邊界。

（2）威脅分析

威脅分析就是把全部的威脅都找出來。
通常採用頭腦風暴法和威脅建模法（好比微軟提出的STRIDE模型）。
漏洞的定義：系統中可能被威脅利用以形成危害的地方。

（3）風險分析

風險由如下因素組成：Risk（風險）=Probability（發生的可能性）*Damage Potential（損失的大小）
一種科學衡量風險的方法：微軟提出的DREAD模型。
注意：模型是死的，人是活的。模型只能起到輔助做用，人要靈活運用。

（4）設計安全方案

一個優秀的安全方案應該具有如下特色：

可以有效解決問題
用戶體驗好
高性能
低耦合
易於擴展與升級

5.安全方案設計技巧

（1）Secure By Default原則

黑名單、白名單原則（儘量使用白名單，不用或者少用黑名單）
最小權限原則（要求系統只授予主體必要的權限，而不要過分受權）

（2）Defence In Depth（縱深防護）原則

縱深防護包含2層含義：首先，要在各個不一樣層面、不一樣方面實施安全方案，避免出現疏漏，不一樣安全方案之間須要相互配合，構成一個總體；其次，要在正確的地方作正確的事情。即：在解決根本問題的地方實施針對性的安全方案。

（3）數據與代碼分離原則

（4）不可預測性原則

不可預測性原則可以有效地對抗基於篡改、僞造的攻擊。

第二篇客戶端腳本安全

一瀏覽器安全

1.同源策略（Same Origin Policy）

同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能。
瀏覽器的同源策略，限制了來自不一樣源的「document」或腳本，對當前「document」讀取或者設置某些屬性。
影響「源」的因素有：host、子域名、端口、協議。
在瀏覽器中，<script>、<img>、<iframe>、<link>等標籤均可以跨域加載資源，而不受同源策略的限制。
對於瀏覽器來講，除了DOM、Cookie、XMLHttpRequest會受到同源策略的限制外，瀏覽器加載的一些第三方插件也有各自的同源策略。最多見的一些插件如Flash、Java Applet、Silverlight、Google Gears等都有本身的控制策略。

2.瀏覽器沙箱

掛馬：在網頁中插入一段惡意代碼，利用瀏覽器漏洞執行任意代碼的攻擊方式。
瀏覽器的多進程架構，將瀏覽器的各個功能模塊分開，各個瀏覽器實例分開，當一個進程崩潰時，也不會影響到其餘的進程。
SandBox即沙箱，泛指「資源隔離類模塊」，設計目的是爲了讓不可信任的代碼運行在必定的環境中，限制不可信任的代碼訪問隔離區以外的資源。

3.惡意網址攔截

工做原理：瀏覽器週期性地從服務端獲取一份最新的惡意網址黑名單，若是用戶上網時訪問的網址存在於此黑名單中，瀏覽器就會彈出一個警告頁面。
常見的惡意網址分爲2類：掛馬網站&釣魚網站。
除了惡意網址黑名單攔截功能外，主流瀏覽器都開始支持EV SSL證書，以加強對安全網站的識別。

4.高速發展的瀏覽器安全

微軟在IE8推出來XSS Filter功能，用以對抗反射型XSS。
FireFox在FireFox4推出來Centent Security Policy（CSP），但並未獲得推廣。
瀏覽器加載的插件也是瀏覽器安全須要考慮的一個問題。

二跨站腳本攻擊（XSS）

1.XSS簡介

跨站腳本攻擊，英文全稱Cross Site Script，簡稱XSS。
XSS攻擊，一般指黑客經過「HTML注入」篡改了頁面，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。
XSS分類：反射型XSS（也叫非持久型XSS）、存儲型XSS（也叫持久型XSS）、DOM Based XSS。

2.XSS攻擊進階

2.1 XSS Payload

XSS Payload就是XSS攻擊成功後，攻擊者對用戶當前瀏覽的頁面植入的可以完成具體功能的一些惡意腳本。
- （1）Cookie劫持——一個最多見的XSS Payload就是經過讀取瀏覽器的cookie對象，從而發起「Cookie劫持」攻擊，直接登陸進用戶的帳戶。Cookie的「HttpOnly」標識或者把cookie與客戶端IP綁定能夠防止「Cookie劫持」。
- （2）構造GET、POST請求
- （3）XSS釣魚——舉例：利用JavaScript在當前頁面上「畫出」一個僞造的登陸框，當用戶在登陸框中輸入用戶名與密碼後，其密碼將被髮送到黑客的服務器上。
- （4）識別用戶瀏覽器——如何經過JS腳本識別瀏覽器版本？1經過XSS讀取瀏覽器的UserAgent對象，存在誤報問題；2根據各個瀏覽器之間存在的實現差別——不一樣的瀏覽器會各自實現一些獨特的功能，從而寫代碼識別出不一樣的瀏覽器。
- （5）識別用戶安裝的軟件——舉例：IE中，能夠經過判斷ActiveX控件的某個classid是否存在，來推測用戶是否安裝了該軟件。FireFox的插件列表存放在一個DOM對象中，經過查詢DOM能夠遍歷出全部的插件。Chrome中，經過檢測擴展的圖標，來判斷某個特定的擴展是否存在。
- （6）CSS History Hack——CSS History Hack就是經過CSS，來發現一個用戶曾經訪問過的網站。其原理就是利用style的visited屬性——若是用戶曾經訪問過某個連接，那麼這個連接的顏色會變得不同凡響。
- （7）獲取用戶的真實IP地址

2.2 XSS攻擊平臺有：Attack API、BeEF、XSS-Proxy等。

2.3 終極武器：XSS Worm(蠕蟲)

發起XSS Worm攻擊的條件：通常來講，用戶之間發生交互行爲的頁面，若是存在存儲型XSS，則比較容易發起XSS Worm攻擊。
好比發送站內信、用戶留言等頁面，都是XSS Worm的高發區。
舉例：Samy Worm（具備里程碑意義的第一個XSS Worm）、百度空間蠕蟲等。

2.4 常見的調試JavaScript的工具：Firebug、IE開發者工具、Fiddler、HttpWatch等。

2.5 常見XSS構造技巧

（1）利用字符編碼
（2）繞過長度限制——好比將XSS Payload寫到別處，再經過簡短的代碼加載這段XSS Payload。在某些環境下，也能夠利用註釋符繞過長度限制。
（3）使用<base>標籤——<base>標籤並不經常使用，它的做用是定義頁面上的全部使用「相對路徑」標籤的hosting地址。攻擊者若是在頁面中插入了<base>標籤，就能夠經過在遠程服務器上僞造圖片、連接或腳本，劫持當前頁面中的全部使用「相對路徑」的標籤。
（4）window.name的妙用——window對象是瀏覽器的窗體，而並不是document對象，所以不少時候window對象不受同源策略的限制。對當前窗口的window.name賦值，沒有特殊字符的限制。舉例：利用window.name能夠實現數據的跨域傳遞、縮短XSS Payload的長度等。

2.6 變廢爲寶：Mission Impossible

Apache Expect Header XSS漏洞曾經一度被認爲是「雞肋」漏洞，可是後來有人提出了「使用Flash構造請求」的方法，成功地利用了這個漏洞。
Anehta 的迴旋鏢的思路以下：若是在B域上存在一個反射型XSS_B，在A域上存在一個存儲型XSS_A，當用戶訪問A域上的XSS_A時，同時嵌入B域上的XSS_B，則能夠達到在A域的XSS攻擊B域用戶的目的。即將要利用的反射型XSS嵌入一個存儲型XSS中。這個攻擊技巧的缺點是，儘管跳轉花費的時間很短，但用戶仍是會看到瀏覽完地址欄的變化。

2.7 容易被忽視的角落：Flash XSS

前文講到的XSS攻擊都是基於HTML的，其實在Flash中一樣也有可能形成XSS攻擊。緣由是在Flash中是能夠嵌入ActionScript腳本的。所以應該儘量地禁止用戶可以上傳或加載自定義的Flash文件。若是必定要使用Flash，則能夠經過Flash的配置參數進行限制，若是是視頻文件，則要求轉碼爲「flv文件」。

2.8 真的高枕無憂嗎？JavaScript開發框架

常見的JavaScript框架，Dojo、YUI、jQuery等。
使用JavaScript框架並不能讓開發者高枕無憂，一樣可能存在安全問題。除了須要關注框架自己的安全外，開發者還要提升安全意識，理解並正確地使用開發框架。

3.XSS的防護

3.1 HttpOnly

瀏覽器禁止頁面JavaScript訪問帶有HttpOnly屬性的Cookie，從而防止Cookie劫持問題。

3.2 輸入檢查

舉例1：輸入格式檢查：有點像白名單，可讓一些基於特殊字符的攻擊失效。輸入檢查邏輯必須放在服務端代碼中實現，放在前端易被繞過。
舉例2：XSS Filter：在用戶提交數據時獲取變量，並進行XSS檢查，但此時用戶數據並無結合渲染頁面的HTML代碼，所以XSS Filter對語境的理解並不完整。

3.3 輸出檢查

（1）使用安全的編碼函數

HtmlEncode：針對Html代碼的編碼方式，它的做用是將字符轉換成HTMLEntities，對應的標準是ISO-8859-1。HtmlEncode要求至少轉換如下字符：（&-->&）（<--><）（>-->>）（"-->"）（'-->'）（//）。在OWASP ESAPI中推薦了一種更嚴格的HtmlEncode——除了字母、數字外，其餘全部的特殊字符都被編碼成HTMLEntities。
JavascriptEncode：針對JavaScript的編碼方式，使用「\」對特殊字符進行轉義，要求輸出的變量必須在引號內。還有一個更加嚴格的函數來保證安全——除了數字、字母外的全部字符，都使用十六進制「\xHH」的方式進行編碼。

（2）只需一種編碼嗎

XSS攻擊主要發生在MVC架構中的View層，大部分的XSS漏洞能夠在模板系統中解決。好比Python的2個經常使用的開發框架Django和web2py都選擇在View層默認escape全部變量（即HtmlEncode全部變量）以對抗xss，可是並不是在模板引擎中使用了auto-escape就萬事大吉了，XSS防護須要區分狀況對待。

3.4 正確地防護XSS

XSS可能發生的場景及對應的防護方法：
場景1：在HTML標籤中輸出 ——>防護方法是使用HtmlEncode。
場景2：在HTML屬性中輸出——>防護方法是使用HtmlEncode。
場景3：在<script>標籤中輸出——>首先確保輸出的變量在引號中，防護方法是使用JavascriptEncode。
場景4：在事件中輸出——>防護方法是使用JavascriptEncode。
場景5：在CSS中輸出——>通常來講，要儘量禁止用戶可控制的變量在「<style>標籤」、「HTML標籤的style屬性」以及「CSS文件」中輸出，若是必定有這樣的需求，則推薦使用OWASP ESAPI中的encodeForCSS()函數——除了字母數字外的全部字符都被編碼成十六進制形式「\uHH」。
場景6：在地址中輸出——>若是變量在在URL的路徑或者參數中輸出，使用URLEncode便可，URLEncode會將字符轉換爲「%HH」形式，好比空格就是「%20」；若是在URL的協議與host中輸出，則不能使用嚴格URLEncode函數，由於會把「://」、「.」等都編碼掉；若是在整個URL中輸出，則應該先檢查變量是否以「http」開頭（若是不是自動添加），以保證不會出現僞協議類的XSS攻擊，而後再對變量進行URLEncode。

3.5 處理富文本

有些時候，網站須要容許用戶提交一些自定義的HTML代碼，稱之爲富文本。
在過濾富文本時，請謹記如下幾條：
（1）事件以及一些危險的標籤，好比<iframe>、<script>、<base>、<form>等，應該被嚴格禁止。
（2）在標籤、屬性、事件的選擇上，應該使用白名單，避免使用黑名單。
（3）儘量禁止用戶自定義CSS與style。若是必定要容許用戶自定義樣式，則只能像過濾富文本同樣過濾CSS，這須要一個CSS Parser對樣式進行智能分析，檢查其中是否包含危險代碼。
（4）有一些比較成熟的開源項目，好比Anti_Samy、HTMLPurify等，實現了對富文本的XSS檢查。

3.6 防護DOM Based XSS

DOM Based XSS是從JavaScript中輸出數據到HTML頁面中，須要分語境使用不一樣的編碼函數。

3.7 從業務風險的角度看XSS的風險

存儲型XSS的風險高於反射型XSS。由於存儲型XSS會保存在服務器上，有可能會跨頁面存在，甚至可能繞過一些檢測工具。
反射型XSS通常須要誘使用戶點擊一個包含XSS代碼的URL連接，而存儲型XSS只須要用戶查看一個正常的URL連接。這樣的漏洞極其隱蔽且埋伏在用戶的正常業務中，風險頗高。
網站的PageView越高，對應頁面受XSS攻擊後的影響越大。

4.小結

理論上，XSS漏洞雖然複雜，但倒是能夠完全解決的。在設計XSS解決方案時，應該深刻理解XSS攻擊的原理，針對不一樣的場景使用不一樣的方法。同時有不少開源項目爲咱們提供了參考。

三跨站點請求僞造（CSRF，Cross Site Request Forgery）

1.CSRF簡介

攻擊者在本身的域構造一個頁面，在這個頁面上僞造一個請求，而後誘使目標用戶訪問這個頁面，從而以該用戶身份在第三方站點裏執行了一次操做。這就是「跨站點請求僞造」。
CSRF爲何可以攻擊成功？其本質緣由是重要操做的全部參數都是能夠被攻擊者猜到的。

2.CSRF進階

2.1 瀏覽器的Cookie策略

瀏覽器的Cookie分爲2種：
Session Cookie（臨時Cookie）：沒有指定Expire時間，瀏覽器一關閉即失效。保存在瀏覽器進程的內存空間中。
Third-party Cookie（本地Cookie）：服務器在Set-Cookie時指定了Expire時間，只有到了Expire時間後Cookie纔會失效，因此這種Cookie會保存在本地。
一些瀏覽器默認策略是，容許在<img>、<iframe>、<script>、<link>等標籤中發送用於認證的第三方Cookie，從而致使CSRF攻擊成功。

2.2 P3P頭的反作用

P3P頭容許跨域訪問隱私數據，從而能夠容許瀏覽器跨域發送第三方Cookie。P3P頭只須要由網站設置一次便可，以後每次請求都會遵循此策略。

2.3 GET？POST？

由於大多數CSRF攻擊發起時，使用的都是<img>、<iframe>、<script>、<link>等帶有src屬性的標籤，而這類標籤只可以發起一次GET請求，不能發起POST請求，因此不少開發者就認爲只要把重要的操做改爲只容許Post請求就能防止CSRF攻擊，其實這種觀點是錯誤的。由於對於攻擊者來講，有若干種方法能夠構造出一個POST請求。好比在一個頁面中構造好一個form表單，而後使用JavaScript自動提交這個表單。

2.4 Flash CSRF

在Flash中能夠經過URLRequest、getUrl、loadVars等多種方式發起網絡請求，包括POST請求。

2.5 CSRF Worm

2008年百度的CSRF Worm展現了CSRF的破壞性——即便沒有XSS漏洞，僅僅依靠CSRF，也是可以發起大規模蠕蟲攻擊的。

3. CSRF的防護

3.1 驗證碼

3.2 Referer Check

Referer Check經過檢查請求是否來自合法的「源」來防護CSRF的攻擊。
它的缺陷在於，服務器並不是何時都能取到Referer。並且，某些客戶端插件容許發送自定義的Referer頭。

3.3 Anti CSRF Token（主要手段）

因爲token足夠隨機，使攻擊者沒法再構造出一個完整的URL實施CSRF攻擊。
Token須要同時放在表單和Session中。在提交請求時，服務器只須要驗證表單中的Token與用戶Session（或Cookie）中的token是否一致，若是一致，則認爲是合法的請求，若是不一致，或者有一個爲空，則認爲請求不合法，可能發生了CSRF攻擊。
Token的使用原則（注意隨機性和保密性）
- （1）Token的生成必定要足夠隨機，須要使用安全的隨機數生成器生成Token。
- （2）爲了使用方便，能夠容許在一個用戶的有效生命週期內，在token消耗掉前都使用同一個token。若是Token保存在cookie中，爲解決多頁面共存的問題，能夠考慮生成多個有效的token。
- （3）注意Token的保密性。儘可能把Token放在表單中，把敏感操做由GET改成POST，以form表單（或者AJEX）的形式提交，能夠避免Token泄漏。
- （4）CSRF的Token僅僅用於對抗CSRF攻擊，若是網站還同時存在XSS漏洞，這個方案就無效了。由於XSS攻擊者能夠請求頁面後讀出頁面內容裏的Token值，而後再構造一個合法的請求。這個過程能夠稱之爲XSRF。

四點擊劫持（ClickJacking）

1.什麼是點擊劫持？

點擊劫持是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，而後誘使用戶在該網頁上進行操做，此時用戶將在不知情的狀況下點擊透明iframe頁面。經過調整iframe頁面的位置，能夠誘使用戶剛好點擊在iframe頁面的一些功能性按鈕上。

2.Flash點擊劫持

舉例：攻擊者製做了一個Flash遊戲，誘使用戶來玩這個遊戲，在完成一系列複雜的動做後，最終控制了用戶電腦的攝像頭。

3.圖片覆蓋攻擊（Cross Site Image Overlaying，簡稱XSIO）

XSIO攻擊原理：經過調整圖片的style使得圖片可以覆蓋在他所指定的任意位置。用戶點擊此圖片的話，會被連接到其餘網站。或者不須要點擊，圖片自己就是一個虛假信息。
XSIO防護：須要檢查用戶提交的HTML代碼中，<img>標籤的style屬性是否可能致使浮出。

4.拖拽劫持與數據竊取

思路：誘使用戶從隱藏的不可見的iframe中「拖拽」出攻擊者但願獲得的數據，而後放到攻擊者能控制的另一個頁面，從而竊取數據。

5.ClickJacking 3.0：觸屏劫持（TapJacking）

經過將一個不可見的iframe覆蓋到當前網頁上，能夠劫持用戶的觸屏操做。

6.防護ClickJacking

6.1 使用frame busting方法

寫一段JavaScript代碼，以禁止iframe的嵌套，這種方法叫frame busting。
frame busting的缺陷是，因爲它是用JavaScript寫的，控制能力不是特別強，所以有許多方法能夠繞過它。

6.2 使用一個HTTP頭——X-Frame-Options

X-Frame-Options有3個可選值：
當值爲DENY時，瀏覽器會拒絕當前頁面加載任何frame頁面；
當值爲SAMEORIGIN時，frame頁面的地址只能爲同源域名下的頁面；
當值爲ALLOW_FROM origin時，則能夠定義運行frame加載的頁面地址。

五 HTML5 安全

1.HTML5新標籤

1.1 新標籤的XSS

好比筆者曾經使用了html5中新增的<video>標籤（用於遠程加載一段視頻）寫了一段XSS代碼，成功地繞過來百度空間的XSS Filter。

1.2 iframe的sandbox

HTML5專門爲iframe定義了一個新的屬性，叫Sandbox。它極大加強了應用使用iframe的安全性。
使用sandbox這一屬性後，<iframe>標籤加載的內容將被視爲一個獨立的「源」，其中的腳本將被禁止執行，表單被禁止提交，插件被禁止加載，指向其餘瀏覽對象的連接也會被禁止。
sandbox屬性能夠經過參數來支持更精確的控制。有如下幾個值可選：
- allow-same-origin：容許同源訪問；
- allow-top-navigation：容許訪問頂層窗口；
- allow-forms：容許提交表單；
- allow-scripts：容許執行腳本。

1.3 Link Types:noreferrer

在HTML5中爲<a>標籤和<area>標籤訂義了一個新的Link Types:noreferrer。
標籤指定了noreferrer後，瀏覽器在請求該標籤指定的地址時將再也不發生Referer。
這種設計是爲了保護敏感信息和隱私。
<a href="xxx" rel="noreferrer">test</a>

1.4 Canvas的妙用

<canvas>標籤讓JavaScript能夠在頁面中直接操做圖片對象，也能夠直接操做像素，構造出圖片區域。
經過Canvas能夠實現自動破解驗證碼功能，大大下降了攻擊的門檻。

2.其餘安全問題

2.1 Cross-Origin Resource Sharing

瀏覽器實現的同源策略限制了腳本的跨域請求，而隨着跨域請求的需求增多，W3C委員會制定了一個新的標準來解決日益迫切的跨域訪問問題。
標準敘述以下：假設A網頁須要發起一個跨域請求，來請求B網頁的數據，則A網頁在發起請求時必須帶上一個Origin Header以證實本身是一個合法的「源」，若是B網頁服務器返回一個HTTP Header——Access-Control-Allow-Origin:http://www.a.com，那麼這個來自A網頁的跨域請求會被經過。

2.2 postMessage——跨窗口傳遞消息

postMessage是HTML5制定的一個新的API，它容許每個window（包括當前窗口、彈出窗口、iframes等）對象往其餘的窗口發送文本消息，從而實現跨窗口的消息傳遞。這個功能是不受同源策略限制的。
使用win.postMessage()注意事項：
- （1）爲防止消息來自非法頁面，能夠在接收窗口驗證Domain，甚至驗證URL；
- （2）在接收窗口不該信任接收到的消息，須要對消息進行安全檢查；
- （3）使用postMessage也會使XSS Payload變得更加靈活。

2.3 Web Storage

Web Storage是HTML5 提出的一個解決在客戶端本地存儲的功能。
Web Storage分爲Session Storage和Local Storage，Session Storage關閉瀏覽器就會失效，而Local Storage則會一直存在。Web Storage就像一個非關係型數據庫，由Key-Value對組成，能夠經過JavaScript對其進行操做。
使用方法以下：
- 設置一個值：window.sessionStorage.setItem(key,value);
- 讀取一個值：window.sessionStorage.getItem(key);
- 此外，Firefox還單獨實現了一個globalStorage：window.globalStorage.namedItem(domain).setItem(key,value);
Web Storage缺點：
- 攻擊者有可能將惡意代碼保存在Web Storage中，從而實現跨頁面攻擊。
- 當Web Storage保存有敏感信息時，也有可能成爲攻擊對象。

第三篇服務端應用安全

一注入攻擊

注入攻擊的本質，就是把用戶輸入的數據當作代碼執行。這裏有2個關鍵條件，第一個是用戶可以控制輸入，第二個是本來程序要執行的代碼，拼接了用戶輸入的數據。注入攻擊是應用違背了「數據與代碼分離原則」致使的結果。

1.SQL注入

若是網站的web服務器開啓了錯誤回顯，披露了敏感信息，則會對攻擊者構造SQL注入語句提供巨大便利。

1.1 盲注（Blind Injection）

盲注就是在服務器沒有錯誤回顯時完成的注入攻擊。此時攻擊者能夠構造簡單的條件語句，根據返回頁面是否發生變化，來判斷SQL語句是否獲得執行，從而判斷出SQL注入漏洞是否存在。

1.2 Timing Attack

在mysql中有一個用於測試函數性能的BENCHMATK()函數，它可讓同一個函數執行若干次，使得結果返回的時間比平時要長，經過時間長短的變化，能夠判斷出注入語句是否執行成功。這是一種邊信道攻擊，這個技巧在盲注中被稱爲Timing Attack。Timing Attack是盲注的一種高級技巧。在不一樣數據庫中，都有着相似於BENCHMATK()的函數能夠被Timing Attack所利用。

2.數據庫攻擊技巧

2.1 常見的攻擊技巧

（1）SQL注入能夠猜想出數據庫的對應版本。
（2）利用union select能夠確認某個表名是否存在，以及列名是否存在。
（3）進一步能夠經過判斷字符的範圍，一步一步讀出某字段的值。
（4）這個過程很是繁瑣，能夠使用自動化注入工具sqlmap.py來幫助完成。
（5）在注入攻擊過程當中，經常會用到一些讀寫文件的技巧。好比mysql中，就能夠經過LOAD_FILE()讀取系統文件，經過INTO DUMPFILE寫入本地文件，經過LOAD DATA INFILE將文件導入建立的表中，最後就能夠經過通常的注入技巧直接操做表數據了。因此，在設計數據庫安全方案時，能夠禁止普通用戶具有操做文件的權限。

2.2 命令執行

在MySQL中除了能夠經過導出webshell間接地執行命令外，還能夠利用「用戶自定義函數」的技巧，即UDF（User-Defined Functions）來執行命令。好比經過lib_mysqludf_sys提供的幾個函數執行系統命令。
其餘數據庫也有相似UDF的功能，利用UDF功能實施攻擊的技巧也大同小異。
在Oracle數據庫中，若是服務器同時還有Java環境，那麼也可能形成命令執行。當SQL注入後能夠執行多語句的狀況下，能夠在Oracle中建立Java的存儲過程執行系統命令。
通常來講，在數據庫執行系統命令要求具備較高的權限。所以在創建數據庫帳戶時應該遵循「最小權限原則」，儘可能避免給Web應用使用數據庫的管理員權限。

2.3 攻擊存儲過程

（1）利用存儲過程直接攻擊。好比在MS SQL Server中，能夠直接使用存儲過程「xp_cmdshell」執行系統命令，使用存儲過程「xp_regread」等來操做註冊表，等等。
（2）存儲過程自己也可能會存在注入漏洞。好比存儲過程當中的某些變量由外部傳入，且未通過任何處理，將直接形成SQL注入的問題。

2.4 編碼問題

基於字符集的注入攻擊的解決方法：統一數據庫、操做系統、Web應用所使用的字符集，以免各層對字符的理解存在差別。統一設置爲UTF-8是一個很好的辦法。若是由於種種緣由沒法統一字符編碼，則須要單獨實現一個用於過濾或轉義的函數，這個函數根據系統所使用的不一樣字符集來限制用戶輸入數據的字符容許範圍，以實現安全過濾。

2.5 SQL Column Truncation

在MySQL的配置選項中，有一個sql_mode選項。當MySQL的sql_mode設置爲寬鬆模式時，即沒有開啓STRICT_TRANS_TABLES選項時，MySQL對於用戶插入的超長值只會提醒warning，而不是error（若是是error則插入不成功），這可能致使發生一些「截斷」問題。
例如：數據庫中存在一個表user，該表中有一個字段爲username，username的字段類型爲varchar(10)，若是我在插入數據的時候，插入一個值「admin（55個空格）x」，顯然它超過了設定的字段長度10。那麼，若是MySQL事先設置的是寬鬆模式，則此時會報warning，數據自動截斷，插入成功；若是MySQL事先設置的是嚴格模式，則報error，數據插入失敗。
當攻擊者插入一個與數據庫中已存在的同名username時，則可能使攻擊者經過某些認證，從而形成一些越權訪問。好比經過註冊一個用戶名爲「admin（55個空格）x」的用戶，就能夠修改原管理員的密碼了。

3.正確地防護SQL注入

3.1 使用預編譯語句

通常來講，防護SQL注入的最佳方式，就是使用預編譯語句，綁定變量。好比在Java語言中，使用PreparedStatement()方法，綁定變量。
mybatis的#{}和${}語法區別：#至關於對數據加上雙引號，$至關於直接顯示數據。mybatis使用#{}語法參數化來避免SQL注入。

3.2 使用安全的存儲過程

3.3 檢查輸入數據的數據類型

好比輸入數字時，檢查輸入數據只能爲整型，或者輸入郵箱時，嚴格按照郵箱的格式檢查等。

3.4 使用安全的編碼函數

好比ESAPI.encoder().encodeForSQL( new OracleCode(), queryparam );

3.5 最小權限原則

數據庫使用「最小權限原則」，避免Web應用之間使用root、dbowner等最高權限帳戶直接鏈接數據庫。若是有多個不一樣的應用使用同一個數據庫，則也應該爲每一個應用分配不一樣的帳戶。Web應用使用的數據庫帳戶，不該該有建立自定義函數，操做本地文件的權限。

4.其餘注入攻擊

4.1 XML注入

XML注入與HTML注入相似。解決方法就是對用戶輸入數據中包含的「語言自己的保留字符」進行轉義便可。

4.2 代碼注入

代碼注入與命令注入每每都是由一些不安全的函數或者方法引發的，其中的典型表明就是eval()。其餘的還有好比利用Java的腳本引擎實施代碼注入、PHP和JSP的動態include致使代碼注入、利用system()函數執行系統命令等。
對抗代碼注入、命令注入是，須要禁用eval()、system()等能夠執行命令的函數。若是必定要使用這些函數，則須要對用戶的輸入數據進行處理。此外，在PHP/JSP中避免動態include遠程文件，或者安全地處理它。此外，在開發過程當中，應儘可能避免使用危險函數。

4.3 CRLF注入

CRLF其實是兩個字符：CR是carriage return（回車，ASCII 13，\r），LF是line feed（換行,ASCII 10,\n）。即\r\n，其十六進制編碼分別爲0x0d、0xa。
CRLF常被用作不一樣語義之間的分隔符。所以t經過「注入CRLF字符」，就有可能改變原有的語義。凡是使用CRLF做爲分隔符的地方都有可能存在這種注入，好比log注入、「注入HTTP頭」等。
在HTTP協議中，HTTP頭是經過「\r\n」來分隔的。所以若是服務器端沒有過濾「\r\n」，而又把用戶輸入的數據放在HTTP頭中，則有可能致使安全隱患。這種在HTTP頭中的CRLF注入，又能夠稱爲「Http Response Splitting」。好比經過2次CRLF注入能夠將惡意代碼注入到HTTP Body中，經過1次CRLF注入能夠注入一個Link頭形成XSS、注入一個X-XSS-Protection:0頭以關閉IE8的XSS Filter功能等。
對抗CRLF的方法很是簡單，只要處理好「\r」、「\n」這兩個保留字符便可，尤爲是那些使用換行符做爲分隔符的應用。

二文件上傳漏洞

1.文件上傳漏洞概述

文件上傳漏洞是指用戶上傳了一個可執行的腳本文件，並經過此腳本文件得到了執行服務器端命令的能力。
文件上傳後致使的常見安全問題通常有~~~~~
經過文件上傳漏洞進行攻擊須要知足3個條件：
（1）上傳的文件能被web容器解釋執行。
（2）用戶可以從Web上訪問這個文件。
（3）用戶上傳的文件若被安全檢查、格式化、圖片壓縮等功能改變了內容，則也可能致使攻擊不成功。

1.1 從FCKEditor文件上傳漏洞談起

FCKEditor是一款很是流行的富文本編輯器，它通常是做爲第三方應用集成到網站中的，它有一個文件上傳功能，在存在漏洞的版本中，是經過檢查文件的後綴來肯定是否安全的，以黑名單的的方式限制文件上傳的類型，所以有一些不在黑名單中的文件，好比後綴爲php2,asa,cer等的文件均可能致使發生安全問題。

1.2 繞過文件上傳檢查功能

不少應用經過判斷文件名後綴的方法來驗證文件的安全性——攻擊者能夠手動修改上傳過程的POST包，在文件名後添加一個%00字節，則能夠截斷某些函數對文件名的判斷，達到攻擊目的。
有的應用經過判斷上傳文件的文件頭來驗證文件的類型——攻擊者能夠僞造一個合法的文件頭，而將真實的PHP等腳本代碼附在合法的文件頭以後。

2.功能仍是漏洞

2.1 Apache文件解析問題

Apache對於文件名的解析是從後往前的，直到碰見一個它認識的文件類型爲止。Apache又是根據定義在自身mime.types文件中的內容來認識文件類型。在Apache 1.x、2.x中，Apache不認識.rar文件類型，因此在解析Phpshell.php.rar.rar.rar.rar.rar文件時，它會從後往前一直遍歷後綴到.php，而後認爲這是一個PHP類型的文件。從而致使腳本被執行。

2.2 IIS文件解析問題

IIS 6漏洞一：分號字符截斷問題，好比將文件名abc.asp;xx.jpg解析爲abc.asp，從而致使腳本被執行。
IIS 6漏洞二：由於處理文件夾擴展名出錯，致使將/*.asp/目錄下的全部文件都做爲ASP文件進行解析。
ISS中因爲支持PUT功能致使的上傳腳本問題：在IIS中，若是目錄支持寫權限，同時開啓了WebDev，則會支持PUT方法，再結合MOVE方法，就可以將原來只容許上傳的文本文件改成腳本文件從而執行webshell。Move可否執行成功，取決於IIS服務器是否勾選了「腳本資源訪問」複選框。
通常要實施此攻擊過程，攻擊者應先經過OPTIONS方法探測服務器支持的HTTP方法類型，若是支持PUT，則使用PUT上傳一個指定的文本文件，最後經過MOVE改寫爲腳本文件。

2.3 PHP CGI路徑解析問題

Nginx配置fastcgi使用PHP時，會存在文件解析漏洞。好比當訪問http://www.xxx.com/path/test.jpg/notexist.php時，會將test.jpg當作PHP進行解析，notexist.php是不存在的文件。
這樣致使的後果是，若是在任何配置爲fastcgi的PHP應用裏上傳一張圖片，其圖片內容是PHP文件，則將致使代碼執行。
官方建議是將PHP的配置文件中與此有關的一個關鍵選項cgi.fix_pathinfo設置爲0（態度消極）。

2.4 利用上傳文件釣魚

釣魚網站在傳播時，會經過利用XSS、服務器端302跳轉等功能，從正常的網站跳轉到釣魚網站。可是這種釣魚會在URL中暴露真實的釣魚網站地址，易被發現。
而利用文件上傳功能，釣魚者能夠先將包含了HTML的文件（好比一張圖片）上傳到目標網站，而後經過傳播這個文件的URL進行釣魚，則URL中不會出現釣魚地址，更具備欺騙性。

3.設計安全的文件上傳功能

（1）文件上傳的目錄設置爲不可執行
（2）判斷文件類型（推薦白名單方式）
（3）使用隨機數改寫文件名和文件路徑
（4）單獨設置文件服務器的域名

三認證與會話管理

1.Who am I?

認證的目的是爲了認出用戶是誰，而受權的目的是爲了決定用戶可以作什麼。
認證明際上就是一個驗證憑證的過程。若是隻有一個憑證被用於認證，則稱爲「單因素認證」（用戶體驗好），若是有2個或者多個憑證被用於認證，則稱爲「雙因素認證」或「多因素認證」（強度高）。

2.密碼那些事兒

密碼是最多見的一種認證手段。
密碼強度——是設計密碼認證方案時第一個須要考慮的問題，每一個網站在其選擇上，都有本身的策略。目前並無一個標準。筆者介紹的OWASP推薦策略你們能夠參考。
密碼保存——密碼必須以不可逆的加密算法，或者是單項散列函數算法，加密後存儲在數據庫中。目前廣泛作法是將明文密碼通過哈希後（MD5或者SHA-1）再保存到數據庫中，使用MD5加密密碼容易被「彩虹表」方法破解，爲了對抗「彩虹表」類攻擊，在計算密碼明文的哈希值時，能夠增長一個「Salt」。「Salt」是一個隨機字符串，做用是爲了增長明文的複雜度。Salt使用以下：MD5(Username+Password+Salt)。

3.多因素認證

多因素認證提升了攻擊的門檻。好比支付寶是使用了支付密碼、手機動態口令、數字證書、保令、支付盾、第三方證書等進行多因素認證。

4.Session與認證

當認證成功後，就須要替換一個對用戶透明的憑證，這個憑證，就是SessionID。通常會把SessionID加密後保存在Cookie中，由於Cookie會隨着HTTP請求頭髮送，且受到瀏覽器同源策略的保護。
爲了安全，一要保證SessionID的隨機性，二要防止SessionID劫持。

5.Session Fixation攻擊

Session Fixation攻擊過程——攻擊者先獲取到一個未經認證的SessionID，而後將這個SessionID交給用戶去認證，用戶完成認證後，服務器並未更新此SessionID的值，因此攻擊者能夠直接憑藉此SessionID登陸僅用戶的帳戶。
Session Fixation解決方法——在登陸完成後，重寫SessionID。

6.Session保持攻擊

Session保持攻擊1——有一些系統，出於用戶體驗的考慮，只要這個用戶還活着，就不會讓這個用戶的Session失效，從而攻擊者能夠經過不停地發起訪問請求（好比刷新頁面），讓session一直活下去。
Session保持攻擊2——還有不少系統，服務器端並不維護Session，而把Session放在Cookie中加密保存，利用Cookie的Expire標籤來控制Session的失效時間。而Cookie的Expire時間是徹底能夠由客戶端控制的。篡改這個時間並使其永久有效就有可能得到一個永久有效的Session。甚至攻擊者能夠爲Session Cookie增長一個Expire時間，使得本來瀏覽器關閉就會失效的Cookie持久化保存在本地，變成一個第三方Cookie。
如何對抗Session保持攻擊？
- （1）在必定時間後，強制銷燬Session。
- （2）當用戶客戶端發生變化時，要求用戶從新登陸。
- （3）每一個用戶只容許擁有一個Session。

7.單點登陸（Single Sign On，簡稱SSO）

單點登陸實現了用戶只登陸一次，就能夠訪問全部的系統。
它有利有弊，利是風險集中化，只須要保護好這一個點，弊是風險被集中了，單點一旦被攻破，影響的範圍將涉及全部使用單點登陸的系統。
目前最大的單點登陸實現是OpenID，可是發展有限。

四訪問控制

1.What Can I do?

訪問控制——某個主體對某個客體須要實施某種操做，而系統對這種操做的限制就是權限控制。
在Web應用中，根據訪問客體的不一樣，常見的訪問控制能夠分爲基於 URL/方法/數據的訪問控制。
漏洞舉例：有些網站後臺頁面存在未受權訪問漏洞，好比一個後臺管理頁面只有管理員才能夠訪問，它是不會被連接到前臺頁面上的，因此正經常使用戶是不知道的。可是它卻未對用戶訪問權限進行控制，致使任意用戶只要構造出了正確的URL就能夠訪問這些頁面。解決方法只要加上「基於頁面的訪問控制」能夠了。

2.垂直權限管理（又稱爲「基於角色的訪問控制」）

訪問控制就是創建起用戶與權限之間的對應關係，一種應用普遍的方法是基於角色的訪問控制（Role-based Access Control），簡稱RBAC，咱們稱之爲「垂直權限管理」。即高權限角色訪問低權限角色的資源每每是被容許的，而低權限角色訪問高權限角色資源每每被禁止。爲防止發生「越權訪問」，在配置權限時，應該使用「最小權限原則」和「默認拒絕」策略。
舉例：Spring Security中的權限管理就是RBAC模型的一個實現。

3.水平權限管理（又稱爲「基於數據的訪問控制」）

「垂直權限管理」不足之處——同一個角色下的不一樣用戶可能存在私有數據，RBAC模型只會驗證用戶A是否屬於角色RoleX，而不會判斷用戶A可否訪問只屬於用戶B的數據DataB，所以，發生了「越權訪問」。這種問題，咱們就稱之爲「水平權限管理問題」。
水平權限問題與業務需求息息相關，目前並無通用的解決方案，通常是具體問題具體解決。

4.OAuth簡介

OAuth是一個在不提供用戶名和密碼的狀況下，受權第三方應用訪問Web資源的安全協議。好比它能夠使得用戶在不須要向人人網提供MSN用戶名和密碼的狀況下，能夠受權MSN將用戶的好友名單提供給人人網。

五加密算法與隨機數

1.概述

常見的加密算法分爲兩類：
- （1）分組加密算法，好比DES、3-DES、Blowfish、IDEA、AES等。
- （2）流密碼加密算法，好比RC四、ORYX、SEAL等。
針對加密算法的攻擊，根據攻擊者能得到的信息，能夠分爲：惟密文攻擊、已知明文攻擊、選擇明文攻擊、選擇密文攻擊。

2.流密碼加密算法

Stream Cipher Attack——流密碼的加密是基於異或操做的，每次都只操做一個字節。性能好。

流密碼加密算法中的幾種常見攻擊方法：

2.1 Reused Key Attack

在流密碼的使用中，最多見的一個錯誤就是使用同一個密鑰進行屢次加解密，這將使破解流密碼很是簡單。這種攻擊叫作「Reused Key Attack」。在這種攻擊下，攻擊者不須要知道密鑰便可還原出明文。
舉例——破解authcode()函數加密。
延伸——弱隨機IV問題（IV指初始化向量）：在anthcode()函數中，它默認使用了4字節的IV，使得破解的難點增大，但其實4字節的IV是很脆弱的，它不夠隨機，攻擊者能夠經過「暴力破解」的方式找到重複的IV。

2.2 Bit-Flipping Attack

攻擊者在不知道明文的狀況下，經過改變密文，使得明文按其須要的方式發生改變的攻擊方式，被稱爲Bit-Flipping Attack。
解決Bit-Flipping攻擊的方法是驗證密文的完整性。最多見的方法是增長帶有KEY的MAC（Message Authentication Code，消息驗證碼），經過MAC驗證密文是否被篡改。
經過哈希算法來實現的MAC，稱爲HMAC。HMAC因爲其性能較好，而被普遍應用。

2.3 WEP破解

WEP是之前用的無線加密傳輸協議，破解了WEP的密鑰，就能夠免費蹭網了。WEP採用RC4算法，因爲存在漏洞易被破解，目前已經被WPA（全名爲Wi-Fi Protected Access，有WPA和WPA2兩個標準）取代了。

3.分組加密算法中的幾種攻擊方法

3.1 ECB模式的缺陷

對於分組加密算法，除去算法自己，還有一些通用的加密模式，不一樣的加密算法會支持一樣的幾種加密模式。常見的加密模式有：ECB、CBC、CFC、OFB、CTR等，若是加密模式被攻擊，那麼不論加密算法的密鑰有多長，都有可能再也不安全。
ECB模式是最簡單的一種加密模式，它的每一個分組之間相對獨立，改變分組密文的順序，將改變解密後的明文順序；替換某個分組密文，解密後該對應分組的明文也會被替換，而其餘分組不受影響。這與鏈式加密模式（CBC）徹底不一樣，鏈式加密模式的分組先後之間會互相關聯，一個字節的變化，會致使整個密文發生變化。
當須要加密的明文多於一個分組的長度時，應該避免使用ECB模式，而使用其餘更加安全的加密模式。

3.2 Padding Oracle Attack

針對CBC模式的Padding Oracle Attack——它能夠在不知道密鑰的狀況下，經過對padding bytes的嘗試，還原明文，或者構造出任意明文的密文。
padbuster工具能夠自動實施Padding Oracle攻擊。
Padding Oracle Attack的關鍵在於攻擊者可以獲知解密結果是否符合padding。在實現和使用CBC模式的分組加密算法時，注意這一點便可。

4.密鑰管理

在密碼學裏有個基本原則：密碼系統的安全性應該依賴於密鑰的複雜性，而不該該依賴於算法的保密性。
密鑰管理中最多見的錯誤就是將密鑰硬編碼在代碼裏，這樣作大大提升了密鑰泄漏的可能性。
對於web應用，常見的作法是將密鑰（包括密碼）保存在配置文件或者數據庫中，在使用時由程序讀出密鑰並加載進內存，必定不能把密鑰寫入本地文件中。

5.僞隨機數問題

僞隨機數，是經過一些數學算法生成的隨機數，並不是真正的隨機數。密碼學上的安全僞隨機數應該是不可壓縮的。

5.1 弱僞隨機數的麻煩

在WEB應用中，密碼、key、SessionID、token等許多很是關鍵的「secret」都是經過僞隨機數算法生成的，若是使用了弱僞隨機數算法，則可能致使很是嚴重的安全問題。

5.2 時間真的隨機嗎

有的程序員直接使用系統時間代替隨機數生成，這樣生成的隨機數時根據時間順序增加的，能夠從時間上進行預測，從而存在安全隱患。
要切記——不要把時間函數當成隨機數使用。

5.3 破解僞隨機數算法的種子

在PHP中，經常使用的隨機數生成算法有rand()、mt_rand()，最大值分別爲32767（3萬多）、2147483647（約21.5億）。
rand()範圍很是小，若是將其用戶一些重要的地方，將會很是危險。
mt_rand()也有一些缺陷。能夠經過猜想種子，來猜想其產生的僞隨機數。
- 原理：僞隨機數是由數學算法實現的，它真正隨機的地方在於「種子（seed）」。種子一旦肯定後，再經過同一僞隨機數算法計算出來的隨機數，其值是固定的，屢次計算所得值的順序也是固定的。
- 攻擊方式：
  - （1）經過一些方法猜想出種子的值；
  - （2）經過mt_rand()對猜解出的種子值進行播種；
  - （3）經過還原程序邏輯，計算出對應的mt_rand()產生的僞隨機數的值。

5.4 使用安全的隨機數

謹記：在重要或敏感的系統中，必定要使用足夠強壯的隨機數生成算法。好比
- 在java中，能夠使用java.security.SecureRandom；
- 在Linux中，能夠使用/dev/Random或者/dev/urandom；
- 在PHP中，能夠使用openssl_random_pseudo_bytes()函數；
- 其餘，能夠在算法上經過多個隨機數的組合以增長隨機數的複雜性，好比經過給隨機數使用MD5算法後，再鏈接一個隨機字符，而後再MD5算法一次。

6.小結

算法的選擇和使用之最佳實踐：
- （1）不要使用ECB模式；
- （2）不要使用流密碼（好比RC4）；
- （3）使用HMAC-SHA1代替MD5（甚至是代替SHA1）；
- （4）不要使用相同的key作不一樣的事情；
- （5）salts和IV須要隨機產生；
- （6）不要本身實現加密算法，儘可能使用安全專家已經實現好的庫；
- （7）不要依賴系統的保密性。
當你不知道如何選擇時，有如下建議：
- （1）使用CBC模式的AES256用於加密；
- （2）使用HMAC-SHA512用於完整性檢查；
- （3）使用帶salt的SHA-256或SHA-512用於Hashing。

六 Web框架安全

1.MVC框架安全

MVC是Model-VIew-Controller的縮寫，它將Web應用分爲三層，View層負責用戶視圖、頁面展現等工做；Controller負責應用的邏輯實現，接收View層傳入的用戶請求，並轉發給對應的Model作處理；Model層則負責實現模型，完成數據的處理。
從數據的流入來看，用戶提交的數據前後流經了View層、Controller層、Model層，數據的流出則反過來。
優秀的安全方案應該是在正確的地方作正確的事情，好比在View層解決XSS問題，在Model層解決SQL注入問題等等。
在框架中集中實施安全方案，能夠大大節省程序員的工做量，並且能夠使全部基於框架開發的業務都能受益，從安全方案的有效性來講，更容易把握。

2.模板引擎與XSS防護

在當前流行的MVC框架中，View層經常使用的技術是使用模板引擎對頁面進行渲染。
最好的XSS防護方案，是在不一樣的場景使用不一樣的編碼函數，而一些模板引擎倒是統一使用HtmlEncode編碼來防護XSS攻擊，這樣頗有可能會被攻擊者繞過。
不過幸運的是，在模板引擎中能夠以實現自定義的編碼函數，應用於不一樣場景。在Django中是使用自定義filters，在Velocity中則能夠使用「宏」。經過自定義的方法，使得XSS防護功能獲得完善。
在其餘的模板引擎中，也能夠根據「是否有細分場景使用不一樣的編碼方式」來判斷XSS的安全方案是否完整。在使用Web框架時，應該慎重對待安全問題，不可盲從官方文檔。

3.Web框架與CSRF防護

在Web框架中能夠使用security token解決CSRF攻擊的問題。
對應Web框架來講，能夠要求全部的寫操做都使用HTTP POST，自動地在全部涉及POST的代碼中添加token，這些地方包括全部的form表單，全部的Ajex POST請求等。
完整的CSRF防護方案，對於Web框架來講有如下幾處須要改動。
- （1）在Session中綁定token。若是不能保存到服務器端Session中，則能夠替代爲保存到Cookie裏。
- （2）在form表單中自動填入token字段。
- （3）在Ajex請求中自動添加token，這可能須要已有的Ajex封裝實現的支持（通常是插入一個包含了token的HTTP頭，使用HTTP頭是爲了防止Token泄密，由於通常的JavaScript沒法獲取到HTTP頭的信息，可是存在一些跨域漏洞時可能會出現例外）。
- （4）在服務器端對比POST提交參數的token與Session中綁定的token是否一致，以驗證CSRF攻擊。
在Spring MVC以及一些其餘的流行Web框架中，並無直接提供對CSRF的保護，所以這些功能須要本身實現。

4.HTTP Headers管理

在Web框架中，能夠對HTTP頭進行全局化的處理，所以一些基於HTTP頭的安全方案能夠很好地實施。好比
- （1）將Http頭當作Key-Value對，對抗CRLF的方案只需在「value」中編碼全部的\r\n便可（固然了，用戶絕對不能控制key，由於這是很是危險的）；
- （2）在框架中統一管理好跳轉的目的地址，好比指定跳轉地址只能在白名單中，防止被釣魚。
- （3）有不少與安全相關的Headers，也能夠統一在Web框架中配置。好比用來對抗ClickJacking的X-Frame-Options，web框架能夠封裝此功能，並提供頁面配置。
- （4）對全部的Cookie默認添加HttpOnly，不須要此功能的Cookie則單獨在配置文件中列出。

5.數據持久層與SQL注入

對抗SQL注入的最佳方式就是使用「預編譯綁定變量」。
使用ORM（Object/Relation Mapping）框架對SQL注入是有積極意義的。

6.還能想到什麼

凡是在Web框架中可能實現的安全方案，只要對性能沒有太大的損耗，都應該考慮實施。好比：
- （1）在Web框架中爲上傳文件功能提供一個足夠安全的二方庫或者函數；
- （2）保存好安全檢查的日誌；
- （3）與時俱進等。

7.Web框架自身安全

Web框架曾經出現過的嚴重漏洞：
- （1）Struts 2命令執行的漏洞
- （2）從Struts 2的問題補丁能夠看出，其開發者對於安全的理解很是不到位。
- （3）Spring MVC命令執行漏洞
- （4）Django命令執行漏洞

七應用層拒絕服務攻擊

1.DDOS簡介

DDOS又稱爲分佈式拒絕服務，全稱是Distributed Denial of Service。DDOS本質是利用合理的請求形成資源過載，致使服務不可用。
常見的DDOS攻擊有SYN flood（最經典，利用了TCP協議設計中的缺陷）、UDP flood、ICMP flood等。
TCP三層握手過程~~~
SYN flood攻擊過程~~~
對抗SYN flood的措施主要有SYN Cookie/SYN Proxy、safereset等算法。
在不少對抗DDOS的產品中，通常會綜合使用各類算法，結合一些DDOS攻擊的特徵，對流量進行清洗。

2.應用層DDOS—— CC攻擊

CC攻擊原理：對一些消耗資源較大的應用頁面不斷髮起正常的請求以達到消耗服務器資源的目的。
在Web應用中，查詢數據庫、讀寫硬盤文件等操做，相對都會消耗比較多的資源。
應用層DDOS攻擊還能夠經過如下方式完成：在黑客入侵了一個流量很大的網站後，經過篡改頁面，將巨大的用戶流量分流到目標網站。

3.防護應用層DDOS

3.1 限制請求頻率

最多見的針對應用層DDOS攻擊的防護措施，是在應用中針對每一個「客戶端」作一個請求頻率的限制。好比經過IP地址和Cookie定位一個客戶端，若是客戶端的請求在必定時間內過於頻繁，則對以後來自該客戶端的全部請求都重定向到一個出錯頁面。
雖然網站能夠根據IP地址定位攻擊者，可是在實際的攻擊中，攻擊者通常會使用代理服務器或者傀儡機來隱藏本身的真實IP地址，從而繞過服務器對單個IP地址請求頻率的限制了。
解決應用層DDOS攻擊咱們能夠從如下3個方面入手：
- （1）應用代碼作好性能優化。
- （2）在網絡架構上作好優化（好比利用負載均衡進行分流）。
- （3）實現一些對抗手段，好比限制每一個IP地址的請求頻率。

3.2 人機識別

3.2.1 驗證碼的那些事兒——識別人

驗證碼（CAPTCHA）的用戶體驗很差，可是卻可以有效地阻止自動化的重發行爲。
驗證碼破解技術：
- （1）直接利用圖像相關算法識別驗證碼。
- （2）利用Web實現上可能存在的漏洞破解驗證碼。好比
  - 原理1：驗證碼的驗證過程，是對比用戶提交的明文和服務器端Session裏保存的驗證碼明文是否一致。
  - 對應漏洞：由於驗證碼消耗掉後SessionID未更新，致使使用原來的SessionID能夠一直重複提交同一個驗證碼。
  - 原理2：還有的驗證碼實現方式，是提早將全部的驗證碼圖片生成好，以哈希過的字符串做爲驗證碼圖片的文件名。使用驗證碼時，則直接從圖片服務器返回已經生成好的驗證碼。這種設計本來的想法是爲了提升性能。
  - 對應漏洞：這種一一對應的驗證碼文件名會存在一個缺陷：攻擊者能夠事先採用枚舉的方式，遍歷全部的驗證碼圖片，並創建驗證碼到明文之間一一對應關係，從而造成一張「彩虹表」。這也會致使驗證碼形同虛設。修補的方式是驗證碼的文件名須要隨機化，知足「不可預測性」原則。

3.2.2 識別客戶端

通常狀況下，服務器端應用能夠經過判斷HTTP頭中的User-Agent字段來識別客戶端，可是User-Agent是能夠被客戶端篡改的，因此不能信任。一種比較可靠的方法是讓客戶端解析一段JavaScript並給出正確的運行結果，或者發送一個flash讓客戶端解析。但有的客戶端腳本是內嵌在瀏覽器中的「內掛」，那就沒法檢測了。

3.3 其餘

在Apache的配置文件中，有一些參數能夠緩解DDOS攻擊。好比調小Timeout、KeepAliveTimeout值，增大MaxClients值。
目前已經有一些開源的Module所有或者部分實現了真的應用層DDOS攻擊的保護。好比mod_qos、mod_evasive等。
Yahoo的專利。

4.資源耗盡攻擊

4.1 Slowloris攻擊

原理：因爲WebServer對於併發的鏈接數都有必定的上限，所以如果惡意地佔用住這些鏈接不釋放，那麼Web Server的全部鏈接都將被惡意鏈接佔用，從而沒法接受新的請求，致使拒絕服務。
攻擊：在正常的HTTP包頭中，是以兩個CLRF表示HTTP Headers部分結束的。所以攻擊者能夠構造一個不完整的HTTP請求（最後一行只有一個CLRF），Web Server只收到了一個\r\n，所以將認爲HTTP Header部分沒有結束，並保持此鏈接不釋放，繼續等待完整的請求。此時客戶端再發送任意HTTP頭，保持住鏈接便可。當構造多個鏈接後，服務器的鏈接數很快就會達到上限。

4.2 HTTP POST DOS

原理：在發送HTTP POST包時，指定一個很是大的Content-Length值，而後以很低的速度發包，好比10-100s發一個字節，保持住這個鏈接不斷開。這樣當客戶端鏈接數多了之後，佔用住了Web Server的全部可用鏈接，從而致使DOS。

4.3 Server Limit DOS

原理：因爲Web Server限制Request Header最大值爲8192字節，若是客戶端發送的HTTP包頭超過這個大小，服務器就會返回一個4xx錯誤。
攻擊：假設攻擊者經過XSS攻擊，惡意地往客戶端寫入了一個超長的Cookie，因爲Cookie也是放在HTTP包頭中發送的，Web Server默認會認爲這是一個超長的非正常請求，從而致使拒絕服務，則在該客戶端清空Cookie以前，將沒法再訪問該Cookie所在域的任何頁面。
防護：調整Apache配置參數LimitRequestFieldSize，這個參數設置爲0時，對HTTP包頭大小沒有限制。

5 一個正則引起的血案：ReDOS

當正則表達式寫的很差從而被惡意輸入利用，消耗大量資源，致使DOS。這種攻擊被稱爲ReDOS。
原理：當用戶惡意構造輸入時，有缺陷的正則表達式會增長正則引擎解析數據時的消耗，就會消耗大量的系統資源（好比CPU和內存），從而致使整臺服務器的性能降低，表現的結果是系統速度很慢，有的進程或服務失去響應，與拒絕服務的後果是同樣的。

八 PHP安全

1.文件包含漏洞

文件包含是PHP的一種常見用法，主要由4個函數完成：include()、require()、include_once()、require_once()。當使用這4個函數包含一個新的文件時，該文件將做爲PHP代碼執行，PHP內核並不在乎該包含的文件是什麼類型。
利用條件：（1）include()等函數經過動態變量的方式引入須要包含的文件；（2）用戶可以給控制該動態變量。

1.1 本地文件包含漏洞（Local File Inclusion，LFI）

好比這段代碼，include 「/home/wwwrun/」.$file.'php';，用戶能夠控制參數file，當file的值爲「../../etc/passwd」時，PHP將訪問/etc/password.php文件。
可是這個文件是不存在的，攻擊者能夠在最後加入一個0字節，截斷file變量以後的字符串（由於PHP內核是由C語言實現的，在鏈接字符串時，0字節（\x00）將做爲字符串的結束符）。即「../../etc/passwd\0」，經過Web輸入時，只須要URLEncode，變成「../../etc/passwd%00」。
字符截斷技巧，也是文件包含中最經常使用的技巧。但在通常的web應用中，0字節用戶實際上是不須要使用的，所以徹底能夠禁用的。
此時，攻擊者能夠使用另一個技巧，利用操做系統對目錄最大長度的限制，能夠不須要0字節而達到截斷的目的。目錄字符串，在Windows下256字節、Linux下4096字節時會達到最大值，最大值長度以後的字符將被丟棄。如何構造出這麼長的目錄呢？經過「./」便可。好比「./././././././././.abc」或者「////////////abc」或者「../1/abc../1/abc../1/abc」。
本地文件包含漏洞可以讀取敏感文件或者服務器端腳本的源代碼，從而爲攻擊者進一步攻擊奠基基礎。
使用了「../../../」這樣的方式來返回到上層目錄中，這種方式又被稱爲「目錄遍歷」。常見的目錄遍歷漏洞，還能夠經過不一樣的編碼方式來繞過一些服務器端邏輯。好比%2e%2e%2f等同於../等等。
目錄遍歷漏洞是一種跨越目錄讀取文件的方式，但當PHP配置了open_basedir時，將很好地保護服務器，使得這種攻擊無效。open_basedir的值是目錄的前綴，若是要限定一個指定的目錄，則須要在最後加上「/」。
要解決文件包含漏洞，應該儘可能避免包含動態的變量，尤爲是用戶能夠控制的變量。一種變通方法是使用枚舉，將$file的值被枚舉出來，也就避免了任意文件包含的風險。

1.2 遠程文件包含漏洞（Remote File Inclusion，RFI）

攻擊者能夠構造攻擊URL，用來執行任意命令。

1.3 本地文件包含的利用技巧

如下幾種常見技巧，用於本地文件包含後執行PHP代碼。

（1）包含用戶上傳的文件。——最簡單的方法，用戶上傳的文件內容中若是包含PHP代碼，那麼這些代碼被include()加載後將會執行。可是可否攻擊成功，取決於文件上傳功能的設計，好比要求知道用戶上傳後文件所在的物理路徑，有時候這個路徑很難猜到。
（2）包含data://或PHP://input等僞協議。——僞協議須要服務器支持，同時要求allow_url_include設置爲ON。
（3）包含Session文件。——須要攻擊者能控制部分Session文件的內容。
（4）包含日誌文件。——間接地將PHP代碼寫入日誌中，而後包含日誌文件便可。可是當日志文件過大時，PHP進程可能會僵死。所以在凌晨時包含日誌文件將提升攻擊的成功性，由於此時日誌文件可能很是小。
（5）包含/proc/self/environ文件。——它是Web進程運行時的環境變量，其中不少都是用戶能夠控制的，最多見的作法是在User-Agent中注入PHP代碼，完成攻擊。
（6）包含上傳的臨時文件。——以上方法，若是PHP配置了open_basedir，則極可能會失效。但PHP建立的上傳臨時文件，每每處於PHP容許訪問的目錄範圍內。該臨時文件的文件名是隨機的，但並無使用安全的隨機函數，因此能夠使用暴力破解文件名。
（7）包含其餘應用建立的文件，好比數據庫文件、緩存文件、應用日誌等，須要具體狀況具體分析。

2.變量覆蓋漏洞

2.1 全局變量覆蓋

變量若是未被初始化，且能被用戶所控制，那麼極可能會致使安全問題，而在PHP中，這種狀況在register_globals爲ON時尤其嚴重。

2.2 extract()變量覆蓋

extract()函數能將變量從數組導入當前的符號表。當extract()函數從用戶能夠控制的數組中導出變量時，可能發生變量覆蓋。
安全作法是肯定register_globals=OFF後，在調用extract()時使用ECTR_SKIP參數保障已有變量不會被覆蓋，而且extract()的來源數組不能被用戶控制。

2.3 遍歷初始化變量

常見的一些以遍歷的方式釋放變量的代碼，可能致使變量覆蓋。

2.4 import_request_variables變量覆蓋

bool import_request_variable( string $types [, string $prefix])
import_request_variables()將GET、POST、Cookie中的變量導入到全局，使用這個函數只須要簡單地指定類型便可。其中第二個參數是爲導入的變量添加的前綴，若是沒有指定，則將覆蓋全局變量。

2.5 parse_str()變量覆蓋

parse_str()函數每每被用於解析URL的query string，可是當參數值能被用戶控制時，極可能致使變量覆蓋。

2.6 防護變量覆蓋

（1）確保register_globals=OFF。若不能自定義php.ini，則應該在代碼中控制。
（2）熟悉可能形成變量覆蓋的函數和方法，檢查用戶是否能控制變量的來源。
（3）養成初始化變量的好習慣。

3.代碼執行漏洞

條件（1）用戶可以控制函數輸入（2）存在能夠執行代碼的危險函數。

3.1 「危險函數」執行代碼

危險函數popen()、system()、passthru()、exec()等均可以直接執行系統命令。
此外，eval()函數也能夠執行PHP代碼。
3.1.1 phpMyAdmin 3.4.3.1 遠程代碼執行漏洞——這是一個典型的parse_str()覆蓋變漏洞。
3.1.2 MyBB 1.4 遠程代碼執行漏洞——這是一個間接控制eval()函數輸入的漏洞。
挖掘此類漏洞的過程，一般須要先找到危險函數，而後回溯函數的調用過程，最終看整個調用的過程當中用戶是否有可能控制輸入。

3.2 「文件寫入」執行代碼

在PHP中對文件的操做必定要謹慎，若是文件操做的內容用戶能夠控制，則也極容易成爲漏洞。

3.3 其餘執行代碼方式

（1）直接執行代碼的函數

好比eval()、assert()、system()、exec()、shell_exec()、passthru()、escapeshellcmd()、pcntl_exec()等。
最好禁用這些函數。在審計代碼時能夠檢查代碼中是否存在這些函數，而後回溯危險函數的調用過程，看用戶是否能夠控制輸入。

（2）文件包含

高度關注可以包含文件的函數：include()、require()、include_once()、require_once()。

（3）本地文件寫入

重點關注可以往本地文件裏寫入內容的函數，好比file_put_contents()、fwrite()、fputs()等。
注意，寫入文件的功能能夠和文件包含、危險函數執行等漏洞結合，最終使得本來用戶沒法控制的輸入變成可控。在代碼審計時要注意這種「組合類」漏洞。

（4）preg_replace()代碼執行

preg_replace()的第一個參數若是存在/e模式修飾符，則容許代碼執行。
當第一個參數中包含變量，而且用戶可控，有可能經過注入/e%00的方式截斷文本，注入一個「/e」。

（5）動態函數執行

用戶自定義的動態函數能夠致使代碼執行，須要注意這種狀況。

（6）Curly Syntax

PHP的Curly Syntax也能致使代碼執行，它將執行花括號間的代碼，並將結果替換回去。

（7）回調函數執行代碼

不少函數均可以執行回調函數，當回調函數用戶可控時，將致使代碼執行。
能夠執行回調函數的函數有array_map()、ob_start()等。

（8）unserialize()致使代碼執行

unserialize()函數能夠將序列化的數據從新映射爲PHP變量。可是unserialize()在執行時若是定義了__destruct()函數，或者是__wakeup()函數，則這2個函數將執行。
unserialize()代碼執行有2個條件，一是unserialize()的參數用戶能夠控制，這樣能夠構造出須要反序列化的數據結構；二是存在__destruct()函數或者是__wakeup()函數，這2個函數實現的邏輯決定了能執行什麼樣的代碼。

4.定製安全的PHP環境

經過配置php.ini加固PHP的運行環境。

（1）設置register_globals=OFF，防止出現變量覆蓋問題。
（2）給open_basedir設置一個值，限制PHP只能操做指定目錄下的文件。
（3）設置allow_url_include=OFF,allow_url_fopen=OFF，以對抗遠程文件包含。
（4）正式環境中設置display_errors=OFF，log_errors=ON，關閉錯誤回顯，將錯誤信息記錄在日誌中。
（5）推薦magic_quotes_gpc=OFF。
（6）若PHP是以CGI的方式安裝，則須要關閉cgi.fix_pathinfo選項（cgi.fix_pathinfo=0），以免出現文件解析問題。
（7）設置session.cookie_httponly=1，開啓HttpOnly。
（8）如果全站HTTPS則請開啓session.cookie_secure選項（session.cookie_secure=1）。
（9）若是是共享環境（好比APP Engine）則建議開啓安全模式safe_mode（它會影響不少函數），和disable_functions配合使用；若是是單獨的應用環境，則能夠考慮關閉它，更多地依賴於disable_functions控制運行環境安全。
（10）disable_functions可以在PHP中禁用函數。

九 Web Server配置安全

1.Apache安全

（1）檢查Apache安全的第一件事情，就是檢查Apache的Module安裝狀況，根據「最小權限原則」，應該儘量地減小沒必要要的Module，對於要使用的Module，則檢查其對應版本是否存在已知的安全漏洞。
（2）使用單獨的低權限用戶身份運行Apache，這個用戶身份不該該具有shell（必定不要使用root或者admin身份），它惟一的做用就是用來運行Web。
（3）Apache還提供了一些配置參數，能夠用來優化服務器的性能，提升對抗DDOS攻擊的能力。
（4）要保護好 Apache Log。好比實時地發送到遠程的syslog服務器上等，防止黑客入侵後修改、刪除入侵痕跡。

2.Nginx安全

（1）多多關注Nginx的漏洞信息，並及時將軟件升級到安全的版本。
（2）使用單獨的用戶身份運行Nginx。
（3）調整Nginx配置參數，以緩解一些DDOS和CC攻擊。

3.jBoss遠程命令執行

JBoss有一個管理後臺——JMX-Console，默認安裝的JMX-Console是沒有任何認證的，黑客能夠通8080端口訪問/jmx-console進入到這個管理界面。在JMX-Console中，有多種能夠遠程執行命令的方法，最簡單的方法就是經過DeploymentScanner遠程加載一個war包。或者經過JMX-Console提供的BSH Deployment方法，一樣也能夠部署war包。
在加固時，須要刪除JMX-Console後臺，若是由於業務須要不得不使用JMX-Console，則應該使用一個強壯的密碼，且運行JMX-Console的端口不該該面向整個Internet開放。

4.Tomcat遠程命令執行

Tomcat的Tomcat Manager做用與JMX-Console相似，管理員也能夠在Tomcat Manager中部署war包。慶幸的是，Tomcat Manager部署war包須要有manager權限，而這一權限是在配置文件中定義的。須要由管理員修改此文件，定義出manager角色。可是像下面這種配置，就存在安全隱患了。
<role rolename="manager"/>
<user username="tomcat" password="tomcat" roles="tomcat,manager"/>
它直接將Tomcat用戶添加爲manager角色，而Tomcat用戶的密碼極可能是一個默認密碼，這種配置違背了「最小權限原則」。
加固時，強烈建議刪除這一後臺。

5.HTTP Parameter Pollution

HPP攻擊原理：經過GET或者POST向服務器發起請求時，提交兩個相同的參數，好比提交/?a=test1&a=test2，某些服務器環境中，會只取第一個參數或者只取第二個參數，而在另一些環境中，好比.net環境中，則會變成：a=test1,test2。利用這種特性，攻擊者能夠構造一些參數值繞過一些服務器的邏輯判斷。
好比以下代碼：/index.aspx?page=select 1& page=2,3 from table where id=1，經過HPP混淆參數，從而繞過ModSecurity對於SQL注入的檢測。

第四篇互聯網公司安全運營

一互聯網業務安全

1.產品須要什麼樣的安全

若是咱們的產品可以潛移默化地培養用戶的安全習慣，將用戶往更安全的行爲上引導，那麼這樣的安全就是最理想的產品安全。

2.業務邏輯安全

3.帳戶是如何被盜的

4.互聯網的垃圾

垃圾註冊、垃圾消息等的危害及處理

5.關於網絡釣魚

5.1 釣魚網站簡介
5.2 郵件釣魚
- 目前有許多識別發件人郵箱的安全技術，大部分都是基於域名策略的，好比SPF、雅虎的DomainKeys、微軟的Sender ID技術等。
5.3 釣魚網站的防控
- （1）控制釣魚網站的傳播途徑
- （2）直接打擊釣魚網站
- （3）用戶教育
- （4）自動化識別釣魚網站
5.4 網購流程釣魚

6.用戶隱私保護

二安全開發流程（SDL）

1.SDL簡介

SDL全稱是Security Development Lifestyle，即安全開發生命週期。它是由微軟最先提出的。
微軟的SDL過程大體分爲16個階段：
- 培訓（1核心安全培訓）-->
- 要求（2肯定安全要求、3建立質量門/bug欄、4安全和隱私風險評估）-->
- 設計（5肯定設計要求、6分析並減少攻擊面、7威脅建模）-->
- 實施（8使用指定的工具、9棄用不安全的函數、10靜態分析）-->
- 驗證（11動態代碼分析、12模糊測試、13攻擊面評析）-->
- 發佈（14事件響應計劃、15最終安全評析、16發佈存檔）-->
- 響應（17執行時間響應計劃）

2.敏捷SDL

SDL適用於採用瀑布法進行開發的軟件開發團隊，微軟爲敏捷開發專門設計了敏捷SDL，以變化的觀點實施安全工做。

3.SDL實戰經驗

（1）與項目經理進行充分溝通，排出足夠的時間。
（2）規範公司的立項流程，確保全部項目都能通知到安全團隊，避免遺漏。
（3）樹立安所有門的權威，項目必須由安所有門審覈完成後才能發佈。
（4）將技術方案寫入開發、測試的工做手冊中。
（5）給工程師培訓安全方案。
（6）記錄全部的安全bug，激勵程序員編寫安全的代碼。

4.需求分析與設計階段

此階段，安全工程師須要關心產品主要功能上的安全強度和安全體驗是否足夠，主要須要思考安全功能。另外，能夠對項目經理、產品經理或者架構師進程訪談，以瞭解產品背景和技術架構，並給出相應建議。

5.開發階段

開發階段應該力求代碼實現上的安全，作到「安全的功能」。

5.1 提供安全的函數

將安全方案寫入開發規範中，真正地讓安全方案落地。

5.2 代碼安全審計工具

目前尚未比較完美的自動化代碼審計工具，代碼審計工具的結果仍須要人工處理。耗費人力。
實際上，對於甲方公司來講，徹底能夠根據開發規範來定製代碼審計工具。其核心思想是，並不是直接檢查代碼是否安全，而是檢查開發者是否遵照了開發規範。

6.測試階段

安全測試，通常分爲自動化測試和手動測試2種方式。
自動化測試以覆蓋性的測試爲目的，能夠經過「Web安全掃描器」對項目或產品進行漏洞掃描。好比Appscan、skipfish等。
經過掃描器產生的安全報告可能會存在誤報與漏報，須要通過安全工程師確認，並結合手動測試的結果，最終造成一份安全測試報告。

三安全運營

1.把安全運營起來

安全是一個持續的過程，而「安全運營」的目的，就是把這個「持續的過程」執行起來。
公司安全的發展藍圖能夠分爲「Find and Fix」、「Defend and Defer」和「Secure at the source」三個方向，每個方向的最終結果都須要由「安全運營」來保證。

2.創建漏洞修補流程

（1）創建相似bugtracker的漏洞跟蹤機制，併爲漏洞的緊急程度選擇優先級；
（2）創建漏洞分析機制，並與程序員一塊兒制定修補方案，同時review補丁的代碼實現；
（3）對曾經出現的漏洞進行歸檔，並按期統計漏洞修補狀況。

3.安全監控

4.入侵檢測

常見的安全監控產品有IDS（入侵檢測系統）、IPS（入侵防護系統）、DDOS監控設備等。
相對於傳統的IDS，WAF（Web應用防火牆）專一於應用層攻擊的檢測和防護。
優秀的開源WAF有ModSecurity、PHPIDS等。
ModSecurity是Apache的一個Module，它能獲取到全部訪問Apache Httped Server的請求，並根據本身的規則對這些請求進行匹配，以檢測哪些請求存在攻擊行爲。
PHPDIS是爲PHP應用設計的一套入侵檢測系統，它與應用代碼的結合更爲緊密，須要修改應用代碼才能加載並使用它。

5.緊急響應流程