同源策略

所謂同源是指姑裂，域名馋袜，協(xié)議，端口相同舶斧。

同源策略(same origin policy)是一種約定欣鳖，它是瀏覽器最核心也是最基本的安全功能，如果缺少了同源策略茴厉，則瀏覽器的正常功能可能受到影響泽台∈踩伲可以說Web是構(gòu)建在同源策略的基礎(chǔ)之上的，瀏覽器只是針對(duì)同源策略的一種實(shí)現(xiàn)怀酷。

瀏覽器的同源策略稻爬，限制了來自不同源的"document"或腳本，對(duì)當(dāng)前“document”讀取或設(shè)置某些屬性蜕依。

跨站腳本攻擊(XSS)

一桅锄、XSS簡(jiǎn)介

跨站腳本攻擊，英文全稱是Cross Site Script样眠，本來縮寫是CSS友瘤，但是為了和層疊樣式表(Cascading Style Sheet，CSS)有所區(qū)別檐束，所以在安全領(lǐng)域叫“XSS”辫秧。

XSS攻擊，通常指黑客通過“HTML注入”篡改了網(wǎng)頁厢塘，插入惡意的腳本茶没，從而在用戶瀏覽網(wǎng)頁時(shí)，控制用戶瀏覽器的一種攻擊晚碾。在一開始，這種攻擊的演示案例是跨域的喂急，所以叫“跨站腳本”格嘁，但是發(fā)展至今，由于JavaScript的強(qiáng)大功能以及網(wǎng)站前端應(yīng)用的復(fù)雜化廊移，是否跨域已經(jīng)不重要了糕簿。

二、XSS的類型：

1. 反射型XSS

反射性XSS只是簡(jiǎn)單地把用戶輸入的數(shù)據(jù)“反射”給瀏覽器狡孔。也就是說懂诗，黑客往往要誘使用戶“點(diǎn)擊”一個(gè)惡意鏈接，才能攻擊成功苗膝。反射型XSS也叫做“非持久型XSS”

2.存儲(chǔ)型XSS

存儲(chǔ)型XSS會(huì)把用戶輸入的數(shù)據(jù)“存儲(chǔ)”在服務(wù)端殃恒。這種XSS具有很強(qiáng)的穩(wěn)定性。黑客把惡意的腳本保存到服務(wù)器辱揭，所以這種XSS攻擊也叫做“存儲(chǔ)型XSS”离唐。存儲(chǔ)型XSS通常也叫做“持久型XSS”，因?yàn)閺男Ч蟻碚f问窃，它存在的時(shí)間是比較長(zhǎng)的亥鬓。

比較常見的一種場(chǎng)景就是，黑客寫下一篇包含有惡意JavaScript代碼的博客文章域庇，博客發(fā)表后嵌戈，所有訪問該博客文章的用戶覆积，都會(huì)在他們的瀏覽器中執(zhí)行這段惡意代碼。

3.Dom Base XSS

通過修改頁面的DOM節(jié)點(diǎn)形成的XSS熟呛，稱之為Dom Based XSS技健。

Dom Based XSS從效果上來說也是反射型XSS，單獨(dú)劃分出來惰拱，是因?yàn)镈om Based XSS的形成原因比較特別雌贱，所以把它單獨(dú)作為一個(gè)分類。

三偿短、XSS Payload

XSS攻擊成功后欣孤，攻擊者能夠?qū)τ脩舢?dāng)前瀏覽的頁面植入惡意腳本，通過惡意腳本昔逗，控制用戶的瀏覽器——這些用以完成各種具體功能的惡意腳本降传，被稱為“XSS Payload”。

XSS Payload實(shí)際上是JavaScript腳本(還可以是Flash或者其他客戶端的腳本)勾怒，所以任何JavaScript腳本能實(shí)現(xiàn)的功能婆排，XSS PayLoad都能做到。

一個(gè)最常見的XSS PayLoad笔链，就是通過讀取瀏覽器的Cookie對(duì)象段只，從而發(fā)起“cookie劫持”攻擊。

Cookie中一般加密保存了當(dāng)前用戶的登陸憑證鉴扫。Cookie如果丟失赞枕，往往意味著用戶的登陸憑證丟失，換句話說坪创，攻擊者可以不通過密碼炕婶，而直接登陸用戶的賬戶。

跨站點(diǎn)請(qǐng)求偽造(CSRF)

一莱预、CSRF簡(jiǎn)介

跨站請(qǐng)求偽造(Cross Site Request Forgery)柠掂，也被稱為one-click attack或者session riding，通骋谰冢縮寫為CSRF或者XSRF涯贞， 是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

