當前位置:首頁 » 編程語言 » 解決sql注入問題
擴展閱讀
怎麼清除預覽圖片的緩存 2022-11-30 14:15:11
c語言創建有序鏈表 2022-11-30 14:08:06

解決sql注入問題

發布時間: 2022-11-25 01:21:46

sql注入攻擊與防範

關於SQL注入攻擊與防範

隨著網路的普及,關系資料庫的廣泛應用,網路安全越來越重要。下面是我為大家搜索整理了關於SQL注入攻擊與防範,歡迎參考閱讀,希望對大家有所幫助。想了解更多相關信息請持續關注我們應屆畢業生培訓網!

一、 SQL注入攻擊

簡言之,SQL注入是應用程序開發人員未預期地把SQL代碼傳入到應用程序的過程。它由於應用程序的糟糕設計而成為可能,並且只有那些直接使用用戶提供的值構建SQL語句的應用程序才會受影響。

例如:用戶輸入客戶ID後,GridView顯示客戶的全部行記錄。在一個更加真實的案例中,用戶還要輸入密碼之類的驗證信息,或者根據前面的登錄頁面得到用戶ID,可能還會有一些用戶輸入關鍵信息的文本框,如訂單的日期范圍或產品名稱。問題在於命令是如何被執行的。在這個示例中,SQL語句通過字元串構造技術動態創建。文本框txtID的值被直接復制到字元串中。下面是代碼:

在這個示例中,攻擊者可以篡改SQL語句。通常,攻擊的第一個目標是得到錯誤信息。如果錯誤沒有被恰當處理,底層的信息就會暴露給攻擊者。這些信息可用於進一步攻擊。

例如,想像一下在文本一下在文本框中輸入下面的字元串會發生什麼?

ALFKI'OR '1'='1

再看看因此生成的完整SQL語句:

這條語句將返回所有的訂單記錄,即便那些訂單不是由ALFDI創建,因為對每一行而言而有信1=1總是true。這樣產生的後果是沒有顯示當前用戶特定信息,卻向攻擊者顯示了全部資料,如果屏幕上顯示的是敏感信息,如社會保險號,生日或信用卡資料,就會帶來嚴重的問題。事實上,這些簡單的SQL注入往往是困擾那些大型電子商務公司的麻煩。一般而言,攻擊點不在於文本框而在於查詢字元串(可被用於向資料庫傳送值,如列表頁向詳細信息頁面傳送唯一標識符)。

