目錄

一、 輸入驗證 3

1. 什么是輸入 3

2. 輸入驗證的必要性 3

3. 輸入驗證技術 3

3.1 主要防御方式 3

3.2 輔助防御方式 5

二、 輸出編碼 8

1. 輸出的種類 8

2. 輸出編碼的必要性 8

3. 輸出編碼 8

4. 常用測試輸出方法 11

三、 防止SQL注入 12

1. 什么是SQL注入 12

2. SQL注入的種類 12

3. 如何防止SQL注入 12

3.1 SQL注入產生的原因 12

3.2主要防御方式 12

3.3 輔助防御方式 15

四、 跨站腳本攻擊 17

1. 什么是跨站腳本攻擊 17

2. 跨站腳本攻擊的危害 17

3. 如何防止跨站腳本攻擊 17

3.1 主要防御方式 17

3.2 輔助防御方式 18

4．XSS漏洞另一個攻擊趨勢 19

五、 跨站請求偽造 21

1. 什么是跨站請求偽造 21

2. 跨站請求偽造的危害 21

3. 如何防止跨站請求偽造 21

3.1主要防御方式 21

3．2輔助防御方式 23

六、 越權操作 24

1. 什么是越權操作 24

2. 越權操作的危害 24

3. 如何防止越權操作 24

七、 IO操作安全 25

八、 緩存泄漏 26

1.什么是緩存泄漏 26

2.防御方法 26

九、 系統加密 27

1. 主要防御方式 27

十、 信息泄露 29

十一、 日志和監測 31

十二、 Web.config的安全配置 32

1.authentication節點 32

2.authorization 節點 32

3.customErrors 節點 32

4.pages 節點 33

十三、 綜合實例講解 34

參考資料 40

一、 輸入驗證
1. 什么是輸入
輸入是編譯時以外的全部數據交換。WEB應用程序從各種來源獲取輸入，例如所有用戶發送的，或者應用程序運行的往返數據（用戶提交的數據、視圖狀態、cookie、查詢字符串參數等），以及后臺數據（數據庫、配置數據和其他數據來源）。所有輸入的數據都會在某種情況下影響請求的處理。[1]

2. 輸入驗證的必要性
為什么輸入驗證如此重要？第一個原因非常明顯：用戶都不希望使用虛假的數據。應用程序會處理這些數據，根據它們得出結果，并最終存儲到后臺數據存儲中。網絡上的其他應用程序有可能在某種情況下需要這些數據，這些程序可能依賴于數據的正確性。（如果這些數據沒有經過驗證，就有可能會帶來麻煩。）[1]
一切從外部獲取的數據都可能是惡意的,如果缺少對數據的驗證，將會帶來很多安全問題。如EMAIL 驗證、用戶名驗證等。如：缺少對EMAIL的長度驗證，在存儲EMAIL時將出現數據庫溢出錯誤。缺少對EMAIL的格式驗證，在發送郵件時將會給程序帶來錯誤等。

3. 輸入驗證技術
3.1 主要防御方式
防御手段一：驗證控件驗證
保護級別:★★★★☆
描述：
對于表現層, 可以利用驗證控件，對用戶輸入的數據進行類型、大小、范圍的驗證。
驗證控件必須做到在客戶端和服務端同時驗證，客戶端的驗證可以減輕對服務端請求的次數和用戶操作的方便性。服務端驗證確保數據的正確性，同時也防止用戶偽造請求繞過客戶端的驗證。
優點： 驗證簡單有效，可重復使用，通常應用于客戶端驗證較多。
缺點： 驗證不完整，有些驗證用戶可以繞過。
應用舉例：
動易SiteFactory系統中,除了使用VS自帶的驗證控件外,還擴展了和增加了部份驗證控件,在PowerEasy.Framework.Controls 命名空間下，可以看到擴展的RequiredFieldValidator 控件，郵箱驗證控件EmailValidator等。具體可以查看文件夾 Core Items 中PowerEasy.Framework.Controls項目下的ExtendedValidator文件夾。這些控件一般使用在用戶輸入的驗證，如注冊時用戶名的驗證：
<pe:RequiredFieldValidator ID="ReqTxtUserName" runat="server" ControlToValidate="TxtUserName"
SetFocusOnError="false" ErrorMessage="用戶名不能為空" Display="None"></pe:RequiredFieldValidator>

防御手段二：業務邏輯層驗證
保護級別:★★★★☆
描述：
關鍵的地方（涉及到點數、金錢、權限）根據情況還需要在業務層或者數據訪問層進行驗證，以保證數據的合法性。對于HTML代碼輸入的地方，輸入時一定要進行HTML格式化處理，否則有可能會引起全局顯示錯誤。如輸入：<!-- （html注釋代碼）等。
優點:驗證的最后防線,確保數據正確。
應用舉例：
動易SiteFactory系統中，在服務端的驗證可以用到數據驗證類，在命名空間PowerEasy.Framework.Common下的 DataValidator 類里的相關函數。如：IsNumber（數字）、IsIP（IP驗證）、IsEmail（郵箱格式驗證）等。這些驗證函數通常應用在緊接著的客戶端驗證，或處理重要數據時的驗證。如：發送郵箱時 SendEMail(string email)函數里的在發送郵件前驗證郵箱是否正確：DataValidator.IsEmail(email)。

防御手段三： 黑名單
保護級別:★★★
描述：
黑名單是看來最簡單的途徑，不過同時也是最不可靠（有可能讓用戶繞過）。但在一些地方也是能起到作用的。
優點：應用簡單，快捷。
缺點：不完全可靠，忘記驗證的幾率高。
應用舉例：
動易SiteFactory系統中，黑名單的應用有如：過濾系統標簽的輸入,先將數據庫中所有系統標簽轉換成別的代替符，標簽解釋完成后再轉換成原字符。函數：PELabelEncode(string value)，PELabelDecode(string value)。又如：系統的過濾函數RemoveXSS也是黑名單的一種利用。適當利用黑名單驗證可以直接過濾掉大部份惡意代碼。