CSRF跟XSS相比悉抵，XSS利用的是用戶對(duì)指定網(wǎng)站的信任肩狂，CSRF 利用的是網(wǎng)站對(duì)用戶網(wǎng)頁瀏覽器的信任。

二姥饰、CSRF的防御

1.驗(yàn)證碼

驗(yàn)證碼被認(rèn)為是對(duì)抗CSRF攻擊最簡(jiǎn)潔而有效的防御方法傻谁。

CSRF攻擊的過程，往往是在用戶不知情的情況下構(gòu)造了網(wǎng)絡(luò)請(qǐng)求列粪。而驗(yàn)證碼审磁，則強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互谈飒，才能完成最終請(qǐng)求。因此态蒂，通常情況下驗(yàn)證碼能夠很好地遏制CSRF攻擊杭措。

2.Referer Check

Referer Check在互聯(lián)網(wǎng)中最常見的應(yīng)用就是“防止圖片盜鏈”。同理钾恢，Referer Check也可以用于檢查請(qǐng)求是夠來自合法的“源”手素。

常見的互聯(lián)網(wǎng)應(yīng)用，頁面與頁面之間都具有一定的邏輯關(guān)系瘩蚪，這就使得每個(gè)正常請(qǐng)求的Referer具有一定的規(guī)律泉懦。

比如一個(gè)“論壇發(fā)帖”的操作，在正常情況下需要先登錄到用戶后臺(tái)疹瘦，或者訪問有發(fā)帖功能的頁面崩哩。在提交“發(fā)帖”的表單時(shí)，Referer的值必然是發(fā)帖表單所在的頁面言沐。如果Referer值不是這個(gè)頁面邓嘹，甚至不是發(fā)帖網(wǎng)站的域，則極有可能是CSRF攻擊险胰。

Referer Check的缺陷在于汹押，服務(wù)器并非什么時(shí)候能都取到Referer。很多用戶處于保護(hù)隱私的考慮鸯乃，限制了Referer的發(fā)送鲸阻。在某些情況下，瀏覽器也不會(huì)發(fā)送Referer缨睡，比如從HTTPS跳轉(zhuǎn)到HTTP，出于安全考慮陈辱，瀏覽器也不會(huì)發(fā)送Referer奖年。

出于以上種種原因，我們還是無法依賴于Referer Check作為防御CSRF攻擊的主要手段沛贪。但是陋守，通過Referer Check來監(jiān)控CSRF攻擊的發(fā)生，倒是一種可行的方法利赋。

3.Anti CSRF Token

• CSRF的本質(zhì)

  CSRF為什么能夠攻擊成功水评？其本質(zhì)原因是重要操作的所有參數(shù)都是可以被攻擊者猜測(cè)到的。

  攻擊者只有預(yù)測(cè)出URL的所有參數(shù)與參數(shù)值媚送，才能成功地構(gòu)造一個(gè)偽造的請(qǐng)求中燥；反之，攻擊者將無法攻擊成功塘偎。出于這個(gè)原因疗涉，可以想到一個(gè)解決方法：把參數(shù)加密拿霉，或使用一些隨機(jī)數(shù)，從而讓攻擊者無法猜測(cè)到參數(shù)值咱扣。

  但是這個(gè)方法也存在一些問題绽淘。首先，加密或者混淆后的URL將變得非常難度闹伪，對(duì)用戶非常不友好沪铭。其次，如果加密的參數(shù)每次都要改變偏瓤，某些URL將無法被用戶收藏杀怠。最后，普通的參數(shù)硼补，如果也被加密或哈希驮肉，將會(huì)給數(shù)據(jù)分析工作帶來很大的困擾。(因?yàn)閿?shù)據(jù)分析工作常常需要用到參數(shù)的明文)

  因此已骇，我們需要一個(gè)通用的方法來解決這個(gè)問題离钝，那就是Anti CSRF Token。這個(gè)token的值是隨機(jī)的褪储，不可預(yù)測(cè)的卵渴。

  Token需要足夠隨機(jī)，必須使用足夠安全的隨機(jī)數(shù)生成算法鲤竹，或者采用真隨機(jī)數(shù)生成器浪读。另外，Token應(yīng)該是一個(gè)秘密辛藻，為用戶與服務(wù)器所共同持有碘橘，不能被第三者知曉。在實(shí)際應(yīng)用中吱肌，Token可以放在用戶的Session中痘拆，或者瀏覽器的Cookie中。

  Token需要同時(shí)放在表單和Session中氮墨，在提交請(qǐng)求時(shí)纺蛆，服務(wù)器只需庁表單中的Token與Session(或CooKie)中的Token是否一致，如果一致规揪，則認(rèn)為是合法請(qǐng)求桥氏，如果不一致，或者有一個(gè)是空猛铅，則認(rèn)為請(qǐng)求不合法字支，可能發(fā)生了CSRF攻擊。

