近來,網絡上的SQL Injection 漏洞利用攻擊,JS腳本,HTML腳本攻擊似乎逾演逾烈。陸續的很多站點都被此類攻擊所困擾,並非像主機漏洞那樣可以當即修復,來自於WEB的攻擊方式使我們在防范或者是修復上都帶來了很大的不便。HOOO…… 一個站長最大的痛苦莫過於此。自己的密碼如何如何強壯卻始終被攻擊者得到,但如何才能做到真正意義上的安全呢?第一,別把密碼和你的生活聯系起來;第二,Supermaster的PWD最好只有你自己知道;第三,絕對要完善好你的網站程序。然而怎樣才能完善,這將是我們此文的最終目的。 安全防護,如何做到安全防護?想要防護就要知道對方是如何進行攻擊。有很多文章都在寫如何攻下某站點,其實其攻擊的途徑也不過是以下幾種: 1. 簡單的腳本攻擊 此類攻擊應該屬於無聊搗亂吧。比如****:alert(); </table>等等,由於程序上過濾的不嚴密,使攻擊者既得不到什麼可用的,但又使的他可以進行搗亂的目的。以目前很多站點的免費服務,或者是自身站點的程序上也是有過濾不嚴密的問題。 2. 危險的腳本攻擊 這類腳本攻擊已經過度到可以竊取管理員或者是其他用戶信息的程度上了。比如大家都知道的cookies竊取,利用腳本對客戶端進行本地的寫操作等等。 3. Sql Injection 漏洞攻擊 可以說,這個攻擊方式是從動網論壇和BBSXP開始的。利用SQL特殊字符過濾的不嚴密,而對數據庫進行跨表查詢的攻擊。比如: ?id=999 and 1=1 ?id=999 and 1=2 ?id=999 and 0<>(select count(*) from admin) ?id=999’; declare @a sysname set @a='xp_' 'cmdshell' exec @a 'dir c:\'---&aid=9 得到了管理員的密碼也就意味著已經控制的整站,雖然不一定能得到主機的權限,但也為這一步做了很大的鋪墊。類似的SQL Injection攻擊的方式方法很多,對不同的文件過濾不嚴密所采取的查詢方式也不同。所以說想做好一個完整的字符過濾程序不下一凡功夫是不可能的。 4. 遠程注入攻擊 某站點的所謂的過濾只是在提交表格頁上進行簡單的JS過濾。對於一般的用戶來說,你大可不必防范;對早有預謀的攻擊者來說,這樣的過濾似乎根本沒作用。我們常說的POST攻擊就是其中一例。通過遠程提交非法的信息以達到攻擊目的。 通過上面的攻擊方法的介紹,我們大致的了解了攻擊者的攻擊途徑,下面我們就開始重點的介紹,如何有效的防范腳本攻擊! 讓我們還是從最簡單的開始: l 防范腳本攻擊 JS腳本 和HTML腳本攻擊的防范其實很簡單:server.HTMLEncode(Str)完事。當然你還不要大叫,怎麼可能?你讓我把全站類似<%=uid%>都加過濾我還不累死?為了方便的過濾,自學教程,我們只需要將HTML腳本和JS腳本中的幾個關鍵字符過濾掉就可以了:程序體(1)如下: ‘以下是過濾函數 <% function CHK(fqyString) fqyString = replace(fqyString, ">", ">") fqyString = replace(fqyString, "<", "<") fqyString = replace(fqyString, "", "&") fqyString = Replace(fqyString, CHR(32), " ") fqyString = Replace(fqyString, CHR(9), " ") fqyString = Replace(fqyString, CHR(34), """) fqyString = Replace(fqyString, CHR(39), "'") fqyString = Replace(fqyString, CHR(13), "") fqyString = Replace(fqyString, CHR(10) & CHR(10), "</P><P> ") fqyString = Replace(fqyString, CHR(10), " ") CHK = fqyString end function %> ‘以下是應用實例 <%=CHK(Username)%> Username=CHK(replace(request(“username”),”’”,””)) 使用Include把函數寫在公有頁面上,這樣效率是最好的。 程序體(1) 另外,值得我們注意的是,很多站點在用戶注冊,或者是用戶資料修改的頁面上也缺少腳本的過濾,或者是只在其中之一進行過濾,注冊進入後修改資料仍然可以進行腳本攻擊。對用戶提交的數據進行檢測和過濾,程序體(2) 如下: ‘以下是過濾函數 If Instr(request("username"),"=")>0 or Instr(request("username"),"%")>0 or Instr(request("username"),chr(32))>0 or Instr(request("username"),"?")>0 or Instr(request("username"),"&")>0 or Instr(request("username"),";")>0 or Instr(request("username"),",")>0 or Instr(request("username"),"'")>0 or Instr(request("username"),"?")>0 or Instr(request("username"),chr(34))>0 or Instr(request("username"),chr(9))>0 or Instr(request("username"),"?K")>0 or Instr(request("username"),"$")>0 or Instr(request("username"),">")>0 or Instr(request("username"),"<")>0 or Instr(request("username"),"""")>0 then response.write "朋友,你的提交用戶名含有非法字符,請更改,謝謝合作 <a href='****:window.history.go(-1);'>返回</a>" response.end end if 程序體(2) 為了提供工作效率我們再將過濾內容程序化,這樣對多個參數的過濾效率將有很大程度上的提高:如
程序體(3) ‘以下為程序主體 dim Bword(18) Bword(0)="?" Bword(1)=";" Bword(2)=">" Bword(3)="<" Bword(4)="-" Bword(5)="’" Bword(6)="””" Bword(7)="&" Bword(8)="%" Bword(9)="$" Bword(10)="'" Bword(11)=":" Bword(12)=" " Bword(13)="(" Bword(14)=")" Bword(15)="--" Bword(16)=" chr(9)" Bword(17)=" chr(34)" Bword(18)=" chr(32)" errc=false ‘以下是應用實例部分 for i= 0 to ubound(Bword) if instr(FQYs,Bword(i))<>0 then errc=true end if next if errc then response.write "<script language=""****"">" response.write "parent.alert('很抱歉!您的操作違法了);" response.write "history,back();" response.write "</script>" response.end end if 程序體(3) 有了上面的過濾函數您可以在任何需要過濾的地方應用過濾函數直接使用就可以了。這就使我們的修復工作大大的簡化了。 另外,我想在這裡再次多提醒一下,一些站點的UBB在進行小的表情圖標轉化時也會出現過濾問題,由於很隱蔽所以不容易發現: 如: 我們標簽內的文字進行修改, 不知道各位看懂沒,前一個單引號用來中和程序提供的左引號,第二個單引號用來中和閉合的右引號,這樣程序輸出就為: <img src=’img/0001.gif’ onerror=****:alert(); alt=’’> 如果圖片不存在,5自學網,那麼將激活onerror標簽執行腳本程序。對於已經過濾了單引號的站點在這裡用雙引號一樣可以完成。對於過濾了****字段的,只用alert()也完全可以。所以說要過濾就要過濾完全,別給攻擊者留下一絲機會。 防范SQL Injection 漏洞攻擊 可以這樣說,這裡似乎是整篇文章的重點了.SQL Injection 漏洞攻擊的的多樣化也使得我們在程序防護上不得不想的更多一些。面對SQL Injection 的強大”攻勢”,我們到底該過濾哪些? 一些常用的危險字符有 ' 數據庫字段判別封閉 -- 某些數據庫注釋標志 # 某些數據庫注釋標志 " 可能導致程序出錯 \ 跨越目錄 3221143836nicode 編碼的特征字符 $ 可能用於變量標注 / 和\ 一樣 NULL 小心"空"錄入的危險,可能導致數據庫或系統處理報錯,利用報錯構造溢出. 空格和'一起,構造sql injeciton ? = & 如果存在二次參數傳遞,可能改寫querystr。 (1) 從最一般的.SQL Injection 漏洞攻擊來看:用戶名和密碼上的過濾問題,如: 提交:用戶名為:’or’’=’ 用戶密碼為:’or’’=’ 從程序出發,我們完全可以得出,數據庫在執行以下操作 Sql=” SELECT * FROM lUsers WHERE Username=''or''='' and Password = ''or''=''” 這樣一來,這樣,SQL 服務器將返回 lUsers 表格中的所有記錄,而 ASP 腳本將會因此而誤認為攻擊者的輸入符合 lUsers 表格中的第一條記錄,從而允許攻擊者以該用戶的名義登入網站。對此類注入的防范似乎簡單的很: 利用以下程序就可以實現,程序體(4) strUsername = Replace(Requ