當前位置:首頁 » 編程語言 » 代碼檢查防止sql注入
擴展閱讀
故宮的密碼是什麼 2022-08-13 01:49:33
資料庫存儲工程接收數據 2022-08-13 01:49:33
插上移動硬碟電腦就卡 2022-08-13 01:49:29

代碼檢查防止sql注入

發布時間: 2022-08-06 10:23:45

A. 如何避免代碼中出現sql注入

普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句,那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象,故要操作這個語句用戶必須有相關的許可權。在許可權設計中,對於終端用戶,即應用軟體的使用者,沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼,由於其用戶許可權的限制,這些代碼也將無法被執行。故應用程序在設計的時候,

強迫使用參數化語句。
如果在編寫SQL語句的時候,用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話,那麼就可以有效的防治SQL注入式攻擊。也就是說,用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反,用戶的輸入的內容必須進行過濾,或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施,可以杜絕大部分的SQL注入式攻擊。不過可惜的是,現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。

多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響,在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中,工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話,則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼,則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查,范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束,就會發生異常,並報告給管理員。如上面這個案例中,如果員工編號定義的數據類型為字元串型,長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據,但是其長度達到了20個字元。則此時就會引發異常,因為用戶輸入的內容長度超過了資料庫欄位長度的限制。

加強對用戶輸入的驗證。
總體來說,防治SQL注入式攻擊可以採用兩種方法,一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中,有比較多的用戶輸入內容驗證工具,可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容,只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入,防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型,強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出,對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾,如拒絕一些特殊的符號。如以上那個惡意代碼中,只要存儲過程把那個分號過濾掉,那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前,可以通過資料庫的存儲過程,來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下,應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符,它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容,故可以直接把他拒絕掉,通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉,那麼即使在SQL語句中嵌入了惡意代碼,他們也將毫無作為。

多層環境如何防治SQL注入式攻擊?
在多層應用環境中,用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕,並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施,對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是,如果下一層認為其輸入已通過驗證,則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境,在防止注入式攻擊的時候,需要各層一起努力,在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。

B. 如何防止sql注入

1
普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句,那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象,故要操作這個語句用戶必須有相關的許可權。在許可權設計中,對於終端用戶,即應用軟體的使用者,沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼,由於其用戶許可權的限制,這些代碼也將無法被執行。故應用程序在設計的時候,

2
強迫使用參數化語句。
如果在編寫SQL語句的時候,用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話,那麼就可以有效的防治SQL注入式攻擊。也就是說,用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反,用戶的輸入的內容必須進行過濾,或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施,可以杜絕大部分的SQL注入式攻擊。不過可惜的是,現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。

3
多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響,在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中,工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話,則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼,則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查,范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束,就會發生異常,並報告給管理員。如上面這個案例中,如果員工編號定義的數據類型為字元串型,長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據,但是其長度達到了20個字元。則此時就會引發異常,因為用戶輸入的內容長度超過了資料庫欄位長度的限制。

4
加強對用戶輸入的驗證。
總體來說,防治SQL注入式攻擊可以採用兩種方法,一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中,有比較多的用戶輸入內容驗證工具,可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容,只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入,防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型,強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出,對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾,如拒絕一些特殊的符號。如以上那個惡意代碼中,只要存儲過程把那個分號過濾掉,那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前,可以通過資料庫的存儲過程,來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下,應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符,它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容,故可以直接把他拒絕掉,通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉,那麼即使在SQL語句中嵌入了惡意代碼,他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入,過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。

5
多層環境如何防治SQL注入式攻擊?
在多層應用環境中,用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕,並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施,對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是,如果下一層認為其輸入已通過驗證,則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境,在防止注入式攻擊的時候,需要各層一起努力,在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊

C. 如何從根本上防止 SQL 注入

SQL注入並不是一個在SQL內不可解決的問題,這種攻擊方式的存在也不能完全歸咎於SQL這種語言,因為注入的問題而放棄SQL這種方式也是因噎廢食。首先先說一個我在其他回答中也曾提到過的觀點:沒有(運行時)編譯,就沒有注入。