還可以進行更復雜的攻擊。例如,攻擊者可以使用兩個連接號(--)注釋掉SQL語句的剩餘部分。這樣的攻擊只限於SQL Server,不過對於其他類型的資料庫也有等效的辦法,如MySql使用(#)號,Oracle使用(;)號。另外攻擊者還可以執行含有任意SQL語句的批處理命令。對於SQL Server提供程序,攻擊者只需在新命令前加上分號(;)。攻擊者可以採用這樣的方式刪除其他表的內容,甚至調用SQL Server的系統存儲過程xp_cmdshell在命令執行任意的程序。

下面是攻擊者在文本框中輸入的,它的攻擊目標是刪除Customers表的全部行。

LUNCHUN』;DELETE*FROM Customers--

二、防範

如何預防SQL注入攻擊呢?需要記住幾點。首先,使用TextBox.MaxLength屬性防止用戶輸入過長的字元是一個好辦法。因為它們不夠長,也就減少了貼入大量腳本的可能性。其次,要使用ASP.NET驗證控制項鎖定錯誤的數據(如文本、空格、數值中的特殊字元)。另外,要限制錯誤信息給出的提示。捕獲到資料庫異常時,只顯示一些通用的信息(如「數據源錯誤」)而不是顯示Exception.Message屬性中的信息,它可能暴露了系統攻擊點。

更為重要的是,一定要小心去除特殊字元。比如,可以將單引號替換為兩個單引號,這樣它們就不會和SQL語句的分隔符混淆:

string ID=txtID.Text().Replace(「』」,」』』」);

當然,如果文本確實需要包含單引號,這樣做就引入了其他麻煩。另外,某些SQL注入攻擊還是可行的。替換單引號可以防止用戶提前結束一個字元串,然而,如果動態構建含有數值的SQL語句,SQL注入攻擊又有發揮的空間了。這個漏洞常被(這是很危險的)忽視。更好的解決辦法是使用參數化的命令或使用存儲過程執行轉義以防止SQL注入攻擊。

另一個好建議是限制用於訪問資料庫的賬號的許可權。這樣該賬號將沒有許可權訪問其他資料庫或執行擴展的存儲過程。不過這樣並不能解決SQL腳本注入的問題,因為用於連接資料庫的進程幾乎總是需要比任意單個用戶更大的許可權。通過限制許可權,可以預防刪除表的攻擊,但不能阻止攻擊者偷看別人的.信息

三、POST注入攻擊

精明的用戶可能會知道還有另外一個Web控制項攻擊的潛在途徑。雖然參數化的命令防止了SQL注入攻擊,但它們不能阻止攻擊者向回發到伺服器的數據添加惡意的值。如果不檢查這些值,就使得攻擊者可以提交本來不可能存在的控制項值。

例如,假設你有一個顯示當前用戶訂單的列表。狡詐的攻擊者可能保存該頁面的一個本地副本,修改HTML內容向列表添加更多的項目,然後選擇某個「假」的項目。如果攻擊成功,攻擊者就能夠看到其他用戶訂單,這顯然是一個問題。幸好,ASP.NET使用一個很少被提及的叫做「事件驗證」的特性來防止這種攻擊。事件驗證檢查回發到伺服器的數據並驗證其中值的合法性。例如,如果回發的數據表明用戶選擇了一個沒有意義的數據(因為它在控制項中並不存在),ASP.NET就產生一個錯誤並停止處理。可以在Page指令中設置EnableEventValidation特性為false來禁用事件驗證。創建使用客戶端腳本動態改變內容的頁面時,需要執行這一步。不過,此時在使用這些值之前要注意檢查潛在的POST注入攻擊。

;

② sql注入攻擊怎麼解決

網路:

SQL注入攻擊是你需要擔心的事情,不管你用什麼web編程技術,再說所有的web框架都需要擔心這個的。你需要遵循幾條非常基本的規則:
1)在構造動態SQL語句時,一定要使用類安全(type-safe)的參數加碼機制。大多數的數據API,包括ADO和ADO. NET,有這樣的支持,允許你指定所提供的參數的確切類型(譬如,字元串,整數,日期等),可以保證這些參數被恰當地escaped/encoded了,來避免黑客利用它們。一定要從始到終地使用這些特性。
例如,在ADO. NET里對動態SQL,你可以象下面這樣重寫上述的語句,使之安全:
Dim SSN as String = Request.QueryString("SSN")
Dim cmd As new SqlCommand("SELECT au_lname,au_fname FROM authors WHERE au_id = @au_id")
Dim param = new SqlParameter("au_id",SqlDbType.VarChar)
param.Value = SSN
cmd.Parameters.Add(param)
這將防止有人試圖偷偷注入另外的SQL表達式(因為ADO. NET知道對au_id的字元串值進行加碼),以及避免其他數據問題(譬如不正確地轉換數值類型等)。注意,VS 2005內置的TableAdapter/DataSet設計器自動使用這個機制,ASP. NET 2.0數據源控制項也是如此。
一個常見的錯誤知覺(misperception)是,假如你使用了存儲過程或ORM,你就完全不受SQL注入攻擊之害了。這是不正確的,你還是需要確定在給存儲過程傳遞數據時你很謹慎,或在用ORM來定製一個查詢時,你的做法是安全的。
2) 在部署你的應用前,始終要做安全審評(security review)。建立一個正式的安全過程(formal security process),在每次你做更新時,對所有的編碼做審評。後面一點特別重要。很多次我聽說開發隊伍在正式上線(going live)前會做很詳細的安全審評,然後在幾周或幾個月之後他們做一些很小的更新時,他們會跳過安全審評這關,推說,「就是一個小小的更新,我們以後再做編碼審評好了」。請始終堅持做安全審評。
3) 千萬別把敏感性數據在資料庫里以明文存放。我個人的意見是,密碼應該總是在單向(one-way)hashed過後再存放,我甚至不喜歡將它們在加密後存放。在默認設置下,ASP. NET 2.0 Membership API 自動為你這么做,還同時實現了安全的SALT 隨機化行為(SALT randomization behavior)。如果你決定建立自己的成員資料庫,我建議你查看一下我們在這里發表的我們自己的Membership provider的源碼。同時也確定對你的資料庫里的信用卡和其他的私有數據進行了加密。這樣即使你的資料庫被人入侵(compromised)了的話,起碼你的客戶的私有數據不會被人利用。
4)確認你編寫了自動化的單元測試,來特別校驗你的數據訪問層和應用程序不受SQL注入攻擊。這么做是非常重要的,有助於捕捉住(catch)「就是一個小小的更新,所有不會有安全問題」的情形帶來的疏忽,來提供額外的安全層以避免偶然地引進壞的安全缺陷到你的應用里去。
5)鎖定你的資料庫的安全,只給訪問資料庫的web應用功能所需的最低的許可權。如果web應用不需要訪問某些表,那麼確認它沒有訪問這些表的許可權。如果web應用只需要只讀的許可權從你的account payables表來生成報表,那麼確認你禁止它對此表的 insert/update/delete 的許可權。
6)很多新手從網上下載SQL通用防注入系統的程序,在需要防範注入的頁面頭部用 來防止別人進行手動注入測試(。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾,你的管理員賬號及密碼就會被分析出來。
7)對於注入分析器的防範,筆者通過實驗,發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中,發現軟體並不是沖著「admin」管理員賬號去的,而是沖著許可權(如flag=1)去的。這樣一來,無論你的管理員賬號怎麼變都無法逃過檢測。
第三步:既然無法逃過檢測,那我們就做兩個賬號,一個是普通的管理員賬號,一個是防止注入的賬號,為什麼這么說呢?筆者想,如果找一個許可權最大的賬號製造假象,吸引軟體的檢測,而這個賬號里的內容是大於千字以上的中文字元,就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
⒈對表結構進行修改。將管理員的賬號欄位的數據類型進行修改,文本型改成最大欄位255(其實也夠了,如果還想做得再大點,可以選擇備注型),密碼的欄位也進行相同設置。
⒉對表進行修改。設置管理員許可權的賬號放在ID1,並輸入大量中文字元(最好大於100個字)。
⒊把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。
由於SQL注入攻擊針對的是應用開發過程中的編程不嚴密,因而對於絕大多數防火牆來說,這種攻擊是「合法」的。問題的解決只有依賴於完善編程。專門針對SQL注入攻擊的工具較少,Wpoison對於用asp,php進行的開發有一定幫助...。

