【web安全】跨站***思路整理

接觸跨站***一段時間了,有了一些認識,如今先按本身的理解理一下思路。後續有時間在針對裏面詳細的***方法作詳解。javascript

一.跨站腳本介紹java

跨站腳本***(XSS)是一種***技術,是***者將惡意代碼插入到迴應給用戶瀏覽器的代碼中的一種實例。跨站腳本的幾個特色:web

受害者:跨站做用在客戶端,而不是服務端,即受害者是客戶端而不是服務器。數據庫

跨站類型:反射式;持久式;基於DOM式;其它式(包括嵌入FLASH,PDF等其它載體)。瀏覽器

1. 非持久型XSS漏洞通常存在於URL參數中,須要訪問***構造好的特定URL才能觸發漏洞。安全

2. 持久型XSS漏洞通常存在於富文本等交互功能,如發帖留言等,***使用的XSS內容經正常功能進入數據庫持久保存。服務器

3. DOM XSS漏洞,也分爲持久和非持久型兩種,可能是經過javascript DOM接口獲取地址欄、referer或編碼指定HTML標籤內容形成。cookie

4. FLASH,PDF等其餘第三方文件所形成的特殊XSS漏洞,一樣按應用功能也分爲持久和非持久型。框架

對跨站三種類型的理解:客戶端執行了 客戶端提交給服務端,服務端返回的惡意代碼。dom

反射型:服務端提取用戶的輸入,未作嚴格過濾,直接返回給客戶端,客戶端瀏覽器執行了代碼。

1)對數據未作嚴格淨化返回給客戶端。

2)實現***須要點擊***者構造的連接,每次點擊完成一次***,由於不能保存。

存儲型:

1)對數據未作嚴格淨化返回給客戶端,客戶端執行了惡意代碼。

2)***者構造連接完成***,受害者點擊正常的連接,就會受影響。由於代碼已經被保存。

DOM型:

1)對數據未作嚴格淨化返回給客戶端,客戶端執行了惡意代碼。

2)服務端返回給客戶端的是一樣的代碼(js代碼),在客戶執行的時候纔出問題,在服務端的響應中是沒有惡意代碼的。DOM型能夠是反射型或者存儲型,在於js代碼是否存儲輸入的值。

 

幾個區別:

反射式和存儲式的區別:

1)服務端對數據的處理方式:一個是保存後返回,一個是直接返回。

2)出現的觸發點不同:反射通常出如今返回錯誤信息等,而存儲通常

出如今填寫表單等。(本質是第一個的緣由,看哪些狀況是要保存數據的,哪些狀況是不保存數據的)

3)是不是一次性的,反射是一次性,每次都要點。 存儲不是。(本質也是第一個緣由,由於存儲保存了代碼)。

因此綜上,區別其實就一個,就是服務端有沒有保存數據,其餘就是根據特色得出的。

DOM式和上面的兩個的區別:

DOM是由於服務端處理數據用的是js代碼,不會對數據進行處理

而是到達瀏覽器後才處理的,因此在響應代碼中是沒有惡意代碼的。它也能夠是保存或者反射,在於js代碼中有沒有保存輸入的值。

 

二.CST、CFS、CSRF

2.1 CST

CST***是一種使用XSS和HTTP TRACE功能來進行***的方式。它是一種***技巧,能夠利用它避開HttpOnly對cookie提供的保護,使之可以經過客戶端JavaScript獲取已經標記爲HttpOnly的cookie值。

