溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

JavaScript同源策略有哪些

發(fā)布時間:2021-05-07 15:08:24 來源:億速云 閱讀:156 作者:Leah 欄目:開發(fā)技術

本篇文章給大家分享的是有關JavaScript同源策略有哪些,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。

JavaScript是什么

JavaScript是一種直譯式的腳本語言,其解釋器被稱為JavaScript引擎,是瀏覽器的一部分,JavaScript是被廣泛用于客戶端的腳本語言,最早是在HTML網頁上使用,用來給HTML網頁增加動態(tài)功能。

概述

  • 同源策略(Same-origin policy,簡稱 SOP)

  • 跨站請求偽造(Cross-site request forgery,簡稱 CSRF)

  • 跨域資源共享(Cross-Origin Resource Sharing,簡稱 CORS)

同源策略 SOP

同源

先解釋何為同源:協(xié)議、域名、端口都一樣,就是同源。

url同源
https://niconico.com基準
https://niconico.com/spirito
https://sub.niconico.com/spiritx
http://niconico.com/spiritx
https://niconico.com:8080/spiritx

限制

你之所以會遇到跨域問題,正是因為 SOP 的各種限制。但是具體來說限制了什么呢?

如果你說 SOP 就是“限制非同源資源的獲取”,這不對,最簡單的例子是引用圖片、css、js文件等資源的時候就允許跨域。

如果你說 SOP 就是“禁止跨域請求”,這也不對,本質上 SOP 并不是禁止跨域請求,而是在請求后攔截了請求的回應。這就就會引起后面說到的 CSRF

其實SOP 不是單一的定義,而是在不同情況下有不同的解釋:

  • 限制 cookies、DOM 和JavaScript的命名區(qū)域

  • 限制 iframe、圖片等各種資源的內容操作

  • 限制 ajax 請求,準確來說是限制操作 ajax 響應結果,本質上跟上一條是一樣的

下面是 3 個在實際應用中會遇到的例子:

  • 使用 ajax 請求其他跨域 API,最常見的情況,前端新手噩夢

  • iframe 與父頁面交流,出現(xiàn)率比較低,而且解決方法也好懂

  • 對跨域圖片(例如來源于<img>)進行操作,在 canvas 操作圖片的時候會遇到這個問題

如果沒有了 SOP:

  • 一個瀏覽器打開幾個 tab,數(shù)據(jù)就泄露了

  • 你用 iframe 打開一個銀行網站,你可以肆意讀取網站的內容,就能獲取用戶輸入的內容

  • 更加肆意地進行 CSRF

繞過跨域

SOP 帶來安全,同時也會帶來一定程度的麻煩,因為有時候就是有跨域的需求。繞過跨域的方案由于篇幅所限,并且網上也很多相關文章,所以不在這里展開解決跨域的方案,只給出幾個關鍵詞:

對于 ajax

  • 使用jsONP

  • 后端進行 CORS 配置

  • 后端反向代理

對于 iframe

  • 使用 location.hash 或 window.name 進行信息交流

  • 使用 postMessage

跨站請求偽造 CSRF

簡述

CSRF(Cross-site request forgery)跨站請求偽造,是一種常見的攻擊方式。是指 A 網站正常登陸后,cookie 正常保存,其他網站 B 通過某種方式調用 A 網站接口進行操作,A 的接口在請求時會自動帶上 cookie。

上面說了,SOP 可以通過htmltag 加載資源,而且 SOP 不阻止接口請求而是攔截請求結果,CSRF 恰恰占了這兩個便宜。

所以 SOP 不能作為防范 CSRF 的方法。

對于 GET 請求,直接放到<img>就能神不知鬼不覺地請求跨域接口。

對于 POST 請求,很多例子都使用 form 提交:

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
  <input type="hidden" name="acct" value="MARIA" />
  <input type="hidden" name="amount" value="100000" />
  <input type="submit" value="View my pictures" />
</form>

歸根到底,這兩個方法不報跨域是因為請求由html控制,你無法用 js 直接操作獲得的結果。

SOP 與 ajax

對于 ajax 請求,在獲得數(shù)據(jù)之后你能肆意進行 js 操作。這時候雖然同源策略會阻止響應,但依然會發(fā)出請求。因為執(zhí)行響應攔截的是瀏覽器而不是后端程序。事實上你的請求已經發(fā)到服務器并返回了結果,但是迫于安全策略,瀏覽器不允許你繼續(xù)進行 js 操作,所以報出你熟悉的blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.。