• Token的使用原則

  • 防御CSRF的Token，是根據(jù)“不可預(yù)測(cè)性原則”設(shè)計(jì)的方案祥款，所以Token的生成一定要足夠隨機(jī)清笨，需要使用安全的隨機(jī)數(shù)生成器來生成Token。

  • 這個(gè)Token的目的不是為了防止重復(fù)提交刃跛，所以為了使用方便抠艾，可以允許在一個(gè)用戶的有效聲明周期內(nèi)，在Token消耗掉前都使用同一個(gè)Token桨昙。但是如果用戶已經(jīng)提交了表單检号，則這個(gè)Token已經(jīng)消耗掉，應(yīng)該再次重新生成一個(gè)新的Token蛙酪。

  • 如果Token保存在Cookie中齐苛，而不是服務(wù)器端的Session中，則會(huì)帶來一個(gè)新的問題桂塞。如果一個(gè)用戶打開幾個(gè)相同的頁面同時(shí)操作凹蜂，當(dāng)某個(gè)頁面消耗掉Token后，其它頁面的表單內(nèi)保存的還是被消耗掉的那個(gè)Token阁危，因此其它頁面的表單再次提交時(shí)玛痊，會(huì)出現(xiàn)Token錯(cuò)誤。在這種情況下狂打，可以考慮生成多個(gè)有效的Token擂煞，以解決多頁面共存的場(chǎng)景。

  • 最后趴乡，使用Token時(shí)應(yīng)該注意Token的保密性对省。Token如果出現(xiàn)在某個(gè)頁面的URL中，則可能會(huì)通過Referer的方式泄露晾捏。因此在使用Token時(shí)蒿涎，應(yīng)該盡量把Token放在表單中，把敏感操作由GET改為POST惦辛，以form表單或者AJAX的形式提交同仆，可以避免Token泄露。

CSRF的Token僅僅用于對(duì)抗CSRF攻擊裙品，當(dāng)網(wǎng)站還同時(shí)存在XSS漏洞時(shí)，這個(gè)方案就會(huì)變得無效俗或，因?yàn)閄SS可以模擬客戶端瀏覽器執(zhí)行任意操作市怎。在XSS攻擊下，攻擊者完全可以請(qǐng)求頁面后辛慰，讀出該內(nèi)容里的Token值区匠，然后再構(gòu)造出一個(gè)合法的請(qǐng)求。這個(gè)過程可以稱之為XSRF，和CSRF以示區(qū)分驰弄。

三麻汰、小結(jié)

• CSRF攻擊是攻擊者利用用戶的身份操作用戶賬戶的一種攻擊方式。設(shè)計(jì)CSRF的防御方案必須先理解CSRF攻擊的原理和本質(zhì)戚篙。

• 根據(jù)“不可預(yù)測(cè)性原則”五鲫，我們通常使用Anti CSRF Token來防御CSRF攻擊。在使用Token時(shí)岔擂，要注意Token的保密性和隨機(jī)性位喂。

點(diǎn)擊劫持(ClickJacking)

1.什么是點(diǎn)擊劫持

點(diǎn)擊劫持是一種視覺上的欺騙手段，它與CSRF有異曲同工之妙乱灵，都是在用戶不之情的情況下誘使用戶完成一些動(dòng)作塑崖。但是在CSRF攻擊的過程中，如果出現(xiàn)用戶交互的頁面痛倚，則攻擊可能無法順利完成规婆，而點(diǎn)擊劫持利用的就是與用戶產(chǎn)生交互的頁面。

2.點(diǎn)擊劫持多種多樣

• Flash點(diǎn)擊劫持

• 圖片覆蓋攻擊

• 拖拽劫持與數(shù)據(jù)竊取

• 觸屏劫持

3.防御點(diǎn)擊劫持

ClickJacking是一種視覺上的欺騙蝉稳，針對(duì)傳統(tǒng)的ClickJacking抒蚜，一般是通過禁止跨域的iframe來防范。

• frame busting

  通车咔可以寫一段JavaScript代碼削锰，以禁止iframe的嵌套，這種方法叫做frame busting毕莱。比如下面這段代碼：

javascript if(top.location != location){ top.location = self.location; }

• X-Frame-Options

  因?yàn)閒rame busting存在被繞過的可能器贩，所以我們需要尋找其他更好的解決方案。一個(gè)比較好的方案是使用一個(gè)HTTP頭-X-Frame-Options朋截。

  X-Frame-Options可以說是為了解決ClickJacking而生的蛹稍。它有三個(gè)可選的值。

  • DENY——拒絕當(dāng)前頁面加載任何frame頁面部服；

  • SAMEORIGIN——frame頁面的地址只能為同源域名下的頁面唆姐；