防御手段四：白名單
保護級別:★★★★★
描述：
白名單是開發人員定義的合法條件集合，集合以外的任何情況都被視為非法。白名單可能是允許的字符集合，合法文件名稱列表，或者只是可以接受的數據類型列表。它與黑名單完全相反。由于它把忘記驗證的幾率降到最小，而且更容易實現，擴展性更強，所以白名單更加強大。開發人員在驗證數據時應該始終使用白名單方法。
優點：可靠性高，擴展性強。
缺點：應用范圍較小，通常應用于內容確定的地方。
應用舉例：
動易SiteFactory系統中白名單的應用有（只列出部份）:數據類型轉換：DataConverter 類 CDate CLng 等；
允許上傳文件類型：m_FileExtArr = "gif|png|jpeg|jpg|gif|bmp|fla|swf";
允許使用個別js：AllowString.xml 名件中的白名單；
允許文件接收參數類型：QueryStrings.config。
白名單一般應用在那些比較確定的輸入類型。

3.2 輔助防御方式
除了使用上述技術驗證輸入外,還可以使用以下防御方式確保輸入的正確性。

防御手段一：過濾技術
保護級別:★★★★
描述：
過濾技術是通過特定過濾函數，把不允許的數據內容過濾掉，這種方法能確保數據的正確性，但同時也存在一些過濾不嚴和過濾太嚴的問題，總體來說，這也算是增強系統安全性的一種很有用的方法。
優點：應用范圍較廣，有一定可靠性。
缺點：函數設計考濾煩多，容易忘記需要過濾的內容。
應用舉例：
動易SiteFactory系統中，有多處使用過濾方法，這些過濾函數一般是放在命名空間PowerEasy.Framework.Common下的DataSecurity類和StringHelper類。如：FilterBadChar 函數、FilterSqlKeyword 函數 、RemoveXss 函數等應用。這些函數常用在內容過濾的地方，如RemoveXss函數主要用于跨站腳本的過濾。

防御手段二：強制轉換技術
保護級別:★★★★
描述：
除了過濾外，有時也需要強制轉換，以確保數據正確和程序的正確運行。如數據層中的強制轉換就是一個很好的例子，程序運行到數據層，如果沒有對數據進行強制轉換，程序的出錯將暴出系統錯誤信息或系統的其他機密信息，更重要的是沒有了友好的錯誤提示。
優點：是系統輸入的最后一道防線，比較安全。
缺點：容晚轉換出錯，要帶出錯處理過程。
應用舉例：
動易SiteFactory系統中，強制轉換函數一般放在命名空間PowerEasy.Framework.Common下的DataConverter類里，如：CDate(object input)、CLng(object input)等，還有一些強制轉換防出錯的函數，在命名空間PowerEasy.SqlServerDal中的DBHelper類，如：ToNumber 函數、ToValidId 函數、CLng函數等。經過這雙重保護，確保進入數據庫的數據正確性。

防御手段三：輸出編碼
保護級別:★★★
描述：
輸出編碼也是一種有效的防止HTML注入（XSS攻擊等）的解決方案，具體技術下一章詳細說明。
優點：實現簡單有效。
缺點：只針對特定輸出。

防御手段四：數據庫約束驗證
保護級別:★★★
描述：
數據庫約束是為了保證數據的完整性而實現的一套機制,通過設計數據庫約束,可以限制某些重要字段的數據輸入,如: 非空約束,數據類型約束等。大大增強了系統數據的正確性。
應用舉例：
動易SiteFactory系統中，在數據庫設計方面就考濾到了數據庫約束驗證，因此在數據設計時，就把數據類型都設計好，那些字段允許空，那些不允許都作好了規定。

二、 輸出編碼
1. 輸出的種類
輸出編碼是轉換輸入數據為輸出格式的過程序，輸出格式不包含，或者只是有選擇性的包含允許的特殊字符。
輸出的種類有：
1）支持HTML代碼的輸出
2）不支技HTML代碼的輸出
3）URL的輸出
4）頁面內容的輸出（Keywords、Description等）
5）js腳本的輸出
6）style樣式的輸出
7）xml數據的輸出
8）服務控件的輸出

2. 輸出編碼的必要性
輸出編碼能有效地防止HTML注入（跨站腳本XSS攻擊）等，也能確保輸出內容的完整性和正確性。

3. 輸出編碼
防御手段一：過濾
保護級別：★★★☆
描述:
對于支持HTML代碼的輸出，輸出前要確保代碼中不含有跨站攻擊腳本才能輸出。通過編寫過濾函數，進行強制過濾。
優點：支持HTML，有交防止主流XSS攻擊。
缺點:有可能出錯，函數設計難度大。
應用舉例：
動易SiteFactory系統中，目前而言，主要采用函數RemoveXss進行處理，由于RemoveXss并非十分完善，有待更好的過濾方案。但函數能防止目前主流的XSS攻擊。所以在支持HTML代碼的輸出，一定要通過這個函數進行過濾（也可以輸入到數據庫前過濾）。

防御手段二：HTML編碼
保護級別：★★★★★
描述:
對于不支持HTML的輸出，在輸出到頁面前要進行Server.HtmlEncode編碼，部分服務器控件或者XSLT轉換本身就支持Server.HtmlEncode編碼，可不必進行重復編碼。
優點：非常可靠。
缺點：不支持HTML輸出。
應用舉例：
動易SiteFactory系統中，命名空間PowerEasy.Framework.Common中的DataSecurity類中有自定義的編碼函數：HtmlDecode和HtmlDecode，這些函數更容易地控制編碼的輸出。函數主要用在那些不支持Html的輸出。