正常狀況下,客戶端腳本(如JS腳本)是能夠經過document.cookie函數得到,這樣若是有XSS跨站漏洞,cookie很容易被盜取。瀏覽器有一個安全策略,經過設置cookie的httponly屬性,這樣客戶端腳本就不能經過document.cookie訪問該cookie,即時有跨站漏洞,也不能盜取用戶cookie。(注意:httponly屬性對正常的HTTP請求並無影響,即時Cookie設置了HTTPONLY屬性,當用戶瀏覽有效域中的站點時候,這個Cookie仍然被自動發送,只是不能使用腳原本訪問該Cookie。(解釋HTTPONLY)

通常客戶端向服務器請求是利用HTTP GET和POST方式,但那只是常見,還有其它方式(詳細參考RFC2616文檔)。其中HTTP TRACE也是一種方式,這種向服務端請求信息主要用於調試web服務器鏈接用。若是請求有效,則在響應中會在實體中包含整個請求消息。(解釋HTTP TRACE)

與XSS聯繫和區別:

聯繫:CST是XSS的一種子類,也屬於XSS跨站漏洞。

區別:瀏覽器請求的方式不同,普通的XSS通常經過GET和POST方式在頁面上輸入***腳本實現,可是CST若是要在頁面上輸入,須要找到會經過TRACE發送的輸入點,通常是本身構造***報文在TRACE方法中進行發送。

測試相關:

因爲普通的XSS***報文能夠經過GET或者POST被提交,而CST則要經過TRACE來提交,因爲比較少用,目前還未搜索到有頁面輸入框可使用TRACE提交的。所以對它的測試須要注意,***腳本中須要本身提供發送函數,好比使用XMLHttpRequest發送請求(固然普通的XSS***也須要覆蓋用XMLHTTPRequest發送GET、POST請求)。

測試總結:對CST的測試只須要將普通XSS的***特徵腳本放在HTTP的TRACE位置發送出去就能夠。

2.2 CFS

在瀏覽器的安全機制中,客戶端腳本是不能訪問不一樣服務器或域名的頁面相關信息。而經過HTML的frame/iframe能夠在頁面中包含第三方服務器的頁面,這樣***者能夠利用主頁面的腳本程序獲取到frame/iframe包含的第三方服務器的信息。

同源策略:客戶端腳本是不能訪問不一樣服務器或域名的頁面相關信息,可是也有例外,能夠經過設置document.domain解決,在兩個不一樣域名的客戶端腳本都設置document.domain爲同個父域。(注意:兩個域是要擁有同個父域這個方法纔有效果),而後在主頁面加載FRAME/IFRAME頁面實現,主頁就能夠調用框架內的頁面的元素。

與XSS的聯繫和區別:

聯繫:CFS是XSS的一種***子類,也屬於XSS跨站漏洞。

區別:CFS主要利用HTML中的FRAME/IFRAME來實現跨站***。將他單獨出來,主要是因爲他***後效果不一樣,有一些特殊的場景。

測試相關:

CFS的測試和XSS的測試同樣,被包含在XSS測試中,是它的一個子集,特徵爲frame和iframe關鍵字。若是針對性測試,就是對frame和iframe進行各類編碼。

2.3 CSRF 

CSRF:cross site request forgery,跨站請求僞造。是一種將受害用戶欺騙到包含有惡意HTTP請求的頁面的***方式,這種***方式的危害性在於它繼承了受害用戶的實體身份和權限,即盜用了受害人的身份以其的名義進行非法的操做,好比篡改用戶資料、用戶密碼、以及購買物品等。通俗的說,CSRF***是在受害者絕不知情的狀況下以受害者名義僞造請求發送給受***站點,從而在未受權的狀況下執行受害者權限保護之下的操做。

CSRF(XSRF)的本質:服務端對客戶端的COOKIE校驗不嚴格,致使被***者盜用。

 

CSRF***方式

1)狀況一:站點B和站點A是不一樣站點,站點B中的請求代碼URL沒有包含腳本,而是正常的請求狀況,只是利用了瀏覽器而瀏覽器不知道而已。這個時候用戶點擊惡意網站B發送給站點A的報文 和 用戶真實發送給站點A的報文只有在referer字段有所區別。Referer字段會顯示發送的起始域,也就是站點B。

2)狀況二:站點B和站點A重合,這個時候利用站點B的存儲XSS漏洞使得用戶發送請求給站點A的其它頁面。

3)狀況三:站點B和站點A是不一樣站點,可是站點B中的請求的代碼含有JS代碼來實現相應功能。同時站點A有XSS漏洞,會使得傳給站點A的代碼返回到客戶端執行。

以上三種狀況僅狀況二是比較特殊的,測試時候須要構造referer字段與用戶登陸的時候域不同的域名,其它兩種同XSS***無區別。

 

與XSS的聯繫和區別:

聯繫:CSRF能夠利用XSS實現更有用的***(常常也這麼用)。上述情

二和狀況三就是利用XSS漏洞的狀況。

區別:CSRF不是XSS的子類,他們的本質問題不同。XSS本質是服務端對輸入過濾不嚴然後輸出的時候將客戶端的腳本再輸出。CSRF是服務端對用戶的身份認證不嚴格(cookie等),使得***者冒充用戶達到***目的。

測試相關:

對於CSRF測試,兩個方面測試:

1)包括XSS測試,同XSS測試,重點在於請求方法。主要有兩種:XMLHTTPRequest和帶有SRC屬性的標籤(frame、iframe、img、input)等。

2)測試Referer域的URL是其它地址,非請求的本URL地址。

 

三. 跨站***整個學習思路:

     跨站本質-->跨站類型分析-->有效載荷內容(就是能完成什麼***,***效果上)-->載荷傳送方式--》檢測漏洞方式 

CST和CFS都是在有效載荷內容上的區別。

CSRF本質跟XSS不同,常常是利用XSS漏洞的功能完成載荷更復雜的功能,達到更好的***效果。

相關文章
相關標籤/搜索