動易安全開發(fā)手冊_動易Cms教程

      編輯Tag賺U幣
      教程Tag:暫無Tag,歡迎添加,賺取U幣!

      目錄

      一、 輸入驗證 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注入產(chǎn)生的原因 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

      九、 系統(tǒng)加密 27

      1. 主要防御方式 27

      十、 信息泄露 29

      十一、 日志和監(jiān)測 31

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

      1.authentication節(jié)點 32

      2.authorization 節(jié)點 32

      3.customErrors 節(jié)點 32

      4.pages 節(jié)點 33

      十三、 綜合實例講解 34

      參考資料 40

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


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


      3. 輸入驗證技術
      3.1 主要防御方式
      防御手段一:驗證控件驗證
      保護級別:★★★★☆
      描述:
      對于表現(xiàn)層, 可以利用驗證控件,對用戶輸入的數(shù)據(jù)進行類型、大小、范圍的驗證。
      驗證控件必須做到在客戶端和服務端同時驗證,客戶端的驗證可以減輕對服務端請求的次數(shù)和用戶操作的方便性。服務端驗證確保數(shù)據(jù)的正確性,同時也防止用戶偽造請求繞過客戶端的驗證。
      優(yōu)點: 驗證簡單有效,可重復使用,通常應用于客戶端驗證較多。
      缺點: 驗證不完整,有些驗證用戶可以繞過。
      應用舉例:
      動易SiteFactory系統(tǒng)中,除了使用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>

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

      優(yōu)點:防止因殊符號而出現(xiàn)錯誤,或跨站。
      缺點:檢查難度大。
      應用舉例:
      動易SiteFactory系統(tǒng)中,命名空間PowerEasy.Framework.Common中的DataSecurity類中有自定義的編碼函數(shù)XmlEncode等來控制所有輸出,以確保輸出的準確性。防止Html注入的出現(xiàn)。

      防御手段五:其他要注意的地方
      保護級別:★★★★
      描述:
      對于服務器控件的輸出,要注意輸出的環(huán)境,對于不同的輸出環(huán)境進行不同的處理,如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&<
      對輸出數(shù)據(jù)到輸出數(shù)據(jù)的對比,看是否出現(xiàn)問題。

      三、 防止SQL注入
      1. 什么是SQL注入

      所謂SQL注入,就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執(zhí)行惡意的SQL命令。通過遞交參數(shù)構造巧妙的SQL語句,從而成功獲取想要的數(shù)據(jù)。

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

      防御手段三: 字符過濾
      保護級別:★★★★
      描述:
      通過函數(shù)進行過濾,能有效防止常見腳站腳本的跨站攻擊。主要過濾常見惡意腳本代碼,如:
      <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攻擊庫,方便測試和收集新的攻擊方式,使過濾函數(shù)更加完善。
      優(yōu)點:支持HTML,有效防止大部份攻擊代碼。
      缺點:可能存在過濾不全的情況。
      應用舉例:
      動易SiteFactory系統(tǒng)中,目前而言,主要采用函數(shù)RemoveXss進行處理,由于RemoveXss并非十分完善,有待更好的過濾方案。但函數(shù)能防止目前主流的XSS攻擊。所以在支持HTML代碼的輸出,一定要通過這個函數(shù)進行過濾(也可以輸入到數(shù)據(jù)庫前過濾)。

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

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

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

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

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

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

      3. 如何防止跨站請求偽造
      3.1主要防御方式
      防御手段一:ViewStateUserKey(對應Post方式)
      保護級別:★★★★
      描述:
      ViewStateUserKey 是 Page 類的一個字符串屬性,設置Page.ViewStateUserKey 屬性,防止出現(xiàn)跨站請求偽造攻擊。如果攻擊者使用視圖狀態(tài)創(chuàng)建預先填充的 Web 頁(.htm 或 .aspx),則發(fā)生跨站請求偽造攻擊。視圖狀態(tài)可根據(jù)攻擊者先前創(chuàng)建的頁面生成。例如,包含 100 種商品的購物車頁面。攻擊者可引誘信任用戶瀏覽該頁,然后將該頁發(fā)送至視圖狀態(tài)有效的服務器。服務器不知道該視圖狀態(tài)是由攻擊者生成的。由于視圖狀態(tài)的有效性,再加上頁面在用戶安全上下文中執(zhí)行,因此視圖狀態(tài)驗證和 MAC 無法對付這種攻擊。為 Page.ViewStateUserKey 屬性設置唯一適合的值,然后作為防止跨站請求偽造攻擊的對策。對于每個用戶而言,這個值必須唯一。通常,它是用戶名或標識符。當攻擊者創(chuàng)建視圖狀態(tài)時,常將 ViewStateUserKey 屬性初始化為自己的用戶名。當用戶向服務器提交頁面時,便使用攻擊者的用戶名對該頁進行初始化。因此,視圖狀態(tài) MAC 檢查將失敗,同時出現(xiàn)異常狀況。
      優(yōu)點:有效防止POST方式的跨站請求偽造。
      應用舉例:
      動易SiteFactory系統(tǒng)中,在后臺操作等重要部份,都設置了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傳遞到操作頁面,保證來訪頁面是指定用戶通過指定操作鏈接來的,從而防止了請求偽造,增加了安全性。
      優(yōu)點:有效防止GET方式的跨站請求偽造。

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

      六、 越權操作
      1. 什么是越權操作

      越權操作是指對系統(tǒng)進行超越自己權限的操作。每種會員用戶都有設置自己特定的權限,如果操作越出了自己權限范圍,就是越權操作。

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

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


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

      八、 緩存泄漏
      1.什么是緩存泄漏
      數(shù)據(jù)的緩存功能是十分重要的,我們可以把一些在相對一段時間內(nèi)不發(fā)生改變的數(shù)據(jù)放在緩存中,這樣,就不必要每次去讀取數(shù)據(jù)庫,當下次再需要這些數(shù)據(jù)時,可以直接從緩存中取得,大大增強了效率。
      但緩存的命名設計和緩存的實現(xiàn)如果處理的不好,就會出現(xiàn)緩存泄漏。什么是緩存泄漏?緩存泄漏是指用戶通過某種手段,利用程序緩存命名漏洞,讀取自己沒有權限得到的緩存內(nèi)容。看下面例子:
      //對標簽進行緩存
      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是由用戶自定義的輸入,如果用戶構造自己不能訪問的緩存內(nèi)容名稱,就可以讀取其緩存內(nèi)容了。

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

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

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

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

      防御手段四:保護ViewState
      保護級別:★★★
      描述:
      對重要的視圖數(shù)據(jù)進行加密處理,默認情況下,視圖狀態(tài)是以明文傳輸?shù)模矣锌赡鼙┞缎畔ⅰJ褂妙愃朴赩iewState Decoder(http://www.pluralsight.com/)的工具,就能重新解碼域的值。所以重要數(shù)據(jù)最好不要保存到ViewState里,或加密處理。

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

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

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

      防御手段:安全入口盡量進行模糊提示
      保護級別:★★★
      描述:
      對于用戶登陸的地方,在驗證時盡量模糊提示。如:當?shù)顷懗鲥e時都一致提示(用戶名或密碼不正確!)能有效增加密碼暴破的難度。


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

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

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

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

      3.customErrors 節(jié)點
      <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 狀態(tài)代碼的自定義錯誤頁。錯誤標記可以出現(xiàn)多次。子標記的每一次出現(xiàn)均定義一個自定義錯誤條件。
      例如:
      <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 節(jié)點
      <!--全局定義頁特定配置設置,如配置文件范圍內(nèi)的頁和控件的 ASP.NET 指令。-->
      <pages validateRequest="true" styleSheetTheme="UserDefaultTheme">
      validateRequest="true"
      該值確定 ASP.NET 是否針對危險值檢查來自瀏覽器的輸入。如果 ASP.NET 針對危險值檢查來自瀏覽器的輸入,則為 true;否則為 false。默認值為 true。
      這個功能是為了防止跨站腳本等危險代碼。使全局默認為true。只有小數(shù)頁面,如搜索頁面
      Search.aspx 設為 : ValidateRequest="false" 。為了可以搜索類似<div> 等內(nèi)容,如果只是文字性的輸入,可修改頁 search.aspx 的設置,以增強系統(tǒng)安全性。

      十三、 綜合實例講解
      本綜合實例,資料是從網(wǎng)上搜集和個人發(fā)現(xiàn),只講漏洞的存在性和修改方法,與開發(fā)語言無關。

      實例1: 創(chuàng)力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) ‘ 進行過濾,而程序很多地方調(diào)用到用戶名,造成多處SQL注入漏洞。

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

      實例 2: DedeCms跨站漏洞


      可以從上面看出,程序沒有對用戶輸入的“’“進行編碼處理輸出,因此造成頁面編碼亂,造成html注入漏洞。

      解決方法:根據(jù)環(huán)境要求,進行編碼輸出。

      實例 3: Discuz!NT 2.5 SQL注入漏洞
      漏洞文件:
      showuser.aspx
      漏洞主要函數(shù):
      GetUserList(int pagesize, int pageindex, string orderby, string ordertype)

      漏洞分析:
      public DataTable GetUserList(int pagesize, int pageindex, string orderby, string ordertype)
      {
      string[] array = new string[] { "username", "credits", "posts", "admin", "lastactivity", "joindate", "oltime" };
      switch (Array.IndexOf<string>(array, orderby))
      {
      case 0:
      orderby = string.Format("ORDER BY [{0}users].[username] {1},[{0}users].[uid] {1}", BaseConfigs.GetTablePrefix, ordertype);
      break;

      case 1:
      orderby = string.Format("ORDER BY [{0}users].[credits] {1},[{0}users].[uid] {1}", BaseConfigs.GetTablePrefix, ordertype);
      break;
      ……
      }
      DbParameter[] commandParameters = new DbParameter[] { DbHelper.MakeInParam("@pagesize", DbType.Double, 4, pagesize), DbHelper.MakeInParam("@pageindex", DbType.Double, 4, pageindex), DbHelper.MakeInParam("@orderby", DbType.AnsiStringFixedLength, 0x3e8, orderby) };
      return DbHelper.ExecuteDataset(4, BaseConfigs.GetTablePrefix "getuserlist", commandParameters).Tables[0];
      }

      從上面可以看出,ordertype沒有過濾就直接進入了SQL查詢,
      ordertype 就是SQL注入的地方,從那里我們可以加入任何SQL語句。如:
      省略..........
      出現(xiàn):
      “/”應用程序中的服務器錯誤。
      ________________________________________
      第 12 行: ',[dnt_users].[uid] asc' 附近有語法錯誤。
      說明: 執(zhí)行當前 Web 請求期間,出現(xiàn)未處理的異常。請檢查堆棧跟蹤信息,以了解有關該錯誤以及代碼中導致錯誤的出處的詳細信息。

      異常詳細信息: System.Data.SqlClient.SqlException: 第 12 行: ',[dnt_users].[uid] asc' 附近有語法錯誤。

      解決方法:對ordertype進行過濾,或用白名單形式處理。


      實例 4: 存儲過程注入舉例
      存儲過程也可能存在SQL注入,由于存儲過程中存在用于字符串連接的 號連接SQL語句,這就造成SQL注入的可能性.
      CREATE PROCEDURE [dbo].[PR_UserManage_Users_BatchMove]
      (
      @UserType int = 1,
      @GroupId NVarChar(500) ='',
      @UserId NVarChar(4000) = '',
      @UserName NVarChar(255) = '',
      @StartUserId int = 0,
      @EndUserId int = 0,
      @BatchUserGroupId NVarChar(500) =''
      )
      AS
      BEGIN
      SET NOCOUNT OFF
      If (@UserType = 1)
      BEGIN
      EXEC('Update PE_Users set GroupID= ' @GroupId ' Where UserID in (' @UserId ')')
      END
      Else If(@UserType = 2)
      BEGIN
      EXEC('Update PE_Users set GroupID= ' @GroupId ' Where UserName in (''' @UserName ''')')
      END
      Else If(@UserType = 3)
      BEGIN
      EXEC('Update PE_Users set GroupID= ' @GroupId ' Where UserId between ' @StartUserId ' and ' @EndUserId)
      END
      Else If(@UserType = 4)
      BEGIN
      EXEC('Update PE_Users set GroupID= ' @GroupId ' Where GroupID in (' @BatchUserGroupId ')')
      END
      END

      可以看出,在用戶名的地方,沒有過濾直接放入查詢,造成in 類型的SQL注入漏洞。

      解決方法:調(diào)用時要對參數(shù)進行過濾

      實例 5: YXBBS任意文件下載漏洞
      漏洞文件: ViewFile.asp
      Function ChkFile(FileName)
      Dim Temp,FileType,F
      ChkFile=false
      FileType=Lcase(Split(FileName,".")(ubound(Split(FileName,"."))))
      Temp="|asp|aspx|cgi|php|cdx|cer|asa|"
      If Instr(Temp,"|"&FileType&"|")>0 Then ChkFile=True
      F=Replace(Request("FileName"),".","")
      If instr(1,F,chr(39))>0 or instr(1,F,chr(34))>0 or instr(1,F,chr(59))>0 then ChkFile=True
      End Function
      可以從上面代碼中看出,代碼是使用黑名單形式,如果名稱中等于列表中的就不能下載,但如果用戶輸入conn.asp ( 是指空格)這樣就能繞黑名單驗證,下載了conn.asp名件。

      解決方法:使用白名單驗證。

      實例 6: 風訊任意文件瀏覽漏洞
      漏洞文件:http://nt.demo.foosun.net/configuration/system/selectPath.aspx
      如圖:

      圖1

      查看源碼:
      string Path = this.str_FilePath base.Request.Form["Path"];
      構造提交表單:
      <form action="http://nt.demo.foosun.net/configuration/system/selectPath.aspx" method=POST >
      <input type="text" name="path"/>
      <input type=submit />
      </form>

      圖 2

      可以看出,系統(tǒng)沒有對“..”進行進濾,于是就造成了這個漏洞。

      解決方法:過濾 “..” 。


      實例 7: KesionCMS瀏覽任意目錄,刪除任意目錄和文件漏洞
      漏洞文件:
      Kesion.WebFilesCls.asp

      漏洞描述:

      <%
      webDir=KS.Setting(3)
      TopDir=Replace(WebDir&Topdir,"http://","/")
      action=LCase(Trim(KS.G("action")))
      CurrentDir=Trim(Replace(KS.G("CurrentDir"),"../",""))
      CurrentPage=KS.ChkClng(KS.G("page"))

      if CurrentDir<>"" then
      CurrentDir=Replace(CurrentDir & "/","http://","/")
      end if
      Set Fso=Server.CreateObject(Trim(KS.Setting(99)))
      Select Case action
      可以看出,上面只過濾“../ ”
      但可以這樣繞過 “…/./” 過濾后就成了“../”。

      解決方法:過濾 “..”


      實例 8: 博客園CuteEditor文件管理漏洞
      CuteEditor編輯品中的插入圖片的都有對以上傳的文件進行操作,但也沒有限制性對“..”的使用,這樣就可以讓用戶復制或移動任意文件到系統(tǒng)任意目錄。

      造成的危害有:
      用戶上傳任意圖片,復蓋博客園中任何圖片(有寫權限目錄)。
      用戶上傳任意js,復蓋博客園中任何js等。

      解決方法:過濾“..”

      參考資料

      [1].開發(fā)更安全的ASP.NET2.0應用程序,[美]Dominick Baier 著,華中宇 田亮君 陳文 譯.人民郵電出版社.2008.7

      http://www.microsoft.com/taiwan/msdn/columns/huang_jhong_cheng/LVSS.htm

      http://technet.microsoft.com/zh-cn/library/ms161953.aspx

      http://www.microsoft.com/china/technet/security/guidance/secmod94.mspx

      http://www.microsoft.com/china/technet/security/guidance/secmod83.mspx

      查看更多 動易Cms教程  動易Cms模板

      來源:模板無憂//所屬分類:動易Cms教程/更新時間:2009-04-02
      相關動易Cms教程