防御手段三：URL編碼
保護級別：★★★★★
描述:
對于URL的輸出，要對輸出URL進行Server.UrlEncode處理。
如：<img src="輸出內容" border="0" alt="logo" /> 的輸出
要確保輸出內容的url編碼正確,不允許“ “ “ 的輸出。
優點：可靠性高。
缺點：應用范圍少。
應用舉例：
動易SiteFactory系統中，命名空間PowerEasy.Framework.Common中的DataSecurity類中有自定義的URL編碼函數UrlEncode和UrlEncode來控制所有URL的輸出，以確保輸出的準確性。

防御手段四：轉換特殊符號的編碼形式
保護級別：★★★★★
描述:
對于頁面內容的輸出，要確保輸出的正確性和允許輸出的數據。
如：頁面 <meta content="輸出內容" name="Keywords" /> 的輸出。
要確保輸出內容中不包含特殊符號：“ “ “ 輸出前要轉換特殊符號的編碼形式，將“ “ “ 轉為 " 同樣的輸出有 title="" 的輸出等。

對于js腳本的輸出，要確保輸出代碼中不包含跨站腳本，注意“‘ ”和“”“的輸出，以免被組合成危險的js代碼,還要注意對轉義符號的輸出“/”。
如：圖片模塊，圖片地址的輸出。
又例如下面例子，變量a 和 b 是由用戶輸入,如果用戶輸入a=“/” ，b=“;alert(/xss/);//”，輸入結果后如下：
<script>
a="/";b=";alert(/xxs/);//"
<script>
注意，這就成了 a=“/”;b=” ；alert(/xss/) 后面的注釋了。。

對于style樣式的輸出，要確保樣式的正確性，目前系統主要應用到標題顏色的輸出，如果增加其他樣式的輸出，要確保樣式的安全性才能輸出，也要注入轉義符“/”的輸入。

對于xml數據的輸出，要確保數據中是否有XML不允許的字符，要對特殊字符進行轉換才能輸出。目前系統中還存在一些地方存在這樣的問題。如：標簽的數據源，輸出時沒有對特殊符號進行處理，造成輸出出錯。留言標題中出現“<” 等。

優點：防止因殊符號而出現錯誤，或跨站。
缺點：檢查難度大。
應用舉例：
動易SiteFactory系統中，命名空間PowerEasy.Framework.Common中的DataSecurity類中有自定義的編碼函數XmlEncode等來控制所有輸出，以確保輸出的準確性。防止Html注入的出現。

防御手段五：其他要注意的地方
保護級別：★★★★
描述：
對于服務器控件的輸出，要注意輸出的環境，對于不同的輸出環境進行不同的處理，如url編碼，html編碼等。
除上述輸出外，還有一些特殊的輸出形式，應盡量避免使用，或者處理編碼后再使用。如：
Response.Write(name.Text);
Response.Write(Request.Form["name"]);
QueryString Response.Write(Request.QueryString["name"]);
Cookies Response.Write(Request.Cookies["name"].Values["name"]);
直接輸出 <%=myVariable %>

4. 常用測試輸出方法
常用的測試輸出語句有：
<script>alert('hello');</script>。
1.jpg" onmouseover="alert('xss')
"></a><script>alert(‘xss’);</script>
http://xxx';alert('xss');var/ a='a
‘”>xss&<
對輸出數據到輸出數據的對比，看是否出現問題。

三、 防止SQL注入
1. 什么是SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。通過遞交參數構造巧妙的SQL語句，從而成功獲取想要的數據。

2. SQL注入的種類
從具體而言，SQL注入可分為五大類，分別是：數字型注入、字符型注入、搜索型注入（like）、in型的注入、句語連接型注入。
從應用來說，要特別注意IP、搜索、批量刪除、從數據庫轉到數據庫等地方的SQL注入。

3. 如何防止SQL注入
3.1 SQL注入產生的原因
看下面檢查登陸的SQL語句：
SqlCommand cmd = new SqlCommand("SELECT * FROM PE_USERS WHERE UserName = '"
UserName "' AND UserPassword = '" PassWord "'", conn);
由于沒有對UserName和PassWord進行任何驗證，如果UserName=” admin’ OR 1=1--“
所執行的SQL語句就成了：
SELECT * FROM PE_USERS WHERE UserName=’admin’ OR 1=1―‘ AND UserPassword=’’
這就造成了SQL注入，條件永遠為真，也就不用密碼也能登陸成功。

3.2主要防御方式
防御手段一:參數化查詢
保護級別：★★★★★
描述:
使用參數化查詢的好處：可以防止sql注入式攻擊，提高程序執行效率。
例如:
const string strSql = "SELECT * FROM [PE_Users] WHERE UserName = @UserName";
Parameters parms = new Parameters("@UserName", DbType.String, userName);
中有一個參數@UserName, 使用Prarmeter對象，通過它把參數添加到Command對象上，這樣就獲得參數化查詢。
如上述語句,ADO.NET 會向SQL Server 發送下面的SQL語句:
Exec sp_executesql N ‘select * from [pe_users] where username=@username ‘,N ‘@username nvarchar(20) ‘,@username=N ‘name’
SQL Server 把@username 替換成字符串”name”,然后再執行查詢.
假設有下面的輸入:
‘ union select @@version,null,null―

生成的SQL語句如下所示:
Exec sp_executesql N ‘select * from [pe_users] where username=@username ‘,N ‘@username nvarchar(20) ‘,@username=N ‘’’ union select @@version,null,null--’
可以看到ADO.NET轉義了輸入。
public SqlParameter Add(string parameterName, SqlDbType sqlDbType, int size);
DbTye或SqlDbType可以是多種數據類型。

