前言
這幾天在拜讀道哥的<<白帽子講Web安全>>這本書,在看瀏覽器安全這章第一次接觸到同源策略(Same Origin Policy)這個詞,再加上道哥對SOP(Same Origin Policy)的字裏行間都透露着其不二般的重要性,所以SOP自然毫無疑問值得我寫一篇博客來記錄對它的學習了!
此處以一張來自wooyun鏡像的截圖證明SOP在瀏覽器安全中的地位
正文開始
什麼是同源策略
首先要了解同源包含了"三個相同"
- 協議相同
- 域名相同
- 端口相同
下面先以http://www.0wl.org/hello/csdn.html爲例子來了解了解"同源"的概念
| http://www.0wl.org/hello/csdn.html | 作爲參照 |
|---|---|
| http://www.0wl.org/hello/csdn.html | 同源 |
| https://www.0wl.org/hello/csdn.html | 不同源(協議不同) |
| http://www.xxx.org/hello/csdn.html | 不同源(域名不同) |
| http://www.0wl.org:6666/hello/csdn.html | 不同源(端口不同) |
現在來看看SOP的介紹
同源策略是一種約定，是瀏覽器最核心也最基本的安全功能，主要體現在SOP會限制來自不同源的文檔和腳本對當前源的文檔數據的讀取或設置某些屬性，是用於隔離潛在惡意文件的重要安全機制。
注意"限制"二字,同源策略只是對源做了限制,而並非是完全隔離.看到這裏,你或許會想,爲什麼不完全隔離呢,這樣豈不是就不會出現跨域的bug了,簡直就是一勞永逸啊,我在查閱相關資料之前也是這麼想的,但是在實際中這種方法的可行性實在太低,下面讓我來爲你解釋爲何不行.
你可以試想一下,假如網站把html,javascript,image,css等文件全部放在一臺服務器上,像個人博客這種小網站或許可以,但是稍微大一點的網站服務器肯定是扛不住的,而且極大的降低了網站的靈活性和可用性,所以瀏覽器爲了提升網站的靈活性,只好只好降低一點點安全性咯,同時這就是爲什麼我們在遵循同源策略的網站中還能看見img , script, src, style等標籤的身影.
寫到到這裏,對同源策略的初步認識也就結束了,下面我們看看在同源策略控制下的web世界被做了哪些限制.
iframe限制
- 可以訪問同域資源, 可讀寫
- 訪問跨域頁面時, 只讀
Ajax限制
Ajax 的限制比 iframe 限制更嚴
- 同域資源可讀寫
- 跨域請求會直接被瀏覽器攔截.(chrome下跨域請求不會發起, 其他瀏覽器一般是可發送跨域請求, 但響應被瀏覽器攔截)
Script限制
script並無跨域限制, 這是因爲script標籤引入的文件不能夠被客戶端的 js 獲取到, 不會影響到原頁面的安全, 因此script標籤引入的文件沒必要遵循瀏覽器的同源策略. 相反, ajax 加載的文件內容可被客戶端 js 獲取到, 引入的文件內容可能會泄漏或者影響原頁面安全, 故, ajax必須遵循同源策略.
但是千萬不要以爲對web做了限制就安全了,因爲黑客的思維是無法被限制的,在後期的博客中我會介紹一些繞過同源策略的方式.接下來先講講一些"正確"的跨域訪問方式.
跨域訪問
XMLHttpRequest的跨域
JSONP
JSONP就是利用 `` 標籤的跨域能力實現跨域數據的訪問，請求動態生成的JavaScript腳本同時帶一個callback函數名作爲參數。
服務端收到請求後，動態生成腳本產生數據，並在代碼中以產生的數據爲參數調用callback函數。
CORS
CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。它是跨域AJAX請求的根本的解決辦法.相比JSONP的只能以GET請求,CORS支持所有類型的HTTP請求.其請求方式也可以分爲簡單請求和非簡單請求。
簡單請求
只要同時滿足以下兩大條件，就屬於簡單請求。
a. 請求方法是以下三種方法之一:
- HEAD
- GET
- POST
b.HTTP的頭信息不超出以下幾種字段:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain
非簡單請求
非簡單請求會發出一次預檢測請求，返回碼是204，預檢測通過纔會真正發出請求，這才返回200。這裏通過前端發請求的時候增加一個額外的headers來觸發非簡單請求
WebSocket
WebSocket是一種新的通信協議，能夠在一個持久連接上提供全雙工、雙向通信。使用url模式也略有不同。使用ws://(非加密)和wss://(加密)作爲協議前綴.該協議並沒有遵循同源策略,只要服務器支持,就可以通過該協議進行跨域通信.
代理
-
正向代理
需要藉助同源的代理服務器，瀏覽器先將請求發送給代理服務器，代理服務器接收請求並其轉發給目標數據服務器，因爲不同源的兩個服務器的交互不遵循同源策略
-
反向代理
可以用Nginx反向代理來實現(服務端之間的資源交互不會有跨域限制)
Cookie的跨域
同源的頁面纔可以共享cookie，但是如果兩個源的一級域名相同，二級域名不同，瀏覽器可以通過設置document.domain來共享cookie
這裏只介紹了我認爲會涉及到安全問題的跨域訪問的種類(剩下的等日後深入的時候在做詳解),講這麼多,其實最主要的目的就是學習基於SOP的Web安全問題,即JSONP劫持和CORS跨域漏洞.
所以,下面先粗略的瞭解瞭解常見的安全問題,此處只作粗略地介紹.因爲我後續還要寫關於對CORS漏洞和JSONP劫持深入學習的博客.
安全問題
CORS 跨域漏洞
關於 CORS 的相關介紹上面已經寫了，這個漏洞產生的主要原因是服務端的配置不當。
CORS跨域漏洞的攻擊流程
若用戶登陸了含有CORS配置的網站0wl.com，同時又訪問了攻擊者提供的一個鏈接Hacker.com
然後從Hacker.com網站再向0wl.com這個網站發起獲取敏感數據的請求
如果網站0wl.com配置了Access-Control-Allow-Origin頭且爲預期
那麼攻擊者就可以通過跨域獲取用戶的敏感數據了
以下是Server端通過設置http請求頭來指定允許請求的域的聲明：
Access-Control-Allow-Origin: http://0wl.com
如果發起請求的域不在Server端的白名單內，那麼瀏覽器將會屏蔽響應包,不予迴應。
是否允許請求包攜帶 Cookie的聲明：
Access-Control-Allow-Credentials: true
出於對安全性的考慮，CORS 協議中有一個特殊限制:
服務端不能在既允許所有請求域的情況下，又同時允許請求包攜帶 Cookie。
CORS結合XSS漏洞進行利用
在有的情況下,假如A站的CORS配置中有信任自身的任何一個子域的許可，那也就意味着,如果該網站的某個子域存在XSS漏洞,那麼此時攻擊者將輕而易舉地就可以通過這個XSS漏洞去讀取其他任意子域的資源,甚至還可以與其他漏洞打組合拳,進行聯動攻擊。
JSONP 劫持
jsonp 劫持就是攻擊者獲取了本應該傳給網站其他接口的數據
下面是JSONP漏洞利用的過程(圖片來源於互聯網)
1）用戶在網站B 註冊並登錄，網站B 包含了用戶的id，name，phone number,email,address等信息
2）用戶通過瀏覽器向網站A發出URL請求
3）網站A向用戶返回響應頁面，響應頁面中註冊了JavaScript的回調函數和向網站B請求的script標籤
4）用戶收到響應，解析JS代碼，將回調函數作爲參數向網站B發出請求
5）網站B接收到請求後，解析請求的URL，以JSON 格式生成請求需要的數據，將封裝的包含用戶信息的JSON數據作爲回調函數的參數返回給瀏覽器，網站B返回數據
6）網站B數據返回後，瀏覽器則自動對步驟4返回的JSON格式數據進行處理，通過alert彈窗展示了用戶在網站B的註冊信息。另外也可將JSON數據回傳到網站A的服務器，這樣網站A利用網站B的JSONP漏洞便獲取到了用戶在網站B註冊的信息
對於以上的攻擊原理及實現我將在後續的博客中寫.感興趣的可以關注我後期的博客哦!