注入漏洞之sql注入漏洞


注入漏洞

1 SQL注入

   所謂SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執行指定的SQL語句。具體來說,它是利用現有應用程序,將SQL語句注入到後臺數據庫引擎執行的能力,它可以通過在Web表單中輸入SQL語句得到一個存在安全漏洞的網站上的數據,而不是按照設計者意圖去執行SQL語句。

1.1 SQL注入的概念
(1)SQL注入漏洞原理

   SQL注入攻擊指的是通過構建特殊的輸入作爲參數傳入Web應用程序,而這些輸入大都是SQL語法裏的一些組合,通過執行SQL語句進而執行攻擊者所要的操作,其主要原因是程序沒有細緻地過濾用戶輸入的數據,致使非法數據侵入系統。

根據相關技術原理,SQL注入可以分爲平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致;後者主要是由於程序員對輸入未進行細緻地過濾,從而執行了非法的數據查詢。基於此,SQL注入的產生原因通常表現在以下幾方面:①不當的類型處理;②不安全的數據庫配置;③不合理的查詢集處理;④不當的錯誤處理;⑤轉義字符處理不合適;⑥多個提交處理不當。

 

(2)SQL注入漏洞對於數據安全的影響

數據庫信息泄漏:數據庫中存放的用戶的隱私信息的泄露。
網頁篡改:通過操作數據庫對特定網頁進行篡改。
網站被掛馬,傳播惡意軟件:修改數據庫一些字段的值,嵌入網馬鏈接,進行掛馬攻擊。
數據庫被惡意操作:數據庫服務器被攻擊,數據庫的系統管理員帳戶被竄改。
服務器被遠程控制,被安裝後門。經由數據庫服務器提供的操作系統支持,讓黑客得以修改或控制操作系統。
破壞硬盤數據,癱瘓全系統。
一些類型的數據庫系統能夠讓SQL指令操作文件系統,這使得SQL注入的危害被進一步放大。

 

(3)SQL注入漏洞的方法

 

1.數字注入

   在瀏覽器地址欄輸入:learn.me/sql/article.php?id=1,這是一個get型接口,發送這個請求相當於調用一個查詢語句:

$sql = "SELECT * FROM article WHERE id =",$id

   正常情況下,應該返回一個id=1的文章信息。那麼,如果在瀏覽器地址欄輸入:learn.me/sql/article.php?id=-1 OR 1 =1,這就是一個SQL注入攻擊了,可能會返回所有文章的相關信息。爲什麼會這樣呢?

   這是因爲,id = -1永遠是false,1=1永遠是true,所有整個where語句永遠是ture,所以where條件相當於沒有加where條件,那麼查詢的結果相當於整張表的內容

2.字符串注入

   有這樣一個用戶登錄場景:登錄界面包括用戶名和密碼輸入框,以及提交按鈕。輸入用戶名和密碼,提交。

   這是一個post請求,登錄時調用接口learn.me/sql/login.html,首先連接數據庫,然後後臺對post請求參數中攜帶的用戶名、密碼進行參數校驗,即sql的查詢過程。假設正確的用戶名和密碼爲user和pwd123,輸入正確的用戶名和密碼、提交,相當於調用了以下的SQL語句:

SELECT * FROM user WHERE username = 'user' ADN password = 'pwd123'

       由於用戶名和密碼都是字符串,SQL注入方法即把參數攜帶的數據變成mysql中註釋的字符串。mysql中有2種註釋的方法:

1)'#':'#'後所有的字符串都會被當成註釋來處理

  用戶名輸入:user'#(單引號閉合user左邊的單引號),密碼隨意輸入,如:111,然後點擊提交按鈕。等價於SQL語句:

SELECT * FROM user WHERE username = 'user'#'ADN password = '111'

   '#'後面都被註釋掉了,相當於:

SELECT * FROM user WHERE username = 'user' 