可根據你的數據類型來選擇。
在某些地方,也可似指定參數的長度:int size。這樣也能有效防止數據庫溢出和SQL注入的可能性。
優點：有效地防止了SQL注入的產生。
缺點：有些地方不能應用，如 in 。
應用舉例：
動易SiteFactory系統中，對于比較固定的地方，我們采用比較安全的存儲過程來實現。系統中所有SQL語句，能用參數化查詢的所有部份都使用了參數化查詢。所有操作數據庫的地方，都能在命名空間 PowerEasy.SqlServerDal下找到。

防御手段二:過濾與轉換
保護級別：★★★★
描述:
對于數據型要強制轉換成數字Clng，對于字符型，要通過函數過濾。如：
private string SafeSqlLiteral(string inputSQL)
{
return inputSQL.Replace("'", "''");
}
對于搜索的地方LIKE 子句，要注意，如果要使用 LIKE 子句，還必須對通配符字符進行轉義：
s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");
對于in類型，要轉換成規格的數字串或字符串。
要盡量少用語句連接形式寫SQL語句，要用到的地方要確保連接語句的安全性，或在白名單內，或限制很短的長度，以防止SQL語句構造的危險。
優點：有效地防止了SQL注入,實現簡單。
缺點：容易遺漏，對于某些地方還是不能過濾，如 order by 變量
應用舉例：
動易SiteFactory系統中，對于不能使用參數化查詢的部份，我們使用過濾函數處理，過濾函數在命名空間PowerEasy.Framework.Common中的DataSecurity類下，如：FilterBadChar函數。這函數主要用于業務邏輯層的過濾，對于數據庫，我們還使用了強制轉換函數，在命名空間 PowerEasy.SqlServerDal 下的 DBHelper 類 ，如：ToValidId 函數等，主要用于數據庫無出錯的處理操作。

防御手段三:白名單
保護級別：★★★★
描述:
對于一些已知的參數范圍，可用白名單的形式處理，能有交防止SQL注入和查詢出錯，如：order by 列名，列名以參數形式傳入時，可制定一個白名單，先判斷一下參數是否在白名單內，再進行查詢，否則出錯處理。
優點：安全可靠
缺點：應用范圍小

3.3 輔助防御方式
防御手段一：嚴格過濾
保護級別：★★★☆
描述：
對于不能參數化查詢或者無法限制變量類型和范圍的情況，使用過濾的手段來處理。對于數據庫中讀取的數量要進入查詢語句，在不確定數據是否安全的情況下，要對其進入過濾。這種SQL注入比較隱蔽，所以要特別注意。
優點：能用于不能參數化而又難過濾的地方，如 order by 變量
缺點: 過濾過于嚴格。
應用舉例：
動易SiteFactory系統中，對于不能使用參數化查詢的部份，我們使用過濾函數處理，過濾函數在命名空間PowerEasy.Framework.Common中的DataSecurity類下，如：FilterBadChar函數。

防御手段二：限定URL傳遞參數的數據類型和范圍
保護級別：★★★
描述：
限定URL的傳遞參數類型、數量、范圍等來防止通過構造URL進行惡意攻擊。參見MSDN雜志
優點：在一定的程序上有效地防止通過URL方式的注入。
缺點：容易遺忘正常需要的參數。
應用舉例：
動易SiteFactory系統中，需要在Config/QueryStrings.config配置文件中增加相應的配置項來控制URL的參數傳入，有效控制每個頁面的參數數量和參數類型。

防御手段三：全局過濾SQL關鍵字過濾
保護級別：★★★
描述：
在某些地方進行全局過濾SQL關鍵字過濾，如對標簽的解釋。（可能存在過濾不完全和限制程序開發的問題）
優點：能用于不能參數化而又難過濾的地方，如 table的連接。
缺點: 過濾過于嚴格。
應用舉例：
動易SiteFactory系統中，對于不能使用參數化查詢的部份，我們使用過濾函數處理，過濾函數在命名空間PowerEasy.Framework.Common中的DataSecurity類下，如：FilterSqlKeyword函數，主要應用在標簽參數的傳入的地方。

更多關于SQL注入，可參考這篇文章：
http://www.microsoft.com/taiwan/msdn/columns/huang_jhong_cheng/LVSS.htm

四、 跨站腳本攻擊
1. 什么是跨站腳本攻擊
跨站腳本攻擊(通常簡寫為XSS)是指攻擊者利用網站程序對用戶輸入過濾不足，輸入可以顯示在頁面上對其他用戶造成影響的HTML代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

2. 跨站腳本攻擊的危害
入侵者便通過技術手段在某個頁面里插入一個惡意HTML代碼，例如記錄論壇保存的用戶信息（Cookie），由于Cookie保存了完整的用戶名和密碼資料，用戶就會遭受安全損失。如這句簡單的Java腳本就能輕易獲取用戶信息：alert(document.cookie)，它會彈出一個包含用戶信息的消息框。入侵者運用腳本就能把用戶信息發送到他們自己的記錄頁面中，稍做分析便獲取了用戶的敏感信息。
跨站腳本攻擊的危險，在如今WEB安全越來越得到重視，他的危險性也越來越大。有效防止跨站腳本攻擊，是WEB程序是否安全的一個重要標準。

3. 如何防止跨站腳本攻擊
3.1 主要防御方式
防御手段一：編碼輸出
保護級別：★★★★★
描述：
對于不支持HTML代碼的地方，可用編碼輸出。如：Server.UrlEncode等方法編碼輸出。
優點：安全可靠。
缺點：不支持HTML代碼。
應用舉例：
動易SiteFactory系統中，命名空間PowerEasy.Framework.Common中的DataSecurity類中有自定義的編碼函數：HtmlDecode和HtmlDecode，這些函數更容易地控制編碼的輸出。函數主要用在那些不支持Html的輸出。