SQL注入產生的原因,和棧溢出、XSS等很多其他的攻擊方法類似,就是未經檢查或者未經充分檢查的用戶輸入數據,意外變成了代碼被執行。針對於SQL注入,則是用戶提交的數據,被資料庫系統編譯而產生了開發者預期之外的動作。也就是,SQL注入是用戶輸入的數據,在拼接SQL語句的過程中,超越了數據本身,成為了SQL語句查詢邏輯的一部分,然後這樣被拼接出來的SQL語句被資料庫執行,產生了開發者預期之外的動作。

所以從根本上防止上述類型攻擊的手段,還是避免數據變成代碼被執行,時刻分清代碼和數據的界限。而具體到SQL注入來說,被執行的惡意代碼是通過資料庫的SQL解釋引擎編譯得到的,所以只要避免用戶輸入的數據被資料庫系統編譯就可以了。

現在的資料庫系統都提供SQL語句的預編譯(prepare)和查詢參數綁定功能,在SQL語句中放置佔位符'?',然後將帶有佔位符的SQL語句傳給資料庫編譯,執行的時候才將用戶輸入的數據作為執行的參數傳給用戶。這樣的操作不僅使得SQL語句在書寫的時候不再需要拼接,看起來也更直接,而且用戶輸入的數據也沒有機會被送到資料庫的SQL解釋器被編譯執行,也不會越權變成代碼。

至於為什麼這種參數化的查詢方式沒有作為默認的使用方式,我想除了兼容老系統以外,直接使用SQL確實方便並且也有確定的使用場合。

多說一點,從代碼的角度來看,拼接SQL語句的做法也是不恰當的。

D. php如何防止sql注入

PHP防止sql注入是一個比較低級的問題了,這個問題其實在我大一上學期做第一個個人博客的時候就已經關注過了,不過簡單的說一下關於PHP防注入的方式吧。


對於現在的防注入技術其實已經成熟了,對於一個站點該關心的不是防注入了,而是大規模高並發如何處理的問題,或者關於各種其他漏洞,比如現在世界上仍然有百分之80使用redis的站點存在redis漏洞,通過redis漏洞可以直接拿到機器的訪問許可權,一般來說都是直接給你種一個挖礦機器人來。

E. 如何防止SQL注入

所謂SQL注入,就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令,比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的,這類表單特別容易受到SQL注入式攻擊.
1、如何防範?
好在要防止ASP.NET應用被SQL注入式攻擊闖入並不是一件特別困難的事情,只要在利用表單輸入的內容構造SQL命令之前,把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行。
⑴ 對於動態構造SQL查詢的場合,可以使用下面的技術:
第一:替換單引號,即把所有單獨出現的單引號改成兩個單引號,防止攻擊者修改SQL命令的含義。再來看前面的例子,「SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'」顯然會得到與「SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'」不同的結果。
第二:刪除用戶輸入內容中的所有連字元,防止攻擊者構造出類如「SELECT * from Users WHERE login = 'mas' -- AND password =''」之類的查詢,因為這類查詢的後半部分已經被注釋掉,不再有效,攻擊者只要知道一個合法的用戶登錄名稱,根本不需要知道用戶的密碼就可以順利獲得訪問許可權。
第三:對於用來執行查詢的資料庫帳戶,限制其許可權。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由於隔離了不同帳戶可執行的操作,因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT、UPDATE或DELETE命令。
⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字元實施攻擊。此外,它還使得資料庫許可權可以限制到只允許特定的存儲過程執行,所有的用戶輸入必須遵從被調用的存儲過程的安全上下文,這樣就很難再發生注入式攻擊了。
⑶ 限製表單或查詢字元串輸入的長度。如果用戶的登錄名字最多隻有10個字元,那麼不要認可表單中輸入的10個以上的字元,這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性,確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和伺服器端都執行——之所以要執行伺服器端驗證,是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端,攻擊者完全有可能獲得網頁的源代碼,修改驗證合法性的腳本(或者直接刪除腳本),然後將非法內容通過修改後的表單提交給伺服器。因此,要保證驗證操作確實已經執行,唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證對象,例如RegularExpressionValidator,它們能夠自動生成驗證用的客戶端腳本,當然你也可以插入伺服器端的方法調用。如果找不到現成的驗證對象,你可以通過CustomValidator自己創建一個。
⑸ 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據,然後再將它與資料庫中保存的數據比較,這相當於對用戶輸入的數據進行了「消毒」處理,用戶輸入的數據不再對資料庫有任何特殊的意義,從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個,非常適合於對輸入數據進行消毒處理。
⑹ 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄,但實際返回的記錄卻超過一行,那就當作出錯處理。