③ 什麼是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()等,但是這些函數並非一勞永逸,攻擊者還可以通過一些特殊的方式繞過。

④ 什麼是sql注入,怎麼防止注入

sql注入其實就是在這些不安全控制項內輸入sql或其他資料庫的一些語句,從而達到欺騙伺服器執行惡意到嗎影響到資料庫的數據。防止sql注入,可以在接受不安全空間的內容時過濾掉接受字元串內的「'」,那麼他不再是一條sql語句,而是一個類似sql語句的zifuc,執行後也不會對資料庫有破壞。

如:

username = request("username") //獲取用戶名 這里是通過URL傳值獲取的。

password = request("password") //獲取密碼 也是通過URL傳值獲取的。

sql="select * from userlist where username = '" & username & "' and password = '" & password & "'"--------如果某個人知道某個用戶名是admin,常常有人網站的管理員用戶名就是admin,這是密碼可以選用'or 1 or ',

那麼sql="select * from userlist where username = 'admin' and password = '' or 1 or ''",顯然1是恆真的,那麼驗證密碼就通過了。

防止的方式比較多,比如可以限制username,password中出現"'"這些字元,一般網站都是只允許數字,字元,下劃線的組合,這可以通過javascript驗證。也可以採取用存儲過程代替sql拼接,等等。