防御手段二：使用UBB編碼
保護級別：★★★★
描述：
UBB代碼是HTML的一個變種,是Ultimate Bulletin Board (國外的一個BBS程序)采用的一種特殊的TAG。它能有效的限制HTML代碼的使用，增強系統輸出的安全性。
優點是：簡單，容易實現，利用白名單形式，易于控制。
缺點是：只支持小量特定html代碼，編輯器功能小。

3.2 輔助防御方式
防御手段一: iframe security="restricted"
保護級別：★★★★
描述：
通過設置iframe security="restricted",能有效防止iframe類的攻擊(對IE有效).
優點：有效防止iframe的攻擊。

防御手段二: HttpOnly
保護級別：★★★★
描述：
設置Cookie的HttpOnly屬性，有效地防止Cookie通過腳本泄密（IE6 SP1以上、Firefox 3）。
優點：有效保護了用戶Cookie信息。
應用舉例：
動易SiteFactory系統中，所有登陸驗證的地方，驗證成功后設置authCookie.HttpOnly = true, 設置Cookie的HttpOnly屬性，這些都應用于用戶登陸成功的地方。

防御手段三: 字符過濾
保護級別：★★★★
描述：
通過函數進行過濾，能有效防止常見腳站腳本的跨站攻擊。主要過濾常見惡意腳本代碼，如：
<applet|meta|xml|blink|link|style|script|embed|object|iframe|frame|frameset|ilayer|layer|bgsound|title|base>
OnX事件代碼、Javascript、Vbscript和Style中的expression、behaviour、script、position等。
但過濾可能存在不完全的情況。建立自己的XSS攻擊庫，方便測試和收集新的攻擊方式，使過濾函數更加完善。
優點：支持HTML，有效防止大部份攻擊代碼。
缺點：可能存在過濾不全的情況。
應用舉例：
動易SiteFactory系統中，目前而言，主要采用函數RemoveXss進行處理，由于RemoveXss并非十分完善，有待更好的過濾方案。但函數能防止目前主流的XSS攻擊。所以在支持HTML代碼的輸出，一定要通過這個函數進行過濾（也可以輸入到數據庫前過濾）。

4．XSS漏洞另一個攻擊趨勢
1）攻擊的本質：
實際上這是一小段JAVASCRIPT，我們只是通過漏洞把這段JS感染到每一個用戶的瀏覽器，但是他不再受系統的限制，任何一個有漏洞的瀏覽器訪問了類似頁面都會受到攻擊。

2）傳播的途徑：
從傳播方式上來說它和傳統的網頁木馬攻擊方式沒有區別，由于這種攻擊對于HTTP請求包括AJAX都沒有域的限制，能使用瀏覽器本地保存的COOKIE，所以可以劫持用戶所有WEB應用的身份，它完全能夠讓已感染主機配合任何網站的應用做蠕蟲式的傳播。

3）攻擊的危害：
我們可以像傳統的僵尸網絡一樣控制大量的瀏覽器肉雞，控制瀏覽器做任意的訪問行為和動作。同時也能針對單個用戶做滲透攻擊，劫持他所有WEB應用的身份，讀取運行本地的任意敏感文件。

4）攻擊的展望：
當Active X等溢出漏洞不再風光的時候，以后利用XSS漏洞針對瀏覽器進行劫持攻擊將是一個大的趨勢。
跨站腳本攻擊，在web2.0時代的現在，越發體現出他的危險性，軟件的漏洞加速了xss攻擊的危險和加劇了這樣攻擊的利用。瀏覽器的漏洞也成為了現今熱門的話題：
更多關于XSS攻擊的文章請看：
http://www.80sec.com/
http://huaidan.org/

五、 跨站請求偽造
1. 什么是跨站請求偽造
CSRF（Cross-site request forgery跨站請求偽造，也被稱成為“one click attack”或者session riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，并且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性。

2. 跨站請求偽造的危害
不要低估了CSRF危害性和攻擊能力！可以說，跨站請求偽造是跨站腳本攻擊的一種深入利用，它的危害性更大。如：給自己提升權限，增加管理員等。可以通過網上的一個案例說明這種攻擊的危害：
Bob在自己的電腦上剛剛查看完自己的銀行A賬戶余額，然后比較無聊就跑到一個公開的BBS上灌水，當他看到一篇“銀行A的內部照片”的帖子，很有興趣的打開這個帖子想看看自己信任的銀行A的內部圖片是啥樣子的，殊不知，這其實是一個attacker精心設計的騙局。在這個帖子中確實有幾個圖片，看上去真的像是銀行A的照片，但是其中有個圖片沒顯示出來，Bob以為是自己網速太慢，導致這個圖片沒有加載進來，也沒在意。只是對這些并不是十分滿意的照片搖搖頭，就關了這個帖子。幾天后，Bob猛然發現自己在銀行A的賬戶上少了1000元，到底是怎么了？
設想一下，Alice編寫了一個在Bob的銀行站點上進行取款的form提交的鏈接，并將此鏈接作為圖片tag。如果Bob的銀行在cookie中保存他的授權信息，并且此cookie沒有過期，那么當Bob的瀏覽器嘗試裝載圖片時將提交這個取款form和他的cookie，這樣在沒經Bob同意的情況下便授權了這次事務。

