不要再問我跨域的問題了

發表於2018-07-16

寫下這篇文章後我想,要不以後就把這種基礎的常見知識都歸到這個“不要再問我XX的問題”,形成一系列內容,希望大家看完之後再有人問你這些問題,你心裡會竊喜:“嘿嘿,是時候展現真正的技術了!”
一、不要再問我this的指向問題了

跨域這兩個字就像一塊狗皮膏藥一樣黏在每一個前端開發者身上,無論你在工作上或者面試中無可避免會遇到這個問題。為了應付面試,我每次都隨便背幾個方案,也不知道為什麼要這樣幹,反正面完就可以扔了,我想工作上也不會用到那麼多亂七八糟的方案。到了真正工作,開發環境有webpack-dev-server搞定,上線了服務端的大佬們也會配好,配了什麼我不管,反正不會跨域就是了。日子也就這麼混過去了,終於有一天,我覺得不能再繼續這樣混下去了,我一定要徹底搞懂這個東西!於是就有了這篇文章。

要掌握跨域,首先要知道為什麼會有跨域這個問題出現

確實,我們這種搬磚工人就是為了混口飯吃嘛,好好的調個介面告訴我跨域了,這種阻礙我們輕鬆搬磚的事情真噁心!為什麼會跨域?是誰在搞事情?為了找到這個問題的始作俑者,請點選瀏覽器的同源策略
這麼官方的東西真難懂,沒關係,至少你知道了,因為瀏覽器的同源策略導致了跨域,就是瀏覽器在搞事情。
所以,瀏覽器為什麼要搞事情?就是不想給好日子我們過?對於這樣的質問,瀏覽器甩鍋道:“同源策略限制了從同一個源載入的文件或指令碼如何與來自另一個源的資源進行互動。這是一個用於隔離潛在惡意檔案的重要安全機制。”
這麼官方的話術真難懂,沒關係,至少你知道了,似乎這是個安全機制。
所以,究竟為什麼需要這樣的安全機制?這樣的安全機制解決了什麼問題?別急,讓我們繼續研究下去。

沒有同源策略限制的兩大危險場景

據我瞭解,瀏覽器是從兩個方面去做這個同源策略的,一是針對介面的請求,二是針對Dom的查詢。試想一下沒有這樣的限制上述兩種動作有什麼危險。

沒有同源策略限制的介面請求

有一個小小的東西叫cookie大家應該知道,一般用來處理登入等場景,目的是讓服務端知道誰發出的這次請求。如果你請求了介面進行登入,服務端驗證通過後會在響應頭加入Set-Cookie欄位,然後下次再發請求的時候,瀏覽器會自動將cookie附加在HTTP請求的頭欄位Cookie中,服務端就能知道這個使用者已經登入過了。知道這個之後,我們來看場景:
1.你準備去清空你的購物車,於是開啟了買買買網站www.maimaimai.com,然後登入成功,一看,購物車東西這麼少,不行,還得買多點。
2.你在看有什麼東西買的過程中,你的好基友發給你一個連結www.nidongde.com,一臉yin笑地跟你說:“你懂的”,你毫不猶豫開啟了。
3.你饒有興致地瀏覽著www.nidongde.com,誰知這個網站暗地裡做了些不可描述的事情!由於沒有同源策略的限制,它向www.maimaimai.com發起了請求!聰明的你一定想到上面的話“服務端驗證通過後會在響應頭加入Set-Cookie欄位,然後下次再發請求的時候,瀏覽器會自動將cookie附加在HTTP請求的頭欄位Cookie中”,這樣一來,這個不法網站就相當於登入了你的賬號,可以為所欲為了!如果這不是一個買買買賬號,而是你的銀行賬號,那……
這就是傳說中的CSRF攻擊淺談CSRF攻擊方式
看了這波CSRF攻擊我在想,即使有了同源策略限制,但cookie是明文的,還不是一樣能拿下來。於是我看了一些cookie相關的文章聊一聊 cookieCookie/Session的機制與安全,知道了服務端可以設定httpOnly,使得前端無法操作cookie,如果沒有這樣的設定,像XSS攻擊就可以去獲取到cookieWeb安全測試之XSS;設定secure,則保證在https的加密通訊中傳輸以防截獲。

沒有同源策略限制的Dom查詢

1.有一天你剛睡醒,收到一封郵件,說是你的銀行賬號有風險,趕緊點進www.yinghang.com改密碼。你嚇尿了,趕緊點進去,還是熟悉的銀行登入介面,你果斷輸入你的賬號密碼,登入進去看看錢有沒有少了。
2.睡眼朦朧的你沒看清楚,平時訪問的銀行網站是www.yinhang.com,而現在訪問的是www.yinghang.com,這個釣魚網站做了什麼呢?