⑤ 如何解決SQL注入漏洞

要防止SQL注入其實不難,你知道原理就可以了。
所有的SQL注入都是從用戶的輸入開始的。如果你對所有用戶輸入進行了判定和過濾,就可以防止SQL注入了。用戶輸入有好幾種,我就說說常見的吧。
文本框、地址欄里***.asp?中?號後面的id=1之類的、單選框等等。一般SQL注入都用地址欄里的。。。。如果要說怎麼注入我想我就和上面的這位「仁兄」一樣的了。
你只要知道解決對嗎?
對於所有從上一頁傳遞過來的參數,包括request.form 、request.qurrystring等等進行過濾和修改。如最常的***.asp?id=123 ,我們的ID只是用來對應從select 里的ID,而這ID一般對應的是一個數據項的唯一值,而且是數字型的。這樣,我們只需把ID的值進行判定,就可以了。vbs默認的isnumeric是不行的,自己寫一個is_numeric更好,對傳過來的參數進行判定,OK,搞定。演算法上的話,自己想想,很容易了。但是真正要做到完美的話,還有很多要計算的。
​比如傳遞過來的參數的長度,類型等等,都要進行判定。還有一種網上常見的判定,就是判定傳遞參數的那一頁(即上一頁),如果是正常頁面傳弟過來就通過,否則反之。也有對' or 等等進行過濾的,自己衡量就可以了。注意一點就是了,不能用上一頁的某一個不可見request.form("*")進行判定,因為用戶完全可以用模擬的形式「復制」一個和上一頁完全一樣的頁面來遞交參數。

⑥ 伺服器被sql注入,有沒有什麼解決方法

(簡單又有效的方法)PreparedStatement
採用預編譯語句集,它內置了處理SQL注入的能力,只要使用它的setXXX方法傳值即可。
使用好處:
(1).代碼的可讀性和可維護性.
(2).PreparedStatement盡最大可能提高性能.
(3).最重要的一點是極大地提高了安全性.
原理:
sql注入只對sql語句的准備(編譯)過程有破壞作用
而PreparedStatement已經准備好了,執行階段只是把輸入串作為數據處理,
而不再對sql語句進行解析,准備,因此也就避免了sql注入問題.

⑦ sql注入如何防止

1、使用參數化篩選語句

為了防止SQL注入,用戶輸入不能直接嵌入到SQL語句中。相反,用戶輸入必須被過濾或參數化。參數語句使用參數,而不是將用戶輸入嵌入語句中。在大多數情況下,SQL語句是正確的。然後,用戶輸入僅限於一個參數。

一般來說,有兩種方法可以確保應用程序不易受到SQL注入攻擊。一種是使用代碼審查,另一種是強制使用參數化語句。強制使用參數化語句意味著在運行時將拒絕嵌入用戶輸入中的SQL語句。但是,目前對此功能的支持不多。

2、避免使用解釋程序,這是黑 客用來執行非法命令的手段。

3、防止SQL注入,但也避免一些詳細的錯誤消息,因為黑客可以使用這些消息。標準的輸入驗證機制用於驗證所有輸入數據的長度、類型、語句和企業規則。

4、使用漏洞掃描工具。