3. 如何防止跨站請求偽造
3.1主要防御方式
防御手段一：ViewStateUserKey（對應Post方式）
保護級別：★★★★
描述:
ViewStateUserKey 是 Page 類的一個字符串屬性,設置Page.ViewStateUserKey 屬性，防止出現跨站請求偽造攻擊。如果攻擊者使用視圖狀態創建預先填充的 Web 頁（.htm 或 .aspx），則發生跨站請求偽造攻擊。視圖狀態可根據攻擊者先前創建的頁面生成。例如，包含 100 種商品的購物車頁面。攻擊者可引誘信任用戶瀏覽該頁，然后將該頁發送至視圖狀態有效的服務器。服務器不知道該視圖狀態是由攻擊者生成的。由于視圖狀態的有效性，再加上頁面在用戶安全上下文中執行，因此視圖狀態驗證和 MAC 無法對付這種攻擊。為 Page.ViewStateUserKey 屬性設置唯一適合的值，然后作為防止跨站請求偽造攻擊的對策。對于每個用戶而言，這個值必須唯一。通常，它是用戶名或標識符。當攻擊者創建視圖狀態時，常將 ViewStateUserKey 屬性初始化為自己的用戶名。當用戶向服務器提交頁面時，便使用攻擊者的用戶名對該頁進行初始化。因此，視圖狀態 MAC 檢查將失敗，同時出現異常狀況。
優點：有效防止POST方式的跨站請求偽造。
應用舉例：
動易SiteFactory系統中，在后臺操作等重要部份，都設置了ViewStateUserKey驗證。主要在管理頁基類AdminPage 類下設置了ViewStateUserKey屬性。
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
if (HttpContext.Current.Session != null)
{
ViewStateUserKey = Session.SessionID;
if (!IsValidSecurityCode)
{
WriteErrMsg("頁面安全碼校驗失敗！");
}
}

this.CheckPagePermission(); // 檢查頁面權限
}

防御手段二：追加安全驗證碼（對應Get方式）
保護級別：★★★★
描述：
通過對鏈接追加安全驗證碼（HMACSHA1）防止跨站請求偽造。通過將正常請求的頁面 私鑰 用戶SessionID進行哈希加密，通過URL傳遞到操作頁面，保證來訪頁面是指定用戶通過指定操作鏈接來的，從而防止了請求偽造，增加了安全性。
優點：有效防止GET方式的跨站請求偽造。

3．2輔助防御方式
防御手段一：驗證直接地址鏈接和外站鏈接
保護級別：★★★
描述：
禁止通過地址欄直接訪問或者通過外部鏈接訪問后臺管理頁面。
優點：簡單的防止用戶直接對頁面請求造成的管理操作。
缺點：不完全安全，以另一種方式可達到目的。
應用舉例：
動易SiteFactory系統中，可以通過Security.config 的noCheckUrlReferrer 配置，設定可以直接訪問的頁面。新增功能或者新增頁面需要根據情況配置Config/Security.config文件。

六、 越權操作
1. 什么是越權操作
越權操作是指對系統進行超越自己權限的操作。每種會員用戶都有設置自己特定的權限，如果操作越出了自己權限范圍，就是越權操作。

2. 越權操作的危害
越權操作危害性視越權情況而定，如查看收費文章，修改別人的文章，刪除系統的文章資料等操作，有一定的危害性。

3. 如何防止越權操作
對于涉及到用戶和管理員的操作，首先必須檢查操作的合法性。對于合法的操作，還需要檢查操作的數據是否是屬于操作者本人。特別對會員的自身操作，如刪除自己的文章等操作，要檢查數據是否屬于操作者本人，是否有權限執行操作。操作時對身份的驗證一定要引用系統服務端的，不要用用戶可修改的數據進行驗證。如：隱藏的TextBox,Label,Cookie等。
應用舉例：
動易SiteFactory系統中，對于每一操作，都會用命名空間下PowerEasy.AccessManage 的 UserPermissions 類相應函數判斷用戶是否有權限進行操作。

七、 IO操作安全
對上傳文件的實際類型進行檢查，并刪除黑名單中列出類型的文件。上傳采用白名單驗證，確保上傳文件類型的正確性，也防止上傳系統可執行文件，對系統造成危險。如：asp,aspx,php等木馬程序。所有的IO操作都要進行權限判斷、類型檢查，避免惡意用戶上傳木馬文件或者刪除、篡改系統文件。特別對于模板操作，文件夾的建立，建立前檢查文件夾名和文件名是否合法，注意建立這樣 asp.asp 的文件夾（win2003文件夾漏洞）。文件下載頻道要注意下載文件類型的檢查，防止輸入“/../web.config ”形式的地址，以下載本站源文件。瀏覽文件時注意允許瀏覽文件的路徑，是否允許用戶輸入，如果允許，還需要過濾“..”等危險字符，特別注意名件重命名的地方，重命名時最好不要讓用戶更改文件后輟的權限。
應用舉例：
動易SiteFactory系統中,對于文件的操作主要在后臺模板標簽管理那里，對于文件路徑的輸入，除了不能讓用戶修改外，還過濾了“..”等危險字符。對于文件的命名使文件后輟固定而不能被修改。

八、 緩存泄漏
1.什么是緩存泄漏
數據的緩存功能是十分重要的，我們可以把一些在相對一段時間內不發生改變的數據放在緩存中，這樣，就不必要每次去讀取數據庫，當下次再需要這些數據時，可以直接從緩存中取得，大大增強了效率。
但緩存的命名設計和緩存的實現如果處理的不好，就會出現緩存泄漏。什么是緩存泄漏？緩存泄漏是指用戶通過某種手段，利用程序緩存命名漏洞，讀取自己沒有權限得到的緩存內容。看下面例子：
//對標簽進行緩存
string labelcacheid = SiteCacheKey.LabelTransformCacheData labelname "_" labelinfo.OriginalData["cacheid"];
int catchftime = DataConverter.CLng(labelinfo.OriginalData["cachetime"]);
if (catchftime > 0 && SiteCache.Get(labelcacheid) != null)
{
labelinfo = (LabelInfo)SiteCache.Get(labelcacheid);
}
else
{
處理。。。。
}
可以從上面看出，cacheid是由用戶自定義的輸入，如果用戶構造自己不能訪問的緩存內容名稱，就可以讀取其緩存內容了。