2)'-- ' (--後面有個空格):'-- '後面的字符串都會被當成註釋來處理

   用戶名輸入:user'-- (注意--後面有個空格,單引號閉合user左邊的單引號),密碼隨意輸入,如:111,然後點擊提交按鈕。等價於SQL語句:

SELECT * FROM user WHERE username = 'user'-- 'AND password = '111'

   '-- '後面都被註釋掉了,相當於:

SELECT * FROM user WHERE username = 'user'

   因此,以上兩種情況可能輸入一個錯誤的密碼或者不輸入密碼就可登錄用戶名爲'user'的賬號,這是十分危險的事情。

 

1.2 SQL注入的安全防護
(1)掌握SQL注入漏洞修復和防範方法

 

1、 普通用戶與系統管理員用戶的權限要有嚴格的區分。


  如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句,那麼是否允許執行呢?由於Drop語句關係到數據庫的基本對象,故要操作這個語句用戶必須有相關的權限。在權限設計中,對於終端用戶,即應用軟件的使用者,沒有必要給他們數據庫對象的建立、刪除等權限。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼,由於其用戶權限的限制,這些代碼也將無法被執行。故應用程序在設計的時候,最好把系統管理員的用戶與普通用戶區分開來。如此可以最大限度的減少注入式攻擊對數據庫帶來的危害。


2、 強迫使用參數化語句。


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

 

3、 加強對用戶輸入的驗證。

 

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

 

4、 多多使用SQL Server數據庫自帶的安全參數。


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


5、 多層環境如何防治SQL注入式攻擊?


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


6、 必要的情況下使用專業的漏洞掃描工具來尋找可能被攻擊的點。


  使用專業的漏洞掃描工具,可以幫助管理員來尋找可能被SQL注入式攻擊的點。不過漏洞掃描工具只能發現攻擊點,而不能夠主動起到防禦SQL注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜索攻擊目標並實施攻擊。爲此在必要的情況下,企業應當投資於一些專業的漏洞掃描工具。一個完善的漏洞掃描程序不同於網絡掃描程序,它專門查找數據庫中的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。所以憑藉專業的工具,可以幫助管理員發現SQL注入式漏洞,並提醒管理員採取積極的措施來預防SQL注入式攻擊。如果攻擊者能夠發現的SQL注入式漏洞數據庫管理員都發現了並採取了積極的措施堵住漏洞,那麼攻擊者也就無從下手了。

 

7、設置陷阱賬號:

 

設置兩個帳號,一個是普通管理員帳號,一個是防注入的帳號。將防注入的賬號設置的很象管理員,如 admin,以製造假象吸引軟件的檢測,而密碼是大於千字以上的中文字符,迫使軟件分析賬號的時候進入全負荷狀態甚至資源耗盡而死機。

(2)掌握一些SQL注入漏洞檢測工具的使用方法

      Sqlmap 使用方法:
--is-dba 當前用戶權限(是否爲root權限,mssql下最高權限爲sa)
--dbs 所有數據庫
--current-db 網站當前數據庫
--users 所有數據庫用戶
--current-user 當前數據庫用戶
--random-agent 構造隨機user-agent
--passwords 數據庫密碼
--proxy http://local:8080 –threads 10 (可以自定義線程加速) 代理
--time-sec=TIMESEC DBMS響應的延遲時間(默認爲5秒)
--threads=  使用多少線程
--batch    選擇默認選項

百度很多sqlmap教程,此處舉例:

sqlmap  -u "http://xxx/?id=1" (-u參數指定目標註入地址)檢測出存在可利用漏洞

sqlmap -u "http://xxx/?id=1"  --dbs   列取數據庫的所有庫

sqlmap -u "http://xxx/?id=1" --current-db     查詢出當前庫

sqlmap -u "http://xxx/?id=1" -D xxx --tables  查詢某個庫的所有表

sqlmap -u "http://xxx/?id=1" -D xxx -T xxx --columns(-D dbname指定數據庫名稱、-T tablename:指定某數據表的名稱、--columns:列出指定表上的所有列)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章