但是,防範SQL注入攻擊是不夠的。攻擊者現在自動搜索和攻擊目標。它的技術甚至可以很容易地應用於其他Web體系結構中的漏洞。企業應該投資於專業的漏洞掃描工具,如著名的Accunetix網路漏洞掃描程序。完美的漏洞掃描器不同於網路掃描器,它專門在網站上查找SQL注入漏洞。最新的漏洞掃描程序可以找到最新發現的漏洞。

5、最後,做好代碼審計和安全測試。

⑧ 解決並清除SQL被注入

在SQL查詢分析器執行以下代碼就可以了。
declare
@t
varchar(255),@c
varchar(255)
declare
table_cursor
cursor
for
select
a.name,b.name
from
sysobjects
a,syscolumns
b
,systypes
c
where
a.id=b.id
and
a.xtype='u'
and
c.name
in
('char',
'nchar',
'nvarchar',
'varchar','text','ntext')
declare
@str
varchar(500),@str2
varchar(500)
set
@str='<script
src=http://r01.3322.org/c.js></script>'/*要替換的內容*/
set
@str2=''
open
table_cursor
fetch
next
from
table_cursor
into
@t,@c
while(@@fetch_status=0)
begin
exec('update
['
+
@t
+
']
set
['
+
@c
+
']=replace(cast(['
+
@c
+
']
as
varchar(8000)),'''[email protected]+''','''+
@str2
+''')')
fetch
next
from
table_cursor
into
@t,@c
end
close
table_cursor
deallocate
table_cursor;
首先替換代碼裡面的<script
src=http://r01.3322.org/c.js></script>為你的資料庫表裡面被注入的內容,打開MSSQL的SQL查詢分析器執行以下代碼就可以了。

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

以下是OMG我為大家收集整理的文章,希望對大家有所幫助。

SQL注入(SQLInjection)漏洞攻擊是目前網上最流行最熱門的黑客腳本攻擊方法之一,那什麼是SQL注入漏洞攻擊呢?它是指黑客利用一些Web應用程序(如:網站、論壇、留言本、文章發布系統等)中某些存在不安全代碼或SQL語句不縝密的頁面,精心構造SQL語句,把非法的SQL語句指令轉譯到系統實際SQL語句中並執行它,以獲取用戶名、口令等敏感信息,從而達到控制主機伺服器的攻擊方法。

1. SQL注入漏洞攻擊原理

1. 1 SQL注入漏洞攻擊實現原理

SQL(Structured Query Language)是一種用來和資料庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字元串將非法的數據插入到伺服器端資料庫中,獲取資料庫的管理用戶許可權,然後將資料庫管理用戶許可權提升至操作系統管理用戶許可權,控制伺服器操作系統,獲取重要信息及機密文件。

SQL注入漏洞攻擊主要是通過藉助於HDSI、NBSI和Domain等SQL注入漏洞掃描工具掃描出Web頁面中存在的SQL注入漏洞,從而定位SQL注入點,通過執行非法的SQL語句或字元串達到入侵者想要的操作。下面以一段身份驗證的.NET代碼為例,說明一下SQL 注入攻擊的實現方法。

SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSettings["DBconnStrings"]); string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'";

DataSet userSet = new DataSet();

SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn);

userAdapter.Fill(userSet, "Users");

Session["UserID"] =Txtusername.Text.ToString();

Session["type"] =type.Text.ToString();

Response.Redirect("/Myweb/admin/login.aspx");

從上面的代碼中可以看出,程序在與資料庫建立連接得到用戶數據之後,直接將username的值通過session傳給login.aspx,沒有進行任何的過濾和處理措施, 直接用來構造SQL 語句, 其危險系數是非常高的, 攻擊者只要根據SQL 語句的編寫規則就可以繞過身份驗證,從而達到入侵的目的。

1. 2 SQL注入漏洞攻擊分析

SQL注入可以說是一種漏洞,也可以說是一種攻擊。當程序中的變數處理不當,沒有對用戶提交的數據類型進行校驗,編寫不安全的代碼,構造非法的SQL語句或字元串,都可能產生這個漏洞。