2.防御方法
緩存命名最好不要有用戶輸入的部份，若有用戶輸入的部份，即要先檢查用戶權限再訪問緩存。緩存命名的前輟要分好類別，重要數據緩存要用特殊命名。
應用舉例：
動易SiteFactory系統中，對于緩存的命名很有講究：
CK_System_Int_緩存內容
CK_System_String_緩存內容
CK_CommonModel_Int_緩存內容
CK_CommonModel_String_緩存內容
CK_Contents_NodeList_ALL
CK_CommonModel_ModelInfo_ModelId_5
緩存都分有特殊的前輟，防止緩存欺騙。

九、 系統加密
系統的信息加密對系統的安全性非常重要，做好系統的加密工作，有利于確保整個系統的安全。
1. 主要防御方式
防御手段一：完善加密體系
保護級別：★★★★
描述：
一個完善的加密體系，有利于確保密碼的安全性和信息的完整性。
用戶密碼可用哈希加密或采用混合方式加密，檢查密碼強度，記錄密碼更新頻率并進行提示。重要的帳號登錄處需要設置驗證碼以防止暴力破解，并且密碼要定期更新。
結合數據完整性驗證，使得用戶密碼只能在特定程序中才有效。這樣能有效地防止非法手段更改用戶密碼，有完善的加密程序和數據完整性檢查，即使被得到數據庫操作權限也不能得到應用程序的管理權限。
優點：有效確保用戶信息的安全。
缺點：增加密碼管理的難度。
應用舉例：
動易SiteFactory系統中，用戶密碼采用MD5加密，采用密碼強度檢測，都有采用驗證碼保護，對于特殊的地方，有考慮采用數據完整性的檢查，防止非正常程序操作對數據庫的更改，這將在后面版本里出現。

防御手段二：連接字符串加密
保護級別：★★★
描述：
可對連接字符串進行加密（加密文件ConnectionStrings.config），防此用戶非法得到數據庫連接密碼。
優點：能簡單保護數據庫。
應用舉例：
動易SiteFactory系統中,對連接字符串的加密是可選的，可以根據自己的情況，選擇是否對數據庫連接字符串進行加密。

防御手段三：密碼保存位置不同
保護級別：★★★★
描述：
對于重要的系統入口，可有多個密碼，如：管理員密碼，管理認證碼。分別把他們放在不同地方：數據庫與文件中。大大增強系統的安全性。
優點：多重密碼保護系統。
應用舉例：
動易SiteFactory系統中，后臺管理認證碼就是這一個應用，即使非法用戶有數據庫操作權限，不知道后臺管理認證碼也是不能進入系統后臺的,這大大增強了系統的安全性。