F. 什麼是sql注入如何防止sql注入

SQL注入是一種非常常見的資料庫攻擊手段,同時也是網路世界中最普遍的漏洞之一,簡單理解就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。
問題來源是,SQL資料庫的操作是通過SQL語句來執行的,而無論是執行代碼還是數據項都必須寫在SQL語句中,也就導致如果我們在數據項中加入了某些SQL語句關鍵字,比如SELECT、DROP等,這些關鍵字就很有可能在資料庫寫入或讀取數據時得到執行。
解決方案
方案一:
採用預編譯技術
使用預編譯的SQL語句,SQL語句的語義不會是不會發生改變的。預編譯語句在創建的時候就已經將指定的SQL語句發送給了DBMS,完成了解析,檢查,編譯等工作,所以攻擊者無法改變SQL語句的結構,只是把值賦給?,然後將?這個變數傳給SQL語句。當然還有一些通過預編譯繞過某些安全防護的操作,大家感興趣可以去搜索一下。
方案二:
嚴格控制數據類型
在java、c等強類型語言中一般是不存在數字型注入的,因為在接受到用戶輸入id時,代碼一般會做一個int id 的數據類型轉換,假如我們輸入的是字元串的話,那麼這種情況下,程序就會報錯。但是在PHP、ASP這些沒有強調處理數據類型的語言,一般我們看到的接收id的代碼都是如下等代碼。
方案三:
對特殊的字元進行轉義
數字型注入可以通過檢查數據類型防止,但是字元型不可以,那麼怎麼辦呢,最好的辦法就是對特殊的字元進行轉義了。比如在MySQL中我們可以對" '
"進行轉義,這樣就防止了一些惡意攻擊者來閉合語句。當然我們也可以通過一些安全函數來轉義特殊字元。如addslashes()等,但是這些函數並非一勞永逸,攻擊者還可以通過一些特殊的方式繞過。

G. 防止sql注入問題

ASP編程門檻很低,新手很容易上路。在一段不長的時間里,新手往往就已經能夠編出看來比較完美的動態網站,在功能上,老手能做到的,新手也能夠做到。那麼新手與老手就沒區別了嗎?這裡面區別可就大了,只不過外行人很難一眼就看出來罷了。在界面的友好性、運行性能以及網站的安全性方面是新手與老手之間區別的三個集中點。而在安全性方面,新手最容易忽略的問題就是SQL注入漏洞的問題。用NBSI
2.0對網上的一些ASP網站稍加掃描,就能發現許多ASP網站存在SQL注入漏洞,教育網里高校內部機構的一些網站這種漏洞就更普遍了,可能這是因為這些網站大都是一些學生做的緣故吧,雖然個個都很聰明,可是畢竟沒有經驗,而且處於學習中,難免漏洞多多了。本文主要講講SQL注入的防範措施,而要明白這些防範措施的用處,須先詳細講解利用SQL注入漏洞入侵的過程。新手們看明白啦。

相當大一部分程序員在編寫代碼的時候,沒有對用戶輸入數據的合法性進行判斷,使應用程序存在安全隱患。如這是一個正常的網址http://localhost/lawjia/show.asp?ID=444,將這個網址提交到伺服器後,伺服器將進行類似Select
* from 表名 where 欄位="&ID的查詢(ID即客戶端提交的參數,本例是即444),再將查詢結果返回給客戶端,如果這里客戶端故意提交這么一個網址:

http://localhost/lawjia/show.asp?ID=444 and user>0,這時,伺服器運行Select * from 表名
where 欄位=444 and user>0這樣的查詢,當然,這個語句是運行不下去的,肯定出錯,錯誤信息如下:

·錯誤類型:

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]將 nvarchar 值 'sonybb' 轉換為數據類型為
int 的列時發生語法錯誤。
/lawjia/show.asp, 第 47 行

但是別有用心的人從這個出錯信息中,可以獲得以下信息:該站使用MS_SQL資料庫,用ODBC連接,連接帳號名為:sonybb。所謂SQL注入(SQL
Injection),就是利用程序員對用戶輸入數據的合法性檢測不嚴或不檢測的特點,故意從客戶端提交特殊的代碼,從而收集程序及伺服器的信息,從而獲取想得到的資料。通常別有用心者的目標是獲取網站管理員的帳號和密碼。比如當某個人知道網站管理員帳號存在表login中,管理員帳號名為admin,他想知道管理員密碼,這里他從客戶端接著提交這樣一個網址:
http://localhost/lawjia/show.asp?ID=444 and (Select password from login where
user_name='admin')>0,返回的出錯信息如下:

·錯誤類型:

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]將 varchar 值 '!@#*&admin' 轉換為數據類型為
int 的列時發生語法錯誤。
/lawjia/show.asp, 第 47 行

你知道嗎?上面標紅的部分就是管理員帳號admin的密碼!雖然很復雜,讓人看幾遍也記不住的,但它就這樣顯示在你面前了,這時您就可以用這個帳號和密碼接管人家的網站了!這時你可能還會說,如果他不是事先知道管理員帳號存在表login中,而且知道管理員帳號為admin,那他就不可能獲得管理員密碼。你錯了,只要人家願意多花時間嘗試,他將可以獲得資料庫連接帳號許可權內所能獲得的所有信息!

當然這個過程是很煩瑣的而且要花費很多的時間,如果只能以這種手動方式進行SQL注入入侵的話,那麼許多存在SQL注入漏洞的ASP網站會安全很多了,不是漏洞不存在了,而是利用這個漏洞入侵的成本太高了。但是如果利用專門的黑客工具來入侵的話,那情況就大大不同了。手動方式進行SQL注入入侵至少需要半天或一天乃至很多天的時間,而利用專門的工具來入侵就只需要幾分鍾時間了(視網速快慢決定),再利用獲得的管理帳號和密碼,上傳一個從網上下載的ASP後門程序,就輕易獲得整個網站的管理許可權了,甚至整個伺服器的管理許可權。最有名的一種SQL注入入侵工具是NBSI
2.0,現在已經出到2.0版本了,不過,人家正式名稱不叫SQL注入入侵工具,而叫做網站安全漏洞檢測工具。有了這個所謂的檢測工具,使得入侵存在SQL注入漏洞的ASP網站成了小兒科的游戲,那些既不懂ASP又不懂SQL、年紀小小的男性青年常常得以在一天之內入侵十多個ASP網站,他們以此獲得內心的極大滿足。他們似乎也非常講究職業道德,往往並不破壞網站數據和系統,常見的破壞方式大都僅僅是改換掉網站的主頁,留下"善意的警告",如:你的網站存在SQL注入漏洞,請管理員做好防範措施!並聲明"我沒有破壞數據和系統",有的還要借機發布一下他的倡導:"國內網站大家不要入侵,有本事入侵小日本的!",最後,簽上他的鼎鼎大名是必不可少的程序。
不知那些沒注意過SQL注入漏洞的ASP程序員們看了上面的例子,要作何感想呢?如果您的網站就這樣被人不費吹灰之力入侵了,您是不是要吐幾升血了呢?也許您已經為系統安全費盡心思了,裝補丁、安防火牆、裝殺毒軟體、巧妙配置IIS及資料庫用戶許可權,但您就是沒有注意到SQL注入漏洞,於是"千里之堤,潰於蟻穴"。防火牆與殺毒軟體對SQL注入是沒辦法防範的,因為SQL注入入侵跟普通的WEB頁面訪問沒什麼區別,所以往往是防不甚防。而且一個伺服器上放置的網站往往是有很多個的,伺服器管理員不可能挨個網站挨個頁面的審查其是否存在SQL注入漏洞。那麼應該如何防範SQL注入入侵呢?作為伺服器管理員或網站程序員應該分別怎麼做呢?伺服器管理員要做的事主要是配置IIS和資料庫用戶許可權,而網站程序員主要是要在程序代碼編寫上防範SQL注入入侵。下面詳細敘述:

對於伺服器管理員,既然你不可能挨個檢查每個網站是否存在SQL注入漏洞,那麼就來個一個絕招。這個絕招能有效防止SQL注入入侵而且"省心又省力,效果真好!"SQL注入入侵是根據IIS給出的ASP錯誤提示信息來入侵的,如果你把IIS設置成不管出什麼樣的ASP錯誤,只給出一種錯誤提示信息,即http
500錯誤,那麼人家就沒辦法入侵了。具體設置請參看圖2。主要把500:100這個錯誤的默認提示頁面
C:\WINDOWS\Help\iisHelp\common\500-100.asp改成
C:\WINDOWS\Help\iisHelp\common\500.htm即可,這時,無論ASP運行中出什麼錯,伺服器都只提示HTTP 500錯誤。
但是這樣設置一個不好的地方是程序員編寫的代碼出錯時,伺服器不給出詳細的錯誤提示信息,會給程序員帶來很大的不便。不過,伺服器畢竟不是測試代碼的地方,應堅持安全穩定第一,這樣設置也是無可厚非的,事實上許多伺服器的出錯信息都是如此設置。

伺服器管理員還應在IIS中為每個網站設置好執行許可權,可千萬別給人家靜態網站以"腳本和可執行"許可權。一般情況下給個"純腳本"許可權就夠了,對於那些通過網站後台管理中心上傳的文件存放的目錄,就更吝嗇一點吧,執行許可權設為"無"好了,這樣做是為了防止人家上傳ASP木馬,執行許可權設為"無",人家上傳ASP木馬也運行不了。一般情況下,SQL注入漏洞僅是涉及一個網站安全的事,如果人家通過這個漏洞上傳了ASP木馬並運行起來,那整個伺服器都失陷了。所以有遠見的、有責任心的伺服器管理員應該十分吝嗇的配置IIS的執行許可權。

同樣的吝嗇態度應適用於資料庫用戶的許可權配置上,當然這里資料庫是指MS_SQL啦,ACCESS都沒有用戶許可權配置這一步驟。如果PUBLIC許可權足夠使用的絕不給再高的許可權,可千萬別把SA級別的許可權隨隨便便地給人家啊。那個所謂的網站安全漏洞檢測工具NBSI
2.0可有跨庫進行SQL注入的功能啊,如果你把SA許可權給了存在SQL注入漏洞的庫,那其它庫就不保啦!城門失火,殃及池魚呀。而人家還可以通過調用xp_cmdshell命令得到系統的最高許可權。具體步驟還是請參看上面提到的那篇《SQL注入漏洞全接觸》這篇文章吧。

接下來要講講程序員的防範措施了。程序主要要做兩件事,最重要的一件事,當然是對客戶端提交的變數參數進行仔細地檢測啦。對客戶端提交的變數進行檢查以防止SQL注入,有各種方法,到http://community.csdn.net/上搜索一下,你能獲得許多有益信息。這里介紹一種現成的方法,別人已經寫好了檢測代碼,拿來用一下,不用自己辛苦啦。那就是"楓葉SQL通用防注入V1.0
ASP版",這是一段對用戶通過網址提交過來的變數參數進行檢查的代碼,發現客戶端提交的參數中有"exec、insert、select、delete、from、update、count、user、xp_cmdshell、add、net、Asc"等用於SQL注入的常用字元時,立即停止執行ASP並給出警告信息或轉向出錯頁面。大家可以到網上搜索一下,下載這段代碼,存為一個ASP頁面,如checkSQL.asp,把這個頁面include到每個需要帶參數查詢SQL資料庫ASP頁面中,記住,只要加一行這樣的<!--#include
file="checkSQL.asp"-->代碼就行了。