由此我們知道,同源策略確實能規避一些危險,不是說有了同源策略就安全,只是說同源策略是一種瀏覽器最基本的安全機制,畢竟能提高一點攻擊的成本。其實沒有刺不穿的盾,只是攻擊的成本和攻擊成功後獲得的利益成不成正比。

跨域正確的開啟方式

經過對同源策略的瞭解,我們應該要消除對瀏覽器的誤解,同源策略是瀏覽器做的一件好事,是用來防禦來自邪門歪道的攻擊,但總不能為了不讓壞人進門而把全部人都拒之門外吧。沒錯,我們這種正人君子只要開啟方式正確,就應該可以跨域。
下面將一個個演示正確開啟方式,但在此之前,有些準備工作要做。為了本地演示跨域,我們需要:
1.隨便跑起一份前端程式碼(以下前端是隨便跑起來的vue),地址是http://localhost:9099。
2.隨便跑起一份後端程式碼(以下後端是隨便跑起來的node koa2),地址是http://localhost:9971。

同源策略限制下介面請求的正確開啟方式

1.JSONP
在HTML標籤裡,一些標籤比如script、img這樣的獲取資源的標籤是沒有跨域限制的,利用這一點,我們可以這樣幹:

後端寫個小介面

簡單版前端

簡單封裝一下前端這個套路

2.空iframe加form
細心的朋友可能發現,JSONP只能發GET請求,因為本質上script載入資源就是GET,那麼如果要發POST請求怎麼辦呢?

後端寫個小介面

前端

3.CORS

CORS是一個W3C標準,全稱是”跨域資源共享”(Cross-origin resource sharing)跨域資源共享 CORS 詳解。看名字就知道這是處理跨域問題的標準做法。CORS有兩種請求,簡單請求和非簡單請求。

這裡引用上面連結阮一峰老師的文章說明一下簡單請求和非簡單請求。
瀏覽器將CORS請求分成兩類:簡單請求(simple request)和非簡單請求(not-so-simple request)。

只要同時滿足以下兩大條件,就屬於簡單請求。
(1) 請求方法是以下三種方法之一:

  • HEAD
  • GET
  • POST

(2)HTTP的頭資訊不超出以下幾種欄位:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type:只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

1.簡單請求
後端

前端什麼也不用幹,就是正常發請求就可以,如果需要帶cookie的話,前後端都要設定一下,下面那個非簡單請求例子會看到。

2.非簡單請求
非簡單請求會發出一次預檢測請求,返回碼是204,預檢測通過才會真正發出請求,這才返回200。這裡通過前端發請求的時候增加一個額外的headers來觸發非簡單請求。
clipboard.png

後端

一個介面就要寫這麼多程式碼,如果想所有介面都統一處理,有什麼更優雅的方式呢?見下面的koa2-cors。

前端

4.代理
想一下,如果我們請求的時候還是用前端的域名,然後有個東西幫我們把這個請求轉發到真正的後端域名上,不就避免跨域了嗎?這時候,Nginx出場了。
Nginx配置

前端就不用幹什麼事情了,除了寫介面,也沒後端什麼事情了

Nginx轉發的方式似乎很方便!但這種使用也是看場景的,如果後端介面是一個公共的API,比如一些公共服務獲取天氣什麼的,前端呼叫的時候總不能讓運維去配置一下Nginx,如果相容性沒問題(IE 10或者以上),CROS才是更通用的做法吧。

同源策略限制下Dom查詢的正確開啟方式

1.postMessage
window.postMessage() 是HTML5的一個介面,專注實現不同視窗不同頁面的跨域通訊。
為了演示方便,我們將hosts改一下:127.0.0.1 crossDomain.com,現在訪問域名crossDomain.com就等於訪問127.0.0.1。

這裡是http://localhost:9099/#/crossDomain,發訊息方

這裡是http://crossdomain.com:9099,接收訊息方

結果可以看到:

clipboard.png

2.document.domain
這種方式只適合主域名相同,但子域名不同的iframe跨域。
比如主域名是http://crossdomain.com:9099,子域名是http://child.crossdomain.com:9099,這種情況下給兩個頁面指定一下document.domain即document.domain = crossdomain.com就可以訪問各自的window物件了。

3.canvas操作圖片的跨域問題
這個應該是一個比較冷門的跨域問題,張大神已經寫過了我就不再班門弄斧了解決canvas圖片getImageData,toDataURL跨域問題

最後

希望看完這篇文章之後,再有人問跨域的問題,你可以嘴角微微上揚,冷笑一聲:“不要再問我跨域的問題了。”
揚長而去。

相關文章