• ALLOW-FROM origin——可以定義允許frame加載的頁面地址。

4.小結(jié)

ClickJacking相對(duì)于XSS與CSRF來說廓八，因?yàn)樾枰T使用戶與頁面產(chǎn)生交互行為奉芦，因此實(shí)施攻擊的成本更高，在網(wǎng)絡(luò)犯罪中比較少見剧蹂。但ClickJacking在未來仍有可能被攻擊者利用声功，不可不察。

HTML5安全

HTML5中新增的一些標(biāo)簽和屬性宠叼，使得XSS等Web攻擊產(chǎn)生了新的變化先巴。

1.iframe的sandbox

在HTML5中，專門為iframe定義了一個(gè)新的屬性，叫sandbox伸蚯。使用sandbox這一屬性后摩渺，<iframe>標(biāo)簽加載的內(nèi)容被視為一個(gè)獨(dú)立的”源“，其中的腳本將被禁止執(zhí)行剂邮，表單被禁止提交摇幻，插件被禁止加載，指向其他瀏覽器對(duì)象的鏈接也會(huì)被禁止抗斤。

sandbox屬性可以通過參數(shù)來支持更精確的控制囚企，有一下幾個(gè)值可以選擇：

• allow-same-origin：允許同源訪問

• allow-top-navigation：允許訪問頂層窗口

• allow-forms：允許提交表單

• allow-script：允許執(zhí)行腳本（有的行為，即使是設(shè)置了allow-script也是不允許的瑞眼，比如“彈出窗扣”）

iframe的sandbox屬性將極大地增強(qiáng)應(yīng)用使用iframe的安全性

2.Link Types：noreferrer

標(biāo)簽指定noreferrer后龙宏，瀏覽器在請(qǐng)求該標(biāo)簽執(zhí)行的地址時(shí)將不再發(fā)送Referer，這種設(shè)計(jì)是出于保護(hù)用戶敏感信息和隱私的考慮伤疙。避免通過Refer泄露一些敏感信息银酗。（這個(gè)標(biāo)簽需要開發(fā)者手動(dòng)添加在頁面的標(biāo)簽中）

HTTP Referer是header的一部分，當(dāng)瀏覽器向Web服務(wù)器發(fā)送請(qǐng)求的時(shí)候徒像，一般會(huì)帶上Referer黍特，告訴服務(wù)器我是從哪個(gè)頁面鏈接過來的，服務(wù)器基此可以獲得一些信息用于處理锯蛀。

3.Canvas的妙用

其它安全問題

1.Cross-Origin Resource Sharing

Origin Header用于標(biāo)記HTTP發(fā)起的“源”灭衷，服務(wù)器通過識(shí)別瀏覽器自動(dòng)帶上這個(gè)Origin Header，來判斷瀏覽器的請(qǐng)求是否來自一個(gè)合法的“源”旁涤。Origin Header可以用于防范CSRF翔曲，它不像Referer那么容易被偽造或者清空。

2.postMessage——跨窗口傳遞消息

postMessage允許每一個(gè)window(包括當(dāng)前窗口劈愚、彈出窗口瞳遍、iframes等)對(duì)象往其他的窗口發(fā)送文本信息，從未實(shí)現(xiàn)跨窗口的消息傳遞菌羽。并且乖坠，這個(gè)功能是不受同源策略限制的暂论。

發(fā)送窗口負(fù)責(zé)發(fā)送事件，而接收窗口需要綁定一個(gè)“message”事件邓了，監(jiān)聽其他窗口發(fā)來的消息雌隅。如果沒有監(jiān)聽這個(gè)事件钧大，則無法接收到消息庞呕。

在使用postMessage()時(shí)家凯，有兩個(gè)安全問題需要注意：

• 必要時(shí)，可以在接收窗口驗(yàn)證Domain署鸡，甚至驗(yàn)證URL，以防止來自非法頁面的消息。這實(shí)際上是在代碼中實(shí)現(xiàn)一次同源策略的驗(yàn)證過程靴庆。

• 根據(jù)“Secure By Default”原則时捌， 在接收窗口不應(yīng)該信任任何接收到的消息，而需要對(duì)消息進(jìn)行安全檢查炉抒。

3.Web Storage

Web Storage讓W(xué)eb開發(fā)更加的靈活多變奢讨，它的強(qiáng)大功能也為XSS Payload打開方便之門，攻擊者有可能將惡意代碼保存在Web Storage中焰薄，從而實(shí)現(xiàn)跨頁面攻擊拿诸。