程序員要做的第二件事是給用戶密碼加密啦。比如用MD5加密。MD5是沒有反向演算法,不能解密的。人家即使知道經加密後存在資料庫里的像亂碼一樣的密碼,他也沒辦法知道原始密碼了。不過,人家可以用UPDATE方法用他的密碼代替你的密碼,但這個操作還是有點麻煩,人家可能會怕麻煩而放棄。而那個所謂的網站安全漏洞檢測工具NBSI
2.0是沒有提供UPDATE操作功能的,所以用MD5加密後,人家僅用NBSI
2.0而不輔以手動操作的話,就不可能獲得網站管理員帳號的密碼,這將擋住許多菜鳥級的攻擊者,至少那些既不懂ASP又不懂SQL、年紀小小的男性青年是沒有辦法啦!

文章寫到這,已經夠長了,本來還想對那些所謂的網站安全漏洞檢測工具如NBSI之流的黑客工具進行一番理性的探討的,看來還是放棄好了。為了增強網站安全,了解攻擊手段是必須的,但是,利用漏洞開發專門的黑客工具,使那些其實並不具備必要的網路技術和網路安全知識的人(就是文中提到的"既不懂ASP又不懂SQL、年紀小小的男性青年")輕而易舉地侵入一家網站,這除了為許多網路管理員製造麻煩外,是否還具有加強網路安全意識提高網路安全水平的功效呢?

H. 請問怎麼防止sql注入

避免sql注入式漏洞的方法:

  1. 對用戶的任何輸入都必須進行相應的驗證,和特殊字元的轉義,對單引號 雙引號的轉換 ,對用戶輸入數據的長度進行合理的限制 對用戶輸入的數據類型進行驗證

  2. 盡量少拼接sql語句,多採用參數化的sql

  3. 禁止使用管理員許可權賬號連接資料庫

  4. 重要信息存入資料庫前,進行適當的加密,對大批導出數據,進行合理的限制

  5. 前端友好提示,禁止直接拋出系統異常

請採納!

I. 如何防範SQL注入漏洞及檢測

SQL注入漏洞攻擊的防範方法有很多種,現階段總結起來有以下方法:
(1)數據有效性校驗。如果一個輸入框只可能包括數字,那麼要通過校驗確保用戶輸入的都是數字。如果可以接受字母,那就要檢查是不是存在不可接受的字元,最好的方法是增加字元復雜度自動驗證功能。確保應用程序要檢查以下字元:分號、等號、破折號、括弧以及SQL關鍵字。另外限製表單數據輸入和查詢字元串輸入的長度也是一個好方法。如果用戶的登錄名最多隻有10個字元,那麼不要認可表單中輸入10個以上的字元,這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
(2)封裝數據信息。對客戶端提交的數據進行封裝,不要將數據直接存入cookie中,方法就是在編程的代碼中,插入session、if、try、else,這樣可以有效地防止攻擊者獲取cookie中的重要信息。
(3)去除代碼中的敏感信息。將在代碼中存在的用戶名、口令信息等敏感欄位刪除,替換成輸入框。
SQL=" select from users where username = 』admin』and password= 』1234567』 "
如:這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成:
SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"
這樣就安全了很多,入侵者也是不會輕易的就獲取到用戶名、口令信息。
(4)替換或刪除單引號。使用雙引號替換掉所有用戶輸入的單引號,這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊,單引號時常會無法約束插入數據的Value,可能給予輸入者不必要的許可權。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。 如:
「select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'」
顯然會得到與
「select * from users where username='admin' and password= '1234567'」
相同的結果。
(5)指定錯誤返回頁面。攻擊者有時從客戶端嘗試提交有害代碼和攻擊字元串,根據Web Service給出的錯誤提示信息來收集程序及伺服器的信息,從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。
(6)限制SQL字元串連接的配置文件。使用SQL變數,因為變數不是可以執行的腳本,即在Web頁面中將連接資料庫的SQL字元串替換成指定的Value,然後將Web.config文件進行加密,拒絕訪問。
(7)設置Web目錄的訪問許可權。將虛擬站點的文件目錄禁止遊客用戶(如:Guest用戶等)訪問,將User用戶許可權修改成只讀許可權,切勿將管理許可權的用戶添加到訪問列表。
(8)最小服務原則。Web伺服器應以最小許可權進行配置,只提供Web服務,這樣可以有效地阻止系統的危險命令,如ftp、cmd、vbscript等。
(9)鑒別信息加密存儲。將保存在資料庫users表中的用戶名、口令信息以密文形式保存,也可以對users表進行加密處理,這樣可以大大增加對鑒別信息訪問的安全級別。
(10)用戶許可權分離。應盡可能的禁止或刪除資料庫中sa許可權用戶的訪問,對不同的資料庫劃分不同的用戶許可權,這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作,就可以防止不同用戶對非授權的資料庫進行訪問。

