摘要:比如基于的方法我認(rèn)為只有是正當(dāng)?shù)睦@過同源策略的方法同源策略是瀏覽器安全策略的基礎(chǔ),但同源策略面對(duì)很多攻擊是無能為力的,比如跨站腳本攻擊,名字跟同源策略很像,事實(shí)上他們之間基本沒有關(guān)系。
作者:肖光宇
野狗科技聯(lián)合創(chuàng)始人,先后在貓撲、百度、搜狗任職,愛折騰的前端工程師。
野狗官博:https://blog.wilddog.com/
野狗官網(wǎng):https://www.wilddog.com/
公眾訂閱號(hào):wilddogbaas
Web安全是一個(gè)如何強(qiáng)調(diào)都不為過的事情,我們發(fā)現(xiàn)國(guó)內(nèi)的眾多網(wǎng)站都沒有實(shí)現(xiàn)全站https,對(duì)于其他安全策略的實(shí)踐更是很少,本文的目的并非討論安全和攻擊的細(xì)節(jié),而是從策略的角度引發(fā)對(duì)安全的思考和重視。
1. 數(shù)據(jù)通道安全http協(xié)議下的網(wǎng)絡(luò)連接都是基于明文的,信息很有可能被泄露篡改,甚至用戶都不知道通信的對(duì)方是否就是自己希望連接的服務(wù)器。因此,信息通道安全有以下兩個(gè)目標(biāo):
身份認(rèn)證
數(shù)據(jù)不被泄漏和篡改
幸運(yùn)的是https解決了上述問題的(更多關(guān)于https的細(xì)節(jié)可以看下上一篇干貨扒一扒https網(wǎng)站的內(nèi)幕)。理論上https是安全的,即使如此,https依然應(yīng)該被重視,因?yàn)槔碚撋侠碚摵蛯?shí)踐是一樣的,但實(shí)踐中又是另外一回事。前段時(shí)間爆發(fā)的心血漏洞就是一個(gè)例子。
2. 瀏覽器安全https解決了點(diǎn)到點(diǎn)的安全問題和身份認(rèn)證問題,接下來會(huì)出現(xiàn)問題的地方就只有2個(gè):瀏覽器和服務(wù)器,這個(gè)層面上的安全問題并沒有https一樣的銀彈可以一次性解決。
2.1 origin 源了解瀏覽器安全,有一個(gè)概念特別重要,那就是源(origin) 什么是源呢?
相同的HOST
相同的協(xié)議
相同的端口
舉栗子:
https//www.wilddog.com和http//www.wilddog.com非同源,因?yàn)閰f(xié)議不同。
http//wilddog.com和http//www.wilddog.com非同源,因?yàn)橛蛎煌?/p>
http//wilddog.com和http//wilddog.com:8080非同源,因?yàn)槎丝诓煌?/p>
源這個(gè)概念為甚這么重要,這要從同源策略說起。
2.2 同源策略同源策略限制了一個(gè)源(origin)中加載文本或腳本與來自其它源(origin)中資源的交互方式。簡(jiǎn)單的說就是一個(gè)源的頁(yè)面上的js只能訪問當(dāng)前源的資源,不能訪問其他源的資源。那么資源是什么呢?
DOM
通過AJAX請(qǐng)求的網(wǎng)絡(luò)資源
Cookie
WebStorage,webSql
...
很顯然,同源策略以源為單位,把資源天然分隔,保護(hù)了用戶的信息安全。
同源策略是一堵墻,然而墻并非不透風(fēng)。有很多方法可以繞過同源策略讓javascript訪問其他源的資源。比如:
JSONP:基于iframe的方法(iframe+window.name iframe+window.domain iframe+webMessage)
CORS:我認(rèn)為只有CORS是"正當(dāng)?shù)?繞過同源策略的方法 同源策略是瀏覽器安全策略的基礎(chǔ),但同源策略面對(duì)很多攻擊是無能為力的,比如XSS
2.3 XSS (Cross-Site Script)跨站腳本攻擊,名字跟同源策略很像,事實(shí)上他們之間基本沒有關(guān)系??缯灸_本攻擊本質(zhì)上是一種注入攻擊(有興趣了解更多注入攻擊可以看Injection Theory)。其原理,簡(jiǎn)單的說就是利用各種手段把惡意代碼添加到網(wǎng)頁(yè)中,并讓受害者執(zhí)行這段腳本。XSS的例子只要百度一下有很多。XSS能做用戶使用瀏覽器能做的一切事情??梢钥吹酵床呗詿o法保證不受XSS攻擊,因?yàn)榇藭r(shí)攻擊者就在同源之內(nèi)。
XSS攻擊從攻擊的方式可以分為:
反射型
存儲(chǔ)型
文檔型
這種分類方式有些過時(shí),長(zhǎng)久以來,人們認(rèn)為XSS分類有以上三種,但實(shí)際情況中經(jīng)常無法區(qū)分,所以更明確的分類方式可以分為以下兩類:
client(客戶端型)
server(服務(wù)端型)
當(dāng)一端XSS代碼是在服務(wù)端被插入的,那么這就是服務(wù)端型XSS,同理,如果代碼在客戶端插入,就是客戶端型XSS。
2.4 防止XSS攻擊--轉(zhuǎn)義無論是服務(wù)端型還是客戶端型XSS,攻擊達(dá)成需要兩個(gè)條件:
代碼被注入
代碼被執(zhí)行
其實(shí)只要做好無論任何情況下保證代碼不被執(zhí)行就能完全杜絕XSS攻擊。詳情可以看下XSS (Cross Site Scripting) Prevention Cheat Sheet這篇文章。
這里簡(jiǎn)單說下結(jié)論:任何時(shí)候都不要把不受信任的數(shù)據(jù)直接插入到dom中的任何位置,一定要做轉(zhuǎn)義。
2.4.1 對(duì)于某些位置,不受信任的數(shù)據(jù)做轉(zhuǎn)義就可以保證安全:
div body的內(nèi)部html
一般的標(biāo)簽屬性值
2.4.2 對(duì)于某些位置,即使做了轉(zhuǎn)義依然不安全:
2.6 使用瀏覽器自帶的 XSS-filter現(xiàn)代瀏覽器都對(duì)反射型XSS有一定的防御力,其原理是檢查url和dom中元素的相關(guān)性。但這并不能完全防止反射型XSS。另外,瀏覽器對(duì)于存儲(chǔ)型XSS并沒有抵抗力,原因很簡(jiǎn)單,用戶的需求是多種多樣的。所以,抵御XSS這件事情不能指望瀏覽器。
可以通過http頭控制是否打開XSS-filter,當(dāng)然默認(rèn)是打開的.X-XSS-Protection
2.7 CSP(Content Security Policy)從原理上說防止XSS是很簡(jiǎn)單的一件事,但實(shí)際中,業(yè)務(wù)代碼非常多樣和復(fù)雜,漏洞還是時(shí)不時(shí)會(huì)出現(xiàn)。CSP并不是用來防止XSS攻擊的,而是最小化XSS發(fā)生后所造成的傷害。事實(shí)上,除了開發(fā)者自己做好XSS轉(zhuǎn)義,并沒有別的方法可以防止XSS的發(fā)生。CSP可以說是html5給Web安全帶來的最實(shí)惠的東西。CSP的作用是限制一個(gè)頁(yè)面的行為不論是否是javacript控制的。
如何引入CSP呢?
2.7.1 通過response頭
//只允許腳本從本源加載Content-Security-Policy: script-src "self"
2.7.2 通過html的meta標(biāo)簽
//作用同上
那么CSP除了限制script-src之外還能限制什么呢?
base-uri: 限制這篇文檔的uri;
child-src: 限制子窗口的源(iframe、彈窗等),取代frame-src;
connect-src: 限制腳本可以訪問的源;
font-src: 限制字體的源;
form-action: 限制表單能夠提交到的源;
frame-ancestors: 限制了當(dāng)前頁(yè)面可以被哪些頁(yè)面以iframe,frame,object等方式加載;
frame-src: deprecated with child-src,限制了當(dāng)前頁(yè)面可以加載哪些源,與frame-ancestors對(duì)應(yīng);
img-src: 限制圖片可以從哪些源加載;
media-src: 限制video,audio, source,track能夠從哪些源加載;
object-src: 限制插件可以從哪些源加載;
sandbox: 強(qiáng)制打開沙盒模式;
可以看出,CSP是一個(gè)強(qiáng)大的策略,幾乎可以限制了所有能夠用到的資源的來源。使用好CSP可以很大成都降低XSS帶來的風(fēng)險(xiǎn)。另外,CSP還提供一個(gè)報(bào)告的頭Content-Security-Policy-Report-Only,使用這個(gè)頭瀏覽器向服務(wù)器報(bào)告CSP狀態(tài),細(xì)節(jié)先不討論。
Content-Security-Policy-Report-Only:script-src"self"; report-uri/csp-report-endpoint/
CSP 目前有兩版:CSP1和CSP2。
兩版的支持狀態(tài)可以在http://caniuse.com/#search=csp中查到。
CSP1:
CSP2:
2.8 X-Frame-Options這是response頭,現(xiàn)在正在使用,但以后可以被CSP的frame-ancestors取代。目前支持的狀態(tài)比起CSP frame-ancestors要好,使用的方式:
X-Frame-Options:DENY//這個(gè)頁(yè)面不允許被以frame的方式加載
X-Frame-Options:SAMEORIGIN//這個(gè)頁(yè)面只允許同源頁(yè)面加載
X-Frame-Options:
使用Http-only保護(hù)cookie,可以保證即使發(fā)生了XSS,用戶的cookie也是安全的。使用Http-only保護(hù)的cookie是不會(huì)被javascript讀寫的。
2.10 iframe沙箱環(huán)境雖然有同源策略,iframe的問題還是有很多的,比如各種利用iframe進(jìn)行跨源。HTML5為iframe提供了安全屬性sandbox,如果使用此屬性,iframe的能力將會(huì)被限制,細(xì)節(jié)我們將會(huì)在以后的文章中詳細(xì)討論。
2.11 其他安全相關(guān)的HTTP頭X-Content-Type-Options阻止瀏覽器進(jìn)行content-type 嗅探。告訴瀏覽器相信此服務(wù)器下發(fā)的資源的類型,防止類型嗅探攻擊。
HPKP(Public Key Pinning)Public Key Pinning是一個(gè)response頭,用來檢測(cè)一個(gè)證書的公鑰是否發(fā)生了改變,防止中間人攻擊。
HSTS (HTTP Strict-Transport-Security) 強(qiáng)制使用TSL作為數(shù)據(jù)通道,在扒一扒HTTPS網(wǎng)站的內(nèi)幕中也有詳細(xì)介紹。
說了這么多我們看以下一些各個(gè)網(wǎng)站實(shí)現(xiàn)的情況:
谷歌是行業(yè)的標(biāo)桿,在互聯(lián)網(wǎng)無出其右,學(xué)習(xí)Google就對(duì)了!
我們野狗的官網(wǎng)https://www.wilddog.com/同樣也實(shí)現(xiàn)了幾個(gè)重要的http頭。
百度做的就比較差了,一家如此大規(guī)模的互聯(lián)網(wǎng)公司,對(duì)于安全,對(duì)于技術(shù)如此不敏感,只能說是很悲哀,充分說明中國(guó)互聯(lián)網(wǎng)企業(yè)對(duì)安全的重視是非常低的!值得注意的是,百度的http到https的跳轉(zhuǎn)居然是服務(wù)端做的。
我們?cè)賮砜聪滦袠I(yè)笑話12306。
3. HTML5 對(duì) Web 安全的影響HTML5帶來了很多新的特性,讓瀏覽器和javascript獲得了更大的能力。然而能力越大,被攻破后的危險(xiǎn)就越大。
HTML5對(duì)XSS的影響主要體現(xiàn)在:
更大的攻擊面,HTML5帶來來更多的標(biāo)簽和更多的屬性,XSS發(fā)生的可能性更大。
更大的危害,HTML5更多的資源可以被XSS利用。黑客可以利用瀏覽器的一切權(quán)限,比如本地存儲(chǔ),GEO,WebSocket,Webworker。
遺憾的是HTML并沒有針止XSS和XSRF帶來系統(tǒng)性解決方案。在這個(gè)前提下,CSP變得非常重要,可以大大降低XSS后的危害。
HTML5時(shí)代實(shí)際對(duì)開發(fā)者提出來更高的要求,因?yàn)橛懈嗟慕换?,更多的前端行為,HTML5有更多的API。希望共勉,不做蒙古大夫,與廣大的開發(fā)者一同提高中國(guó)互聯(lián)網(wǎng)的用戶體驗(yàn)!
4. references安全相關(guān)的HTTP頭 https://www.owasp.org/index.php/List_of_useful_HTTP_headers
同源策略 https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
CSP http://www.w3.org/TR/CSP/
HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
w3c iframe element http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html
MDN web security https://developer.mozilla.org/en-US/docs/Web/Security
XSS cheet sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
野狗科技官網(wǎng) https://www.wilddog.com/
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/49645.html
摘要:不會(huì)產(chǎn)生動(dòng)作意味著和的請(qǐng)求不會(huì)在服務(wù)器上產(chǎn)生任何結(jié)果。對(duì)長(zhǎng)度的限制是字節(jié)。起限制作用的是服務(wù)器的處理程序的處理能力。很可能受到中文名稱跨站請(qǐng)求偽造攻擊。而數(shù)據(jù)大小,則是因?yàn)闉g覽器的限制造成的。請(qǐng)開始你的表演參考文章的人都理解錯(cuò)了中與的區(qū)別 本篇文章分兩部分,第一部分可以列為初為新人的裝逼失敗模式,第二部分列為修煉低調(diào)模式。裝逼失敗模式:99%的人對(duì)GET和POST的認(rèn)識(shí)修煉低調(diào)模式:1...
摘要:不會(huì)產(chǎn)生動(dòng)作意味著和的請(qǐng)求不會(huì)在服務(wù)器上產(chǎn)生任何結(jié)果。對(duì)長(zhǎng)度的限制是字節(jié)。起限制作用的是服務(wù)器的處理程序的處理能力。很可能受到中文名稱跨站請(qǐng)求偽造攻擊。而數(shù)據(jù)大小,則是因?yàn)闉g覽器的限制造成的。請(qǐng)開始你的表演參考文章的人都理解錯(cuò)了中與的區(qū)別 本篇文章分兩部分,第一部分可以列為初為新人的裝逼失敗模式,第二部分列為修煉低調(diào)模式。裝逼失敗模式:99%的人對(duì)GET和POST的認(rèn)識(shí)修煉低調(diào)模式:1...
摘要:不會(huì)產(chǎn)生動(dòng)作意味著和的請(qǐng)求不會(huì)在服務(wù)器上產(chǎn)生任何結(jié)果。對(duì)長(zhǎng)度的限制是字節(jié)。起限制作用的是服務(wù)器的處理程序的處理能力。很可能受到中文名稱跨站請(qǐng)求偽造攻擊。而數(shù)據(jù)大小,則是因?yàn)闉g覽器的限制造成的。請(qǐng)開始你的表演參考文章的人都理解錯(cuò)了中與的區(qū)別 本篇文章分兩部分,第一部分可以列為初為新人的裝逼失敗模式,第二部分列為修煉低調(diào)模式。裝逼失敗模式:99%的人對(duì)GET和POST的認(rèn)識(shí)修煉低調(diào)模式:1...
摘要:程序在訪問資源時(shí),出現(xiàn)報(bào)錯(cuò)這本質(zhì)上,是在訪問資源時(shí)的證書信任問題。因此,如果用訪問資源,發(fā)現(xiàn)證書不可信任,則會(huì)報(bào)文章開頭說到的錯(cuò)誤。 java程序在訪問https資源時(shí),出現(xiàn)報(bào)錯(cuò)sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunC...
摘要:安全不是簡(jiǎn)簡(jiǎn)單單地在你家門口貼上不許入內(nèi)的告示是處于全面的系統(tǒng)安全考慮,所以才會(huì)出現(xiàn)上圖所看到的提示,解決的辦法可以考慮下面幾點(diǎn)確保站點(diǎn)的外鏈腳本或文件都是使用而不是,這包括一些腳本鏈接或者是的背景圖片等。 之前寫過一篇博客介紹如何使用StartSSL在Ubuntu上開啟SSL,但是在最開始的時(shí)候,當(dāng)我訪問自己的博客時(shí), showImg(https://segmentfault.co...
閱讀 3442·2021-11-19 09:40
閱讀 1342·2021-10-11 11:07
閱讀 4871·2021-09-22 15:07
閱讀 2904·2021-09-02 15:15
閱讀 1975·2019-08-30 15:55
閱讀 548·2019-08-30 15:43
閱讀 894·2019-08-30 11:13
閱讀 1462·2019-08-29 15:36