防御手段四：保護ViewState
保護級別：★★★
描述：
對重要的視圖數據進行加密處理，默認情況下，視圖狀態是以明文傳輸的，而且有可能暴露信息。使用類似于ViewState Decoder(http://www.pluralsight.com/)的工具，就能重新解碼域的值。所以重要數據最好不要保存到ViewState里，或加密處理。

防御手段五：強命名加密程序集
保護級別：★★★★
描述：
使用強名稱對程序集進行簽名將向包含程序集清單的文件添加公鑰加密。強名稱簽名幫助驗證名稱的唯一性，避免名稱欺騙。強命名程序集可以防止程序集被篡改，強命名的程序集可以部署到GAC(Global Assembly Cache)中，共享多個版本的程序集。
應用舉例：
動易SiteFactory系統就是采用了這種手段來防止程序集被篡改。

十、 信息泄露
如果攻擊者通過探測 Web 頁來找尋引起異常的各種情況，則出現信息泄漏攻擊。對于攻擊者而言，這是一種頗有成效的攻擊方法。因為異常細節信息常以 HTML 的形式返回并顯示在瀏覽器中。這可能會泄漏很有用的信息，如堆棧跟蹤。堆棧跟蹤包含數據庫連接字符串、數據庫名、數據庫方案信息、SQL 語句以及操作系統和平臺版本。

防御手段：錯誤或異常信息處理
保護級別：★★★★
描述：
利用web.config中配置的自定義錯誤頁和全局的異常處理，屏蔽異常出現時暴露的敏感信息。捕獲系統的所有出現異常的地方，做到友好的錯誤提示信息，不要暴露敏感信息。
優點：友好提示，隱藏出錯信息。

防御手段：安全入口盡量進行模糊提示
保護級別：★★★
描述：
對于用戶登陸的地方，在驗證時盡量模糊提示。如：當登陸出錯時都一致提示（用戶名或密碼不正確！）能有效增加密碼暴破的難度。

防御手段：動態表單（防ARP嗅探）
保護級別：★★★
描述：
網絡竊聽、ARP嗅探存在于網絡的任何地方，如何保護WEB程序，確保密碼不被捕獲或增加被捕獲的難度？考慮了常用ARP嗅探軟件的嗅探原理（軟件自動從用戶預先設置好的要獲取的表單字段信息，有選擇性地獲取與用戶名，密碼字段有關的數據包）。
web程序的ARP嗅探技術也在發展中，同一服務器的網站也不能被免，如：WebSniff 1.0，user權限的aspx rawsocket sniff，可用于smtp,http,ftp敏感信息獲取。http://www.cncert.net/DOWN/sinff/2008-7-29/163.html
如果采用動態表單，就增加了ARP嗅探軟件捕獲密碼的難度，因些重要登陸信息都采用隨機表單形式，大大保護了數據包被截取的難度。
優點：簡單而有效地實現了防ARP嗅探。
應用舉例：
動易SiteFactory系統中，在后臺登陸部份就是采用了這種方法，簡單而有效地防止ARP嗅探，這可能是動易SiteFactory系統首創的一種方法。

十一、 日志和監測
做好系統的日志監測，記錄好后臺管理操作和異常情況，有利于監測系統未知漏洞，通過操作日志，還能找出系統出錯或對某些重要操作的管理員、操作時間、IP等信息。有效地預防，檢測,增強系統的安全性。
應用舉例：
動易SiteFactory系統中，對重要的日志都進入了記錄，如：登陸日志、系統錯誤日志、數據庫錯誤日志等。

十二、 Web.config的安全配置
1.authentication節點
<system.web>
<!--配置 ASP.NET 使用的安全身份驗證模式，以標識傳入的用戶。-->
<authentication mode="Forms">
<forms loginUrl="~/User/Login.aspx" name=".ASPXAUTH" defaultUrl="User/Default.aspx" timeout="30" path="/"/>
</authentication>
基于窗體（Forms）的身份驗證配置站點，當沒有登陸的用戶訪問需要身份驗證的網頁，網頁自動跳轉到登陸網頁。其中元素loginUrl表示登陸網頁的名稱，name表示Cookie名稱

2.authorization 節點
<!--配置 Web 應用程序的授權，以控制客戶端對 URL 資源的訪問。-->
<authorization>
<allow users="*"/>
<deny users="?"/>
</authorization>
allow 向授權規則映射添加一個規則，該規則允許對資源進行訪問。
deny 向授權規則映射添加一條拒絕對資源的訪問的授權規則。
users="*" 是指任何用戶 users="?" 是指經身份驗證的用戶
注意: 運行時，授權模塊從最本地的配置文件開始，循環訪問 allow 和 deny 元素，直到它找到適合特定用戶帳戶的第一個訪問規則。然后，該授權模塊根據找到的第一個訪問規則是 allow 還是 deny 規則來允許或拒絕對 URL 資源的訪問。默認的授權規則為 <allow users="*"/>。因此，默認情況下允許訪問，除非另外配置。
如果在根目錄下的web.config配置太繁瑣，可以配置到相應目錄下，例如User目錄下的web.config文件

3.customErrors 節點
<customErrors mode="Off">
</customErrors>
<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">
<error. . ./>
</customErrors>
defaultRedirect 可選的屬性。指定出錯時將瀏覽器定向到的默認 URL。如果未指定該屬性，則顯示一般性錯誤。
Mode 必選的屬性。指定是啟用或禁用自定義錯誤，還是僅向遠程客戶端顯示自定義錯誤。
此屬性可以為下列值之一。
值 說明
On 指定啟用自定義錯誤。如果未指定 defaultRedirect，用戶將看到一般性錯誤。
Off 指定禁用自定義錯誤。這允許顯示標準的詳細錯誤。
RemoteOnly 指定僅向遠程客戶端顯示自定義錯誤并且向本地主機顯示 ASP.NET 錯誤。這是默認值。
默認值為 RemoteOnly。
error 可選的元素。指定給定 HTTP 狀態代碼的自定義錯誤頁。錯誤標記可以出現多次。子標記的每一次出現均定義一個自定義錯誤條件。
例如：
<customErrors mode="RemoteOnly" defaultRedirect="~/Prompt/GenericError.htm">
<error statusCode="403" redirect="~/Prompt/NoAccess.htm"/>
<error statusCode="404" redirect="~/Prompt/FileNotFound.htm"/>
<error statusCode="500" redirect="~/Prompt/GenericError.htm"/>
</customErrors>
這里可以讓用戶自定義出錯頁。

4.pages 節點
<!--全局定義頁特定配置設置，如配置文件范圍內的頁和控件的 ASP.NET 指令。-->
<pages validateRequest="true" styleSheetTheme="UserDefaultTheme">
validateRequest="true"
該值確定 ASP.NET 是否針對危險值檢查來自瀏覽器的輸入。如果 ASP.NET 針對危險值檢查來自瀏覽器的輸入，則為 true；否則為 false。默認值為 true。
這個功能是為了防止跨站腳本等危險代碼。使全局默認為true。只有小數頁面，如搜索頁面
Search.aspx 設為 : ValidateRequest="false" 。為了可以搜索類似<div> 等內容，如果只是文字性的輸入，可修改頁 search.aspx 的設置，以增強系統安全性。

十三、 綜合實例講解
本綜合實例，資料是從網上搜集和個人發現，只講漏洞的存在性和修改方法，與開發語言無關。

實例1: 創力CMS注冊驗證漏洞
漏洞文件：user/Reg.asp 注冊頁面。
Sub Reg_Post() ‘46行 開始
if NameLen > MaxLen or NameLen < MiniLen then '84行
ErrMsg=ObjErr.selectSingleNode("NameLen").text
ErrMsg=Replace(ErrMsg,"{$MaxLen}",MaxLen)
ErrMsg=Replace(ErrMsg,"{$MiniLen}",MiniLen)
Call Cl.OutErr(0,ErrMsg)
else
if Instr(UserName,chr(32))>0 or Instr(UserName,",")>0 or Instr(UserName,chr(34))>0 or Instr(UserName,chr(9))>0 or Instr(UserName,"?")>0 then
Call Cl.OutErr(0,ObjErr.selectSingleNode("NameChar").text)
end if
end If
只對用戶名進行長度檢查，和檢查 chr(32) 空格 , chr(34) " chr(9) tab
但沒對chr(39) ‘ 進行過濾,而程序很多地方調用到用戶名，造成多處SQL注入漏洞。

解決方法：加強輸入驗證，過濾重要字符。

實例 2: DedeCms跨站漏洞