J. 怎麼樣防止Sql注入

(1)對於動態構造SQL查詢的場合,可以使用下面的技術:

第一:替換單引號,即把所有單獨出現的單引號改成兩個單引號,防止攻擊者修改SQL命令的含義。再來看前面的例子,「SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'」顯然會得到與「SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'」不同的結果。

第二:刪除用戶輸入內容中的所有連字元,防止攻擊者構造出類如「SELECT * from Users WHERE login = 'mas' -- AND password =''」之類的查詢,因為這類查詢的後半部分已經被注釋掉,不再有效,攻擊者只要知道一個合法的用戶登錄名稱,根本不需要知道用戶的密碼就可以順利獲得訪問許可權。

第三:對於用來執行查詢的資料庫帳戶,限制其許可權。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由於隔離了不同帳戶可執行的操作,因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT、UPDATE或DELETE命令。

⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字元實施攻擊。此外,它還使得資料庫許可權可以限制到只允許特定的存儲過程執行,所有的用戶輸入必須遵從被調用的存儲過程的安全上下文,這樣就很難再發生注入式攻擊了。

⑶ 限製表單或查詢字元串輸入的長度。如果用戶的登錄名字最多隻有10個字元,那麼不要認可表單中輸入的10個以上的字元,這將大大增加攻擊者在SQL命令中插入有害代碼的難度。

⑷ 檢查用戶輸入的合法性,確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和伺服器端都執行——之所以要執行伺服器端驗證,是為了彌補客戶端驗證機制脆弱的安全性。

在客戶端,攻擊者完全有可能獲得網頁的源代碼,修改驗證合法性的腳本(或者直接刪除腳本),然後將非法內容通過修改後的表單提交給伺服器。因此,要保證驗證操作確實已經執行,唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證對象,例如RegularExpressionValidator,它們能夠自動生成驗證用的客戶端腳本,當然你也可以插入伺服器端的方法調用。如果找不到現成的驗證對象,你可以通過CustomValidator自己創建一個。

⑸ 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據,然後再將它與資料庫中保存的數據比較,這相當於對用戶輸入的數據進行了「消毒」處理,用戶輸入的數據不再對資料庫有任何特殊的意義,從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個,非常適合於對輸入數據進行消毒處理。

⑹ 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄,但實際返回的記錄卻超過一行,那就當作出錯處理。
---------------------------------------------------------------------------------------------------------------------------
關鍵是明白原理,其實防範很簡單的,
1.過濾SQL需要的參數中的敏感字元(注意加入忽略大小寫)
2.禁用資料庫伺服器的xp_cmdshell存儲過程,刪除相應用到的dll
3.屏蔽伺服器異常信息