方案一1.打補丁 微軟的作風就是三天一小補，五天一大補，漏洞太多，補一點就好一點，使用“開始-Windows Update" 然後把所有的補丁都裝進去吧 2.刪除默認共用 2.1刪除IPC$共用Win2k 的缺省安裝很容易被攻擊者取得帳號列表，即使安裝了最新的Service ack也是如此。在Win2k中有一個缺省共用IPC$，並且還有諸如admin$ C$ D$等等,而IPC$允許匿名用戶（即未經登錄的用戶）訪問，利用這個缺省共用可以取得用戶列表。如何防範這東東，很簡單在"管理工具\本地安全策略\安 全設定\本地策略\安全選項"中的"對匿名連接的額外限制"可修改為"不允許枚舉SAM帳號和共用"。就可以防止大部分此類連接，但是還沒完，如果使用 NetHacker只要使用一個存在的帳號就又可以順利取得所有的帳號名稱。所以，我們還需要另一種方法做後盾，(1)：創建一個檔startup.cmd，內容就是以下的一行命令"net share ipc$ delete"(不包括引號) (2)：在Windows的計畫任務中增加一項任務執行以上的startup.cmd，時間安排為"電腦啟動時執行"。或者把這個檔放到"開始-程式-啟動"中 讓他一啟動就刪除ipc$共用(3)：重新啟動伺服器。 2.2刪除admin$共用修改登錄檔:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters增加AutoShareWks子鍵（REG_DWORD），鍵值為0 2.3清除默認磁片共用(C$,D$等)修 改登錄檔: ：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters 增加AutoShareServer子鍵（REG_DWORD），鍵值為0 3.修改默認用戶名 "管理工具\本地安全策略\安全設定\本地策略\安全 選項"中"重命名來賓帳戶"就是把"guest"改個名字而已，改成abc或者其他名字，下面機器登陸名字也設為"abc"或其他的名字，然後再把"重命 名系統管理員帳戶"也改一下，有一次我閑著無聊，用小榕的流光隨便掃了一下我的IP段，就發現有N家網吧伺服器的管理員名稱是默認的 Administrator,並且是簡單密碼。如果有人想搞個肉機的話，實在是很簡單。 至此下來，伺服器已經可以很安全穩定的執行下去了，當然別忘了要一兩天重啟一下你的伺服器，SQL伺服器安全設定首先,關閉sql默認的1433(好象是這個吧) 就是把sql的TCP/IP協議刪除就ok了,刪掉後就不能是用遠程了 那總歸少點事情吧sa 設密碼設的密碼為數位加字母等, 不用我多說了吧administrator 別忘了設密碼在tcp/ip協議裏關掉所有的無用埠本地連接狀態 --內容--tcp/ip協定--進階--選項--tcp/ip篩選 --只允許 tcp埠開80(網站埠)開21(ftp埠--可開可不開)55019(奇跡私服埠)44405(奇跡私服埠)以上是針對無路由的使用伺服器直接對外的情況,使用路由的情況見下
映射以下埠就OK了開80(網站埠)開21(ftp埠--可開可不開)55019(奇跡私服埠)44405(奇跡私服埠)當然,上面的你也要設一設哦再來就是asp的安全問題了請使用fishserver這套工具就不存在是用asp漏洞改你資料了這套工具在 夢之奇跡1.05裏有非常方便設定,
方案二丸子的一些安全建議我的伺服器一直沒被黑不知道是人家沒空搭理我還是怎麼的我不推薦防火牆的應為在負荷量大的時候防火牆很容易失效系統的補丁是絕對要打得 最好一個星期一次 上中國微軟站點 用它的自動更新有沒沒用的都打。。。汗~~sql的補丁我沒打過因為直接對sql進行連接達到黑你的目的可能性太小了我的sa密碼是37位元大小寫轉換帶數位的我想沒那麼無聊的駭客去搞那麼大的硬碟和字典來窮舉把況且我的1433是關閉的系統的登錄口令也一樣使用弱智口令會造成嚴重的安全隱患3389埠也要關閉另外關閉一切ICMP的連接我的服武器開的埠不是很多UDP53---DNSUDP8000 UDP4000---QQ80----http*****---mu*****---muTCP5000 5050UDP5050 花生可以說這些埠都是安全的 至少我這麼認為然後我的下一條規則就是禁止所有IP通訊和ICMP通訊我做過測試的 我的是ADSL如果我不開DNS伺服器的埠UDP53那麼我的伺服器都不能上網這些是很簡單的安全策略用2ks的本地安全策略的IP安全策略就可以達到了另外說一下衝擊波的埠 衝擊波病毒是利用了TCP135 TCP4444UDP69這三個埠對你進行攻擊的 關閉了這三個埠基本上衝擊波就over了其實不用刻意去關閉 因為最後一條規則一定要禁止所有IP通訊至少現在是 當然系統的補丁是要全部打得更改DS的埠來防止別人用GS連接你的DS這個似乎是多餘的 因為DS的兩個埠也是對外遮罩的但是我也改了 呵呵
伺服器做到以上的安全設定 基本上沒什麼問題的其實防黑說容易也容易我想沒有那麼多真正意義上的hack來搞你他們沒時間我看了下大家被黑 基本上都是改人改裝備這些都是網頁的漏洞點明轉生的asp這個漏洞很嚴重我去過一個網把 整個網巴的人都會利用這個漏洞進行合法的對sql的操作命令是人家給出來的 只要在轉生asp的密碼那裏輸入指令 就可以繞過伺服器監測了這個也是測試成功的我說的這麼明白 下面的我就不說了吧關閉1433就沒可能被遠端連接到sql了那為什麼我們的sql資料還是被更改了呢？網頁對sql的指令是合法的 因為在config.aso和conn.asp裏面規定了sql的登錄帳號上面我說的那個改人辦法就是利用了這點其實防止網頁漏洞的辦法 也早說過很多次了大家翻翻以前的貼子把如果不是9C和真正意義上的hack搞你上面這些都做到了你的伺服器會比較安全的
以上都是我個人的建議哎。。1433 3389口令補丁這些足夠安全了主要就是注意網頁的漏洞如果不信 當你的服武器改人出現的時候你立刻停止80服務
方案三[討論]被黑的朋友，我個人認為的私服比較安全的方案！其實，看了很多朋友的被黑經歷，我有一個最有效的方法，那就是請大家使用路由器，因為硬體的安全漏洞要比軟體小的多，最便宜的路由器也能使一個頂級駭客耗費1/3的腦細胞和N小時的精力。這是一個簡單的道理，一個防駭客軟體再強大，但他畢竟是建立在伺服器的系統之上的但路由器和硬體防火牆就不一樣，它是獨立的，絕大多數的駭客進攻到路由器就無能為力了（真正能破硬體的，那就是世界級的駭客了，那是少之又少）這也是為什麼電信的防火牆是硬體的道理一樣。有一點大家要注意，用路由器，最好用埠影射，而不要用DMZ，因為DMZ不安全。還有那個遠端倉庫編輯器的埠是1433，不開這個埠，所謂的駭客也就沒辦法了其實只要你的註冊網頁沒有後臺，而你使用路由器，只影射44405，81，21這三個埠，我想全中國幾乎沒有人能黑你的私服，還有你的資料庫應該每天備份一次或定時備份，我想即使被黑，也能在15分鐘內恢復，就不會出現XX私服被戒靈那種不夠駭客資格的人渣黑了，搞的資料庫也沒有了。方案四1、ASP/SQL語句注入：在多都是利用網頁沒有對提交的資料進行過濾而直接帶入資料庫！防：注入語句大多有如下字元：' , % & = ; > < 來構成SQL語句！注意：我們要作的是對寫入資料庫中的每一個欄位都要作過濾！是每一個，千萬不怕麻煩！提供如下過濾語句！'****************************************************if instr(accountname,"'")<>0 or instr(accountname,";")<>0 or instr(accountname,"&")<>0 or instr(accountname,">")<>0 or instr(accountname,",")<>0 or instr(accountname,"=")<>0 or instr(accountname,"%")<>0 thenresponse.write "" response.end end if'****************************************************把accountname改成需要過濾欄位就行了！有多個欄位就要多少個如上的判斷語句！2、異地表單提交！（某此人用來突破原網頁的種種限制）防：禁止異地表單提交！在你的資料庫連接檔(conn.asp)加入如下判斷語句！******************************************************方案五編寫安全的ASP代碼發帖子的目的是為了大家討論與研究。。。ASP中資料庫的安全是一個很嚴肅的問題。很多代碼的編寫者意識到了這類問題，並且小心 翼翼地對他們認為有問題的地方做了補救，但常見的情況是要麼沒有窮盡所有的可疑地點，要麼這種補救邏輯上有誤。對於一個耐心且嗅覺靈敏的攻擊者來說，這種 意義上的補救措施和沒有任何補救措施沒有本質上區別。下面羅列的是一些可能出現的問題：有些是常見易犯的錯誤，有些根本就是邏輯上有問題。看看你是不是也這樣寫過？對於攻擊者而言，倒著看這些東西，應該對尋找漏洞有點幫助，更為完整一點的檢測方法，請等我的關於黑/白盒分析和自動化測試文章。一、令人疑惑的過濾方式典型例子是不管不顧地對所有的輸入變數都去掉單引號，或者是把單引號替換成合法的兩個單引號，例如：id = replace(request.querystring("id"), "", "")str = replace(request("someinput"), "", "")現在很明瞭的是，第一個做法很有可能是錯誤的。因為引起SQL Injection的不總是單引號，再擴大一點，引起問題的不是任何單獨的符號，這樣子的過濾，有些冤枉單引號了。正確的利用注入，重要的一點是閉合前面 的一句SQL查詢語句——往往是得先正確地閉合前面一個條件，因為我們可能會在同一句裏面引入新的條件，補救措施只要破壞注入條件應該就可以了，但是考慮 到其複雜性（下面會說），最好還是較為完整的限制一下輸入的字元種類。第二個看起來是沒有什麼問題的，但潛在的會帶來一些隱患。這很容易給人造成 的一個錯覺是，我對輸入的字串已經很有效的做過處理了，以後使用沒有什麼問題。這句話沒有錯，對字串來說這樣做也是很正確的，但是他扮演了一個不光彩 的角色，試想一下，如果過濾後的字串放進了資料庫，而後續的語句有直接拿出來使用的，這種對前面過濾的依賴性，是不是正確的呢？也許較好的做法應該是，針對具體的情況來確定過濾的準則。常見的輸入變數有三 種：數位，字串還有集合。對於數字型的輸入變數，簡單調用一下判斷函數即可，見得到的代碼中，凡是檢查了這類變數的，幾乎都正確。對於字串型的來說， 基本上在插入到生成的SQL語句時，前後都有單引號，如果僅從破壞注入條件來看，把單引號替換成兩個單引號應該問題不大。同理的，如果是一個字串的集 合，也可以簡單的用這種方法。而如果是數位的集合，情況可能稍微麻煩一點，至少你得允許數字、逗號或許還有空格之類的符號在輸入中正常出現，這樣子的過濾 規則可能顯得複雜，不過你可以借鑒一下dvBBS6.1打過補丁後的版本，總的來說，對於已經發現的過濾漏洞而言，他們還是補得比較好的。對於第二句話，至少現在不能說它說錯的，我們留待後面解決。二、獲取的資料值得信賴嗎？其實這樣子說範圍顯得有點大，一下子涉及到很多方面，一個例子一個例子地舉來看好了。首先是關於選擇過濾資料的問題。一直以來，我們認為凡是用戶輸入的東西，都要經過適當的 處理。沒錯，但真正的是否都做到呢？隨便找個抓包的工具，比如Ethereal，看看在你用IE提交表單或者是打開連接的時候，都提交了什麼。或者，簡單 一些，打開NetAnt編輯一個任務，在協議標籤中，看看那個“自定義提交者”和“用戶代理”的選項。我想你已經明白了，對方可以自己定制的東西 不僅僅是GET或POST過來的數據！如果所有的用戶都規規矩矩地用流覽器，確實不用防備這麼嚴，如果對方不這麼老實，在取服務端變數或Cookie的時 候可要小心了，沒有任何人能夠保證你獲得的資料是合法的。對於Cookie而言，很多程式都出過問題，所以以前強調得比較多，至於另外的，關注的人可能比 較少一點，但你是否看過或者寫過這樣的代碼：sql="ShowHOT_COM_inst_online_char 2,"&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來修改他 人的資訊。這種異類的問題都是非常難發現，而且幾乎都只有*經驗而不是某一個具體的演算法來處理。我們在聯繫一下前面的，連起來想想或許能夠更加清楚，對於 輸入的字串，感覺上沒有過濾也不會有錯，因為比較數位之類集合來說，字串所能容納的幾乎是全部可能輸入的集合。事實上，常見的是沒有過濾造成單引號的 錯誤匹配，進而導致了SQL Injection。嚴格說起來，這也是一個語義上的問題，不過對於這樣子的特殊情況而言，可以通過處理輸入中的單引號來保證語義的某種程度上的正確。所 以我也一再強調，單引號本身是無罪的，不過是背了語義的黑鍋而已。令人遺憾的是，如果是整型資料出了語義上的問題，沒有什麼東西可以替語義背黑鍋了，所以沒有了一個一定程度上通用的解決方案。不過也不要悲觀，前面就已經說過，能避開就避開，釜底抽薪不要讓可能有語義問題的變數作為輸入好了。僅 僅考慮資料庫安全的話，所有有威脅的語義問題都幾乎出在對資料庫的操作上，那麼，我們只要注意update/insert等語句就可以了，如果考慮資料內 容的安全性的話，select也得算上。一般來說，特別關注的是生成的where後面的條件語句，總覺得條件的語義應該是由伺服器端決定的，而不是說用戶 的輸入是什麼就是什麼。我的建議是對於所有的可能出現語義問題的整型變數，最好都是Session，當然，沒有進行非常深入的研究，或許有人能夠提出像對 付字串的語義問題一樣的有效方法也說不一定。不過話又說回來，在語義層面上看對字串的過濾，不能證明它不安全，但是更重要的沒有人能夠證明它安全，只 是大家現在用著沒有問題，也就默認了罷了。若要深入的分析語義，也會突然冒出一大堆奇怪的東西，所以還是就此打住吧，真切的希望同行之間能夠多一些這方面的交流！前面說的也許更多地會用在一些對既有代碼的補救上，如果是從頭開始構架一個軟體的話，上 面的僅僅是設計上一些參考。所有的漏洞都是源於設計上的缺陷，一個好的軟體應該被證明其模型是正確的，這很難但是可以做到。如果你一開始就證明了軟體的正 確性，我想也不會有漏子可以給別人鑽了。方案六防範SQL指令植入式攻擊發帖子的目的是為了大家討論與研究。。。什麼是SQL 指令植入式攻擊？ 在設計或者維護 Web 網站時，你也許擔心它們會受到某些卑鄙用戶的惡意攻擊。的確，如今的 Web 網站開發者們針對其站點所在作業系統平臺或Web 伺服器的安全性而展開的討論實在太多了。不錯，IIS 伺服器的安全漏洞可能招致惡意攻擊；但你的安全檢查清單不應該僅僅有 IIS 安全性這一條。有些代碼，它們通常是專門為資料驅動(data-driven) 的 Web 網站而設計的，實際上往往同其他 IIS 漏洞一樣存在嚴重的安全隱患。這些潛伏于代碼中的安全隱患就有可能被稱為“SQL 指令植入式攻擊” (SQL injection) 的手段所利用而導致伺服器受到攻擊。 SQL 指令植入式攻擊技術使得攻擊者能夠利用 Web 應用程式中某些疏於防範的輸入機會動態生成特殊的 SQL 指令語句。舉一個常見的例子： 某 Web 網站採用表單來收集訪問者的用戶名和密碼以確認他有足夠許可權訪問某些保密資訊，然後該表單被發送到 Web 伺服器進行處理。接下來，伺服器端的ASP 腳本根據表單提供的資訊生成 SQL 指令語句提交到 SQL 伺服器，並通過分析 SQL 伺服器的返回結果來判斷該用戶名/密碼組合是否有效。
為了實現這樣的功能，Web 程式師可能會設計兩個頁面：一個 HTML 頁面 (Login.htm) 用於登錄，另一個ASP 頁面 (ExecLogin.asp) 用於驗證用戶許可權(即向資料庫查詢用戶名/密碼組合是否存在)。具體代碼可能象這樣： Login.htm (HTML 頁面) ＜FORM action=ExecLogin.asp method="post"＞Username: Password: ExecLogin.asp (ASP 頁面)
代 碼:＜% Dim p_strUsername, p_strPassword, objRS, strSQL p_strUsername = Request.Form("txtUsername") p_strPassword = Request.Form("txtPassword") strSQL = "SELECT * FROM tblUsers " & _ "WHERE Username=" & p_strUsername & _ " and Password=" & p_strPassword & "" Set objRS = Server.CreateObject("ADODB.Recordset") objRS.Open strSQL, "DSN=..." If (objRS.EOF) Then Response.Write "Invalid login." Else Response.Write "You are logged in as " & objRS("Username") End If Set objRS = Nothing %>
乍一看，ExecLogin.asp 的代碼似乎沒有任何安全漏洞，因為用戶如果不給出有效的用戶名/密碼組合就無法登錄。然而，這段代碼偏偏不安全，而且它正是SQL 指令植入式攻擊的理想目標。具體而言，設計者把用戶的輸入直接用於構建SQL 指令，從而使攻擊者能夠自行決定即將被執行的 SQL 指令。例如：攻擊者可能會在表單的用戶名或密碼欄中輸入包含“ or ”和“=” 等特殊字元。於是，提交給資料庫的 SQL 指令就可能是： 代碼:SELECT * FROM tblUsers WHERE Username= or = and Password = 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 值偷換為“0 or 1=1”等內容(也就是說，把 URL 換成 http://www.example.com/Article.asp?ID=0 or 1=1) 從而誘使 ASP 腳本生成不安全的 SQL 指令如： 代碼:SELECT * FROM tblArticles WHERE ID=0 or 1=1 於是，資料庫將會返回所有文章的內容。 當然了，本例伺服器所受的攻擊不一定會引起什麼嚴重後果。可是，攻擊者卻可能變本加厲，比如用同樣的手段發送 DELETE 等 SQL 指令。這只需要簡單地修改前述 URL 中的 querystring 參數就可以了！例如：任何人都可以通過 “http://www.example.com/Article.asp?ID=1055; DELETE FROM tblArticles ” 之類的 URL 來訪問 Web 網站。 SQL 指令植入式攻擊的危害 SQL 指令植入式攻擊可能引起的危害取決於該網站的軟體環境和配置。當 Web 伺服器以操作員(dbo)的身份訪問資料庫時，利用SQL 指令植入式攻擊就可能刪除所有表格、創建新表格，等等。當伺服器以超級用戶 (sa) 的身份訪問資料庫時，利用SQL 指令植入式攻擊就可能控制整個 SQL 伺服器；在某些配置下攻擊者甚至可以自行創建用戶帳號以完全操縱資料庫所在的 Windows 伺服器。 杜絕SQL 指令植入式攻擊 杜絕SQL 指令植入式攻擊的第一步就是採用各種安全手段監控來自 ASP request 物件 (Request 、 Request.QueryString 、 Request.Form 、 Request.Cookies 和 Request.ServerVariables) 的用戶輸入，以確保 SQL 指令的可*性。具體的安全手段根據你的 DBMS 而異，下面給出的都是基於 MS SQL Server的例子。 在前述登錄頁面的例子中，腳本期望得到的兩個輸入變數 (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 發送的詳細錯誤資訊，而改用自定義的出錯頁面。(關於創建自定義的出錯頁面的更多資訊，請務必參閱 《Creating Custom ASP Error Pages》。)
最後，為了減輕SQL 指令植入式攻擊的危害，請限制 Web 應用程式所用的資料庫訪問帳號許可權。一般來說，應用程式沒有必要以 dbo 或者 sa 的身份訪問資料庫。記住，給它的許可權越少，你的網站越安全！你還可以考慮分別給每個需要訪問資料庫的物件分配只擁有必需許可權的帳號，以分散安全漏洞。例 如：同是前端用戶介面，當用於公共場所時就比用於具有本地內容管理機制的平臺時更加需要嚴格限制資料庫訪問許可權。 相關資料 在 Internet 上有許許多多關於本話題的有用資源。我想下列連接可能會對你有所幫助： * SQL Injection FAQ (http://www.sqlsecurity.com/) * Advanced SQL Injection White Paper (http://www.nextgenss.com/research.html) * Preventing SQL Injection (http://www.owasp.org/asac/input_validation/sql.shtml)