所以再強調一次,同源策略不能作為防范 CSRF 的方法。

不過可以防范 CSRF 的例外還是有的,瀏覽器并不是讓所有請求都發(fā)送成功,上述情況僅限于簡單請求,相關知識會在下面 CORS 一節(jié)詳細解釋。

CSRF 對策

SOP 被 CSRF 占了便宜,那真的是一無是處嗎?

不是!是否記得 SOP 限制了 cookie 的命名區(qū)域,雖然請求會自動帶上 cookies,但是攻擊者無論如何還是無法獲取 cookie 的內容本身。

所以應對 CSRF 有這樣的思路:同時把一個 token 寫到 cookie 里,在發(fā)起請求時再通過 query、body 或者 header 帶上這個 token。請求到達服務器,核對這個 token,如果正確,那一定是能看到 cookie 的本域發(fā)送的請求,CSRF 則做不到這一點。(這個方法用于前后端分離,后端渲染則可以直接寫入到 dom 中)

示例代碼如下:

var csrftoken = Cookies.get('csrfToken')

function csrfSafeMethod(method) {
  // these HTTP methods do not require CSRF protection
  return /^(GET|HEAD|OPTIONS|TRACE)$/.test(method)
}
$.ajaxSetup({
  beforeSend: function(xhr, settings) {
    if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
      xhr.setRequestHeader('x-csrf-token', csrftoken)
    }
  },
})

跨域資源共享 CORS

跨域是瀏覽器限制,但是如果服務器設置了 CORS 相關配置,在返回服務器的信息頭部會加上Access-Control-Allow-Origin,瀏覽器看到這個字段的值與當前的源匹配,就會解鎖跨域限制。

HTTP/1.1 200 OK

Date: Sun, 24 Apr 2016 12:43:39 GMT

Server: Apache

Access-Control-Allow-Origin: http://www.acceptmeplease.com

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Content-Type: application/xml

Content-Length: 423

對于 CORS,請求分兩種。

簡單請求

  • 請求方法使用 GET、POST 或 HEAD

  • Content-Type 設為 application/x-www-form-urlencoded、multipart/form-data 或 text/plain

符合上面兩個條件的都為 CORS 簡單請求。簡單請求都會直接發(fā)到服務器,會造成 CSRF。

預檢請求

不符合簡單請求要求的請求都需要先發(fā)送預檢請求(Preflight Request)。瀏覽器會在真正請求前發(fā)送 OPTION 方法的請求向服務器詢問當前源是否符合 CORS 目標,驗證通過后才會發(fā)送正式請求。

例如使用 application/json 傳參的 POST 請求就是非簡單請求,會在預檢中被攔截。

再例如使用 PUT 方法請求,也會發(fā)送預檢請求。

上面提到的可以防范 CSRF 的例外,就是指預檢請求。即使跨域成功請求預檢,但真正請求并不能發(fā)出去,這就保證了 CSRF 無法成功。

CORS 與 cookie

與同域不同,用于跨域的 CORS 請求默認不發(fā)送 Cookie 和 HTTP 認證信息,前后端都要在配置中設定請求時帶上 cookie。

這就是為什么在進行 CORS 請求時 axios 需要設置withCredentials: true。

下面是 node.js 的后臺 koa框架的 CORS 設置:

/**
 * CORS middleware
 *
 * @param {Object} [options]
 *  - {String|Function(ctx)} origin `Access-Control-Allow-Origin`, default is request Origin header
 *  - {String|Array} allowMethods `Access-Control-Allow-Methods`, default is 'GET,HEAD,PUT,POST,DELETE,PATCH'
 *  - {String|Array} exposeHeaders `Access-Control-Expose-Headers`
 *  - {String|Array} allowHeaders `Access-Control-Allow-Headers`
 *  - {String|Number} maxAge `Access-Control-Max-Age` in seconds
 *  - {Boolean} credentials `Access-Control-Allow-Credentials`
 *  - {Boolean} keepHeadersOnError Add set headers to `err.header` if an error is thrown
 * @return {Function} cors middleware
 * @api public
 */

以上就是JavaScript同源策略有哪些,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經查實,將立刻刪除涉嫌侵權內容。

AI