服務器反黑技巧方案二
繼上文服務器反黑技巧方案簡述一之后，本文接著介紹服務器反黑技巧，具體內容如下所述。
方案五
編寫安全的ASP代碼
發帖子的目的是為了大家討論與研究。。。
ASP中數據庫的安全是一個很嚴肅的問題。很多代碼的編寫者意識到了這類問題，并且小心翼翼地對他們認為有問題的地方做了補救，但常見的情況是要么沒有窮盡所有的可疑地點，要么這種補救邏輯上有誤。對于一個耐心且嗅覺靈敏的攻擊者來說，這種意義上的補救措施和沒有任何補救措施沒有本質上區別。
下面羅列的是一些可能出現的問題：有些是常見易犯的錯誤，有些根本就是邏輯上有問題。看看你是不是也這樣寫過？對于攻擊者而言，倒著看這些東西，應該對尋找漏洞有點幫助，更為完整一點的檢測方法，請等我的關于黑/白盒分析和自動化測試文章。
一、令人疑惑的過濾方式
典型例子是不管不顧地對所有的輸入變量都去掉單引號，或者是把單引號替換成合法的兩個單引號，例如：
id=replace(request.querystring("id"),"","")
str=replace(request("someinput"),"","")
現在很明了的是，第一個做法很有可能是錯誤的。因為引起SQLInjection的不總是單引號，再擴大一點，引起問題的不是任何單獨的符號，這樣子的過濾，有些冤枉單引號了。正確的利用注入，重要的一點是閉合前面的一句SQL查詢語句——往往是得先正確地閉合前面一個條件，因為我們可能會在同一句里面引入新的條件，補救措施只要破壞注入條件應該就可以了，但是考慮到其復雜性（下面會說），最好還是較為完整的限制一下輸入的字符種類。
第二個看起來是沒有什么問題的，但潛在的會帶來一些隱患。這很容易給人造成的一個錯覺是，我對輸入的字符串已經很有效的做過處理了，以后使用沒有什么問題。這句話沒有錯，對字符串來說這樣做也是很正確的，但是他扮演了一個不光彩的角色，試想一下，如果過濾后的字符串放進了數據庫，而后續的語句有直接拿出來使用的，這種對前面過濾的依賴性，是不是正確的呢？
也許較好的做法應該是，針對具體的情況來確定過濾的準則。
常見的輸入變量有三種：數字，字符串還有集合。對于數字型的輸入變量，簡單調用一下判斷函數即可，見得到的代碼中，凡是檢查了這類變量的，幾乎都正確。對于字符串型的來說，基本上在插入到生成的SQL語句時，前后都有單引號，如果僅從破壞注入條件來看，把單引號替換成兩個單引號應該問題不大。同理的，如果是一個字符串的集合，也可以簡單的用這種方法。而如果是數字的集合，情況可能稍微麻煩一點，至少你得允許數字、逗號或許還有空格之類的符號在輸入中正常出現，這樣子的過濾規則可能顯得復雜，不過你可以借鑒一下dvBBS6.1打過補丁后的版本，總的來說，對于已經發現的過濾漏洞而言，他們還是補得比較好的。
對于第二句話，至少現在不能說它說錯的，我們留待后面解決。
二、獲取的數據值得信賴嗎？
其實這樣子說范圍顯得有點大，一下子涉及到很多方面，一個例子一個例子地舉來看好了。
首先是關于選擇過濾數據的問題。一直以來，我們認為凡是用戶輸入的東西，都要經過適當的處理。沒錯，但真正的是否都做到呢？隨便找個抓包的工具，比如Ethereal，看看在你用IE提交表單或者是打開連接的時候，都提交了什么。或者，簡單一些，打開NetAnt編輯一個任務，在協議標簽中，看看那個“自定義提交者”和“用戶代理”的選項。
我想你已經明白了，對方可以自己定制的東西不僅僅是GET或POST過來的數據！如果所有的用戶都規規矩矩地用瀏覽器，確實不用防備這么嚴，如果對方不這么老實，在取服務端變量或Cookie的時候可要小心了，沒有任何人能夠保證你獲得的數據是合法的。對于Cookie而言，很多程序都出過問題，所以以前強調得比較多，至于另外的，關注的人可能比較少一點，但你是否看過或者寫過這樣的代碼：
- sql="ShowHOT_COM_inst_online_char2,"&statuserid&","&membername&","&memberclass&","&Request.ServerVariables("REMOTE_HOST")&","&boardid&","&Request.ServerVariables("HTTP_USER_AGENT")&","&replace(stats,"","")&","&Request.ServerVariables("HTTP_X_FORWARDED_FOR")&","&UserGroupID&","&actCome&","&userhidden&","&userid&""
Request.ServerVariables("HTTP_USER_AGENT")就是你在NetAnt中看到的用戶代理選項，也就是說你可以偽造，同樣可以偽造的還有Request.ServerVariables("HTTP_REFERER")，也就是你在NetAnt中看到的提交者選項等等。在做一些項目的時候，很有可能要將這一類的變量添加入數據庫，這時候要千萬小心，這個地方的忽略，引起的后果和其他類型變量未過濾導致的后果是一樣的。
在Google上搜索Referer和Request.ServerVariables兩個關鍵字，還可以看到很多有問題的寫法，或者去看看五月份左右的關于動網論壇入侵的文章，也許你的理解會更加深刻一點。
然后是一個隱藏得稍微深一點的問題，不是用戶的直接輸入要不要過濾？
這就回到了我們前面留下的那個問題，單引號換成兩個單引號的潛在威脅。在第二次構造SQL語句的時候，倘若數據是從數據庫里面直接去取出來用的，多數情況下人們會認為前面已經處理過的東西看起來似乎并沒有必要再處理，或者干脆就是沒有意識到應該處理。這是極其錯誤的！從兩個方面來看，首先你入庫的時候對提交數據中的單引號處理，僅僅是保證了單次SQL語句構造的正確性，并沒有一勞永逸地解決問題；再說了，后面取出數據用的時候，對數據安全性檢查的依賴并沒有得到保證，因為這種依賴關系沒有傳遞下來，而且依賴關系本身還不是可傳的。
就replace(request("someinput"),"","")而言，它的不安定性在于這種過濾方式只是一種妥協，換句話說只是在有限的范圍內掩蓋了可能出現的問題，而沒有永久性的處理掉。它還有一個討厭的地方在于給人一種錯覺，似乎是處理過的數據已經安全了，容易讓后繼的代碼編寫者產生虛幻的安全感。對這兩個弱點，不是*換一個寫法就能解決的，因為如果你把單引號干脆去掉，又會引來另外一個問題，輸入數據中確實有需要而且正確的單引號怎么辦？從一開始我就說，單引號本身是無罪的，過濾它只是一種解決手段而已，所以我們還是就這樣寫吧，不過要在后繼的部分加強一下檢查。
這一類的問題，如果依然用動網論壇做例子，我建議看一下六月八號的漏洞文章。
還有就是過濾器的位置，這個摻雜了邏輯問題在內的復雜問題。
我曾經非常驚奇地發現喬客論壇對外散布的版本中一段讓人覺得不可思議的問題代碼，如果你比較感興趣的話，翻翻gallery.asp就能看到一個特定的動作序列（action=flash_view），繞過了所有對id的檢查。
其實說起來，這一類代碼不太可能有太復雜的邏輯結構，對代碼進行審查的時候，進行所有的分支覆蓋是可以手工完成的，只要稍微想想就會發現對變量的檢查是否能夠有效地到達你的目的地——生成SQL語句的地方。
關于過濾器的位置，如果要深入下去，馬上就會出來一些讓人眼花繚亂的東西，中間的分析很麻煩而且很形式化，雖然確實有算法可以保證位置選取的正確性，但是我想這里還是給出一些結論性的東西吧。倘若你很有興趣，我想你可以來信和我交流。
過濾的位置，取決于兩個方面：你獲得變量的來源，以及你需要保證到的生成SQL語句的位置。前面一個，不論是來自于直接還是間接輸入，先想想可能的輸入字符；對于后面一個，你要保證無論程序運行情況怎樣，經過了過濾語句的流程一定會經過你需要保證到的生成SQL語句的位置（保證其是有效過濾語句的后向必經節點）。如果你不很清楚流程的判斷，我的建議是if中僅僅判斷，if嵌套間不要有多余的東西，過濾語句后緊接生成SQL語句。
再回到前面提到的潛在問題，我們終于可以在這里解決了：在取出數據后依然首先進行判斷。因為根據前面說的，這一種間接輸入依然有可能出現危險。
說到這里，插一句另類的過濾位置問題：不要把對輸入的過濾放到客戶端解決，那是可以繞過的！誰能保證你的VBScript/JavaScript能起作用，如果別人直接用NC或者一個不支持腳本的瀏覽器呢？
上述兩個大的方面，以軟件測試的目光來認識，顯然是沒有窮盡所有的分支所導致。在使用對方提交的數據之前，先做一個對方所有可能進入字符的分析列表，然后就每一種輸入分支情況進行類型的審核，這是每個代碼編寫者都應該做的事情。這是一件很簡單的事情，因為只是類型上的審核還好，碰上語義的問題就麻煩了……
三、類型正確意味著放行？
涉及到語義的問題，要是可能的話，我選擇最好還是避開。
譬如對于一個整型數字，你輸入的確實是一個整型，通過了過濾器，潛在的問題是你的輸入內容上合法嗎，或者根本就不應該從你這里獲得信息？很多年前就有人提出來，有些注冊的模塊存在問題：它里面的id是通過一個type=hidden掩蓋后隱式提交的，但是我在第一步建立了用戶，第二步仍就有可能通過提交內容不合法的id來修改他人的信息。這種異類的問題都是非常難發現，而且幾乎都只有*經驗而不是某一個具體的算法來處理。我們在聯系一下前面的，連起來想想或許能夠更加清楚，對于輸入的字符串，感覺上沒有過濾也不會有錯，因為比較數字之類集合來說，字符串所能容納的幾乎是全部可能輸入的集合。事實上，常見的是沒有過濾造成單引號的錯誤匹配，進而導致了SQLInjection。嚴格說起來，這也是一個語義上的問題，不過對于這樣子的特殊情況而言，可以通過處理輸入中的單引號來保證語義的某種程度上的正確。所以我也一再強調，單引號本身是無罪的，不過是背了語義的黑鍋而已。
令人遺憾的是，如果是整型數據出了語義上的問題，沒有什么東西可以替語義背黑鍋了，所以沒有了一個一定程度上通用的解決方案。不過也不要悲觀，前面就已經說過，能避開就避開，釜底抽薪不要讓可能有語義問題的變量作為輸入好了。
僅僅考慮數據庫安全的話，所有有威脅的語義問題都幾乎出在對數據庫的操作上，那么，我們只要注意update/insert等語句就可以了，如果考慮數據內容的安全性的話，select也得算上。一般來說，特別關注的是生成的where后面的條件語句，總覺得條件的語義應該是由服務器端決定的，而不是說用戶的輸入是什么就是什么。我的建議是對于所有的可能出現語義問題的整型變量，最好都是Session，當然，沒有進行非常深入的研究，或許有人能夠提出像對付字符串的語義問題一樣的有效方法也說不一定。不過話又說回來，在語義層面上看對字符串的過濾，不能證明它不安全，但是更重要的沒有人能夠證明它安全，只是大家現在用著沒有問題，也就默認了罷了。
若要深入的分析語義，也會突然冒出一大堆奇怪的東西，所以還是就此打住吧，真切的希望同行之間能夠多一些這方面的交流！
前面說的也許更多地會用在一些對既有代碼的補救上，如果是從頭開始構架一個軟件的話，上面的僅僅是設計上一些參考。所有的漏洞都是源于設計上的缺陷，一個好的軟件應該被證明其模型是正確的，這很難但是可以做到。如果你一開始就證明了軟件的正確性，我想也不會有漏子可以給別人鉆了。
方案六
防范SQL指令植入式攻擊
發帖子的目的是為了大家討論與研究。。。
什么是SQL指令植入式攻擊？
在設計或者維護Web網站時，你也許擔心它們會受到某些卑鄙用戶的惡意攻擊。的確，如今的Web網站開發者們針對其站點所在操作系統平臺或Web服務器的安全性而展開的討論實在太多了。不錯，IIS服務器的安全漏洞可能招致惡意攻擊；但你的安全檢查清單不應該僅僅有IIS安全性這一條。有些代碼，它們通常是專門為數據驅動(data-driven)的Web網站而設計的，實際上往往同其它IIS漏洞一樣存在嚴重的安全隱患。這些潛伏于代碼中的安全隱患就有可能被稱為“SQL指令植入式攻擊”(SQLinjection)的手段所利用而導致服務器受到攻擊。
SQL指令植入式攻擊技術使得攻擊者能夠利用Web應用程序中某些疏于防范的輸入機會動態生成特殊的SQL指令語句。舉一個常見的例子：
某Web網站采用表單來收集訪問者的用戶名和密碼以確認他有足夠權限訪問某些保密信息，然后該表單被發送到Web服務器進行處理。接下來，服務器端的ASP腳本根據表單提供的信息生成SQL指令語句提交到SQL服務器，并通過分析SQL服務器的返回結果來判斷該用戶名/密碼組合是否有效。
為了實現這樣的功能，Web程序員可能會設計兩個頁面：一個HTML頁面(Login.htm)用于登錄，另一個ASP頁面(ExecLogin.asp)用于驗證用戶權限(即向數據庫查詢用戶名/密碼組合是否存在)。具體代碼可能象這樣：
Login.htm(HTML頁面)
代碼:Username:
Password:
ExecLogin.asp(ASP頁面)
代碼:
乍一看，ExecLogin.asp的代碼似乎沒有任何安全漏洞，因為用戶如果不給出有效的用戶名/密碼組合就無法登錄。然而，這段代碼偏偏不安全，而且它正是SQL指令植入式攻擊的理想目標。具體而言，設計者把用戶的輸入直接用于構建SQL指令，從而使攻擊者能夠自行決定即將被執行的SQL指令。例如：攻擊者可能會在表單的用戶名或密碼欄中輸入包含“or”和“=”等特殊字符。于是，提交給數據庫的SQL指令就可能是：
代碼:SELECT*FROMtblUsersWHEREUsername=or=andPassword=or=
這樣，SQL服務器將返回tblUsers表格中的所有記錄，而ASP腳本將會因此而誤認為攻擊者的輸入符合tblUsers表格中的第一條記錄，從而允許攻擊者以該用戶的名義登入網站。
SQL指令植入式攻擊還有另一種形式，它發生在ASP服務器根據querystring參數動態生成網頁時。這里有一個例子，此ASP頁面從URL中提取出querystring參數中的ID值，然后根據ID值動態生成后繼頁面：
代碼:
在一般情況下，此ASP腳本能夠顯示具有特定ID值的文章的內容，而ID值是由URL中的querystring參數指定的。例如：當URL為http://www.example.com/Article.asp?ID=1055;時，ASP就會根據ID為1055的文章提供的內容生成頁面。
如同前述登錄頁面的例子一樣，此段代碼也向SQL指令植入式攻擊敞開了大門。某些惡意用戶可能會把querystring中的文章ID值偷換為“0or1=1”等內容(也就是說，把URL換成http://www.example.com/Article.asp?ID=0;or1=1)從而誘使ASP腳本生成不安全的SQL指令如：
代碼:SELECT*FROMtblArticlesWHEREID=0or1=1
于是，數據庫將會返回所有文章的內容。
當然了，本例服務器所受的攻擊不一定會引起什么嚴重后果。可是，攻擊者卻可能變本加厲，比如用同樣的手段發送DELETE等SQL指令。這只需要簡單地修改前述URL中的querystring參數就可以了！例如：任何人都可以通過“http://www.example.com/Article.asp?ID=1055;DELETEFROMtblArticles”之類的URL來訪問Web網站。SQL指令植入式攻擊的危害
SQL指令植入式攻擊可能引起的危害取決于該網站的軟件環境和配置。當Web服務器以操作員(dbo)的身份訪問數據庫時，利用SQL指令植入式攻擊就可能刪除所有表格、創建新表格，等等。當服務器以超級用戶(sa)的身份訪問數據庫時，利用SQL指令植入式攻擊就可能控制整個SQL服務器；在某些配置下攻擊者甚至可以自行創建用戶帳號以完全操縱數據庫所在的Windows服務器。
杜絕SQL指令植入式攻擊
杜絕SQL指令植入式攻擊的第一步就是采用各種安全手段監控來自ASPrequest對象(Request、Request.QueryString、Request.Form、Request.Cookies和Request.ServerVariables)的用戶輸入，以確保SQL指令的可*性。具體的安全手段根據你的DBMS而異，下面給出的都是基于MSSQLServer的例子。
在前述登錄頁面的例子中，腳本期望得到的兩個輸入變量(txtUserName和txtPassword)均為字符串類型。無論用戶在哪個參數中插入單引號，他都可能讓數據庫執行單引號中的SQL指令。為了杜絕此類SQL指令植入式攻擊，我們可以借助Replace函數剔除單引號，比如：
代碼:p_strUsername=Replace(Request.Form("txtUsername"),"","")p_strPassword=Replace(Request.Form("txtPassword"),"","")
在第二個例子中，腳本期望的輸入變量是長整型變量(ID)。用戶可以通過在ID參數中插入特殊字符來運行不安全的SQL指令。為了為了杜絕此類SQL指令植入式攻擊，我們只需要借助CLng函數限制ID值為長整型變量，比如：
代碼:p_lngID=CLng(Request("ID"))
當用戶試圖在ID中包含特殊字符時，CLng就會產生一個錯誤。
為了進一步減少SQL指令植入式攻擊的危脅，請務必清除客戶端錯誤信息文本中的所有技術資料。某些錯誤信息往往泄露了技術細節，從而讓攻擊者可以看出服務器的安全漏洞所在。這里指的錯誤信息不但包括應用程序生成的消息框，還包括來自IIS的出錯提示。為此，你可以禁止由IIS發送的詳細錯誤信息，而改用自定義的出錯頁面。(關于創建自定義的出錯頁面的更多信息，請務必參閱《CreatingCustomASPErrorPages》。)
最后，為了減輕SQL指令植入式攻擊的危害，請限制Web應用程序所用的數據庫訪問帳號權限。一般來說，應用程序沒有必要以dbo或者sa的身份訪問數據庫。記住，給它的權限越少，你的網站越安全！你還可以考慮分別給每個需要訪問數據庫的對象分配只擁有必需權限的帳號，以分散安全漏洞。例如：同是前端用戶界面，當用于公共場所時就比用于具有本地內容管理機制的平臺時更加需要嚴格限制數據庫訪問權限。
總結：
希望本系列介紹的服務器反黑技巧能夠對讀者有所幫助，更多有關操作系統的知識還有待于讀者去探索和學習。
【編輯推薦】