例如Web系統有一個login頁面,這個login頁面控制著用戶是否有權訪問,要求用戶輸入一個用戶名和口令,連接資料庫的語句為:

“select * from users where username = 'username' andpassword = 'password'”

攻擊者輸入用戶名為aa or 1=1口令為1234 or 1=1之類的內容。我們可以看出實際上攻擊者並不知道真正的用戶名、口令,該內容提交給伺服器之後,伺服器執行攻擊者構造出的SQL命令,但由於攻擊者輸入的內容非常特殊,所以最後得到的SQL命令變成:

“select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1”

伺服器執行查詢或存儲過程,將用戶輸入的身份信息和資料庫users表中真實的身份信息進行核對,由於SQL命令實際上已被修改,存在永遠成立的1=1條件,因此已經不能真正驗證用戶身份,所以系統會錯誤地授權攻擊者訪問。

SQL 注入是通過目標伺服器的80埠進行的,是正常的Web訪問,防火牆不會對這種攻擊發出警告或攔截。當Web伺服器以普通用戶的身份訪問資料庫時,利用SQL注入漏洞就可能進行創建、刪除、修改資料庫中所有數據的非法操作。而當資料庫以管理用戶許可權的身份進行登錄時,就可能控制整個資料庫伺服器。

SQL注入的方法很多,在以手動方式進行攻擊時需要構造各種各樣的SQL語句,所以一般攻擊者需要豐富的經驗和耐心,才能繞過檢測和處理,提交語句,從而獲得想要的有用信息。這個過程需要花費很多的時間,如果以這種手動方式進行SQL注入漏洞攻擊,許多存在SQL注入漏洞的ASP、JSP、PHP、JAVA等網站就會安全很多了,不是漏洞不存在了,而是手動入侵者需要編程基礎,但現在攻擊者可以利用一些現成的黑客工具來輔助SQL注入漏洞攻擊,加快入侵的速度,使SQL注入變得輕而易舉。

由於SQL注入漏洞攻擊利用的是通用的SQL語法,使得這種攻擊具有廣泛性。理論上說,對於所有基於SQL語言的資料庫管理系統都是有效的,包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。當然,各種系統自身的SQL擴展功能會有所不同,因此最終的攻擊代碼可能不盡相同。

1. 3 SQL注入漏洞攻擊過程

(1)繞過身份驗證

如一個login界面,需要輸入用戶名和口令,然後Post到另一個頁面,進行身份驗證,因此攻擊者只需在用戶名和口令的輸入框中都輸入aa or’1’=’1’的內容,那麼攻擊者就可以通過欺騙的驗證方式而直接進入下一個頁面,並擁有和正常登錄用戶一樣的全部特權。原因是什麼呢? 我們比較一下正常用戶登錄和攻擊者登錄時的兩種SQL語句:

1)正常用戶(如用戶名為admin,口令為1234567) :

SQL= " selectfrom users where username = ’admin’and password= ’1234567’ ";

2)攻擊者(用戶名和口令都為aa or’1’=’1’) :

SQL= " select * from users where username='aa or’1’=’1’'and password = ' aa or’1’=’1’'";

可以看到由and連接的兩個條件都被一個永遠成立的1=1所代替,執行的結果為true,資料庫會認為條件恆成立,會返回一個true,讓攻擊者以合法身份登錄進入下一個頁面。

(2)執行非法操作

如一個查詢頁面select1.asp? id=1,編程人員原本設計意圖是顯示id為1的查詢信息,而攻擊者利用程序中沒有對id內容進行檢查的機制,插入自己的代碼。

從select1.asp中摘錄一段關鍵代碼:

SQL= " select *from photo where photoid= 'id'";

可以看到,id沒有進行任何的處理,直接構成SQL語句並執行,而攻擊者在知道該系統資料庫中表名及欄位名的情況下,利用SQL語句特性(分號是將兩句SQL 語句分開的符號),直接向資料庫Tuser表中添加記錄:

select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理員'),然後攻擊者就可以直接用hack進行登錄了。通過這樣的方法,攻擊者還可以對系統做任何的事情,包括添加、刪除、修改系統資源的操作。

(3)執行系統命令

如果Web主機使用MSSQL資料庫管理系統,那麼攻擊者就可以用到xp_cmdshell這個擴展存儲過程,xp_cmdshell是一個非常有用的擴展存儲過程,用於執行系統命令,比如dir、net等,攻擊者可以根據程序的不同,提交不同的語句:

execmaster.dbo.xp_cmdshell " dir "; exec master.dbo.xp_cmdshell" net user hack 1234567 /add ";

execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add ";

這樣就可以向Web主機系統中成功添加了一個管理員帳戶。

2. SQL注入漏洞攻擊的檢測方式及方法

2. 1檢測方式

SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵後的檢測。入侵前的檢測,可以通過手工方式,也可以使用SQL注入漏洞掃描工具軟體。檢測的目的是為預防SQL注入漏洞攻擊,而對於SQL注入漏洞攻擊後的檢測,主要是針對審計日誌的查看,SQL注入漏洞攻擊成功後,會在Web Service和資料庫的審計日誌中留下“痕跡”。

2. 2檢測方法

(1)動態SQL檢查

動態的SQL語句是一個進行資料庫查詢的強大的工具,但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行,這樣就限制了入侵者的行動。當然,它不適用於存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下,用戶輸入的SQL命令仍可能得到執行,資料庫仍然存在SQL注入漏洞攻擊的危險。

(2)有效性校驗

如果一個輸入框只可能包括數字,那麼要通過驗證確保用戶輸入的都是數字。如果可以接受字母,檢查是不是存在不可接受的字元,那就需要設置字元串檢查功能。確保應用程序要檢查以下字元:分號、等號、破折號、括弧以及SQL關鍵字。

(3)數據表檢查

使用SQL注入漏洞攻擊工具軟體進行SQL注入漏洞攻擊後,都會在資料庫中生成一些臨時表。通過查看資料庫中最近新建的表的結構和內容,可以判斷是否曾經發生過SQL注入漏洞攻擊。

(4)審計日誌檢查

在Web伺服器中如果啟用了審計日誌功能,則Web Service審計日誌會記錄訪問者的IP地址、訪問時間、訪問文件等信息,SQL注入漏洞攻擊往往會大量訪問某一個頁面文件(存在SQL注入點的動態網頁),審計日誌文件會急劇增加,通過查看審計日誌文件的大小以及審計日誌文件中的內容,可以判斷是否發生過SQL注入漏洞攻擊事件;另外還可以通過查看資料庫審計日誌,查詢某個時間段是否有非法的插入、修改、刪除操作。

(5)其他

SQL注入漏洞攻擊成功後,入侵者往往會添加特權用戶(如:administrator、root、sa等)、開放非法的遠程服務以及安裝木馬後門程序等,可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。

3. 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許可權用戶的訪問,對不同的資料庫劃分不同的用戶許可權,這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作,就可以防止不同用戶對非授權的資料庫進行訪問。

4. 結束語

SQL注入漏洞攻擊在網上非常普遍,許多ASP、PHP論壇和文章管理系統、下載系統以及新聞系統都存在這個漏洞。造成SQL注入漏洞攻擊的主要原因是開發人員在系統開發的過程中編程不規范,沒有形成良好的編程習慣,問題的解決只有依賴於規范編程。此外,也可以使用現有的SQL注入漏洞掃描器對整個網站中的關鍵代碼進行掃描,查找網站頁面中存在的SQL注入點。對於有問題的頁面,可以及時刪除或更新。本文通過對SQL注入漏洞攻擊的方法、原理以及攻擊實施過程進行了闡述和總結,並給出了一些常見的SQL注入漏洞攻擊防範的方法。