寫在前面
- 書籍介紹:Web前端的黑客攻防技術是一門非常新穎且有趣的黑客技術,主要包含Web前端安全的跨站腳本(XSS)、跨站請求偽造(CSRF)、界面操作劫持這三個大類,涉及的知識點涵蓋信任與信任關系、Cookie安全、Flash安全、DOM渲染、字符集、跨域、原生態攻擊、高級釣魚、蠕蟲思想等,這些都是研究前端安全的人必備的知識點,本書作者深入剖析了許多經典的攻防技巧,并給出了許多獨到的安全見解,
- 我的簡評:這本書出版好幾年了(13年出版的),上面寫的很多HTML漏洞、CSS漏洞、JavaScript漏洞以及瀏覽器漏洞現在已經都被修復了,但Web前端安全這個主題對于我們開發人員來說,還是非常重要的一塊知識點,特別是對于大型公司專案的開發人員,而且對于Web前端黑客技術的了解,體現出一個技術人員的技術層次及對于技術的熱衷和鉆研程度,所以還是很推薦朋友們閱讀此書,
- !!福利:文末有pdf書籍、筆記思維導圖、隨書代碼打包下載地址哦!想看看[書籍精讀]系列所有文章,請移步:[推薦收藏]JavaScript書籍精讀筆記系列導航
第一章 Web安全的關鍵點
1.1.資料與指令
- 用瀏覽器打開一個網站,呈現在我們面前的都是資料,有服務端存盤的(如:資料庫、記憶體、檔案系統等)、客戶端存盤的(如:本地Cookies、Flash Cookies等)、傳輸中的(如:JSON資料、XML資料等),還有文本資料(如:HTML、JavaScript、CSS等)、多媒體資料(如:Flash、Mp3等)、圖片資料等,
- 兩個例子的攻擊場景:1.SQL注入攻擊的發生;2.XSS跨站腳本攻擊的發生
- 跨站攻擊發生在瀏覽器客戶端,而SQL注入攻擊由于針對的物件是資料庫,一般情況下,資料庫都在服務端,所以SQL注入是發生在服務端的攻擊
1.2.瀏覽器的同源策略
- 計算機的本地與Web是不同的層面,Web世界(通常稱為Internet域)運行在瀏覽器上,而被限制了直接進行本地資料(通常稱為本地域)的讀寫
- 同源策略規定:不同域的客戶端腳本在沒明確授權的情況下,不能讀寫對方的資源,其中有幾個關鍵詞:不同域、客戶端腳本、授權、讀寫、資源
- 1.不同域或同域:同域要求兩個站點同協議、同域名、同埠
- 2.客戶端腳本:主要指JavaScript(各個瀏覽器原生態支持的腳本語言)、ActionScript(Flash的腳本語言),以及JavaScript與ActionScript都遵循的ECMAScript腳本標準
- 3.授權:HTML5新標準中提到關于Ajax跨域訪問的情況,默認情況下是不允許跨域訪問的,只有目標站點明確回傳HTTP回應頭
- 4.讀寫權限:Web上的資源有很多,有的只有讀權限,有的同時擁有讀和寫的權限,比如:HTTP請求頭里的Referer(表示請求來源)只可讀,而document.cookie則具備讀寫權限
- 5.同源策略里的資源是指Web客戶端的資源,一般來說,資源包括:HTTP訊息頭、整個DOM樹、瀏覽器存盤(如:Cookies、Flash Cookies、localStorage等)
1.3.信任與信任關系
- 安全類似木桶原理,短的那塊板決定了木桶實際能裝多少水,一個Web服務器,如果其上的網站沒做好權限分離,沒控制好信任關系,則整體安全性就由安全性最差的那個網站決定
- 很多網站都嵌入了第三方的訪問統計腳本,嵌入的方式是使用
<script>標簽參考,這時就等于建立了信任關系,如果第三方的統計腳本被黑客掛馬,那么這些網站也都會被危及
1.4.社會工程學的作用
- 常用的社工輔助技巧有:Google Hack、SNS垂直搜索、各種收集的資料庫集合查詢等
1.5.攻防不單一
- CSRF會借用目標用戶的權限做一些借刀殺人的事(注意是“借用”,而不是“盜取”目標權限),然后去做壞事,“盜取”通常是XSS(跨站腳本攻擊)最喜歡做的事
第二章 前端基礎
2.1.W3C的世界法則
- Web安全事件的角色如下:W3C、瀏覽器廠商、Web廠商、攻擊者(或黑客)、被攻擊者(或用戶)
2.2.URL
- URL是互聯網最偉大的創意之一,也就是我們經常提的鏈接,通過URL請求可以查找到唯一的資源
- URL有個重點就是編碼方式,有三類:escape、encodeURI、encodeURIComponent,對應的解碼函式是:unescape、decodeURI、decodeURIComponent
2.3.HTTP協議
- URL的請求協議幾乎都是HTTP,它是一種無狀態的請求回應,即每次的請求回應之后,連接會立即斷開或延時斷開(保持一定的連接有效期),斷開后,下一次請求再重新建立
- User-Agent很重要,用于表明身份(我是誰),從這里可以看到作業系統、瀏覽器、瀏覽器內核及對應的版本號等資訊
- 通過Cookies進行會話跟蹤,第一次回應時設定的Cookies在隨后的每次請求中都會發送出去,Cookies還可以包括登錄認證后的身份資訊
- 針對不同的資源型別會有不同的決議方式,這個會影響瀏覽器對回應體里的資源決議 方式,可能因此帶來安全問題,字符集也會影響瀏覽器的解碼方式,同樣可能帶來安全問題
2.4.松散的HTML世界
- HTML里可以有腳本、樣式等內容的嵌入,以及圖片、多媒體等資源的參考
- HTML是由眾多標簽組成的,標簽內還有對應的各種屬性,這些標簽可以不區分大小寫,有的可以不需要閉合,屬性的值可以用單引號、雙引號、反單引號包圍住,甚至不需要引號,多余的空格與Tab毫不影響HTML的決議,HTML里可以內嵌CSS、JavaScript等內容,而不強調分離,等等
- 很多前端安全問題就是因為松散導致的
- 1.DOM樹:很多資料都存在于DOM樹中,通過DOM樹的操作可以非常容易地獲取到我們的隱私資料;隱私資料可能存盤在以下位置(HTML內容中、瀏覽器本地存盤中,如Cookies、URL地址中)
- 2.iframe內嵌出一個開放的世界:iframe標簽是HTML中一個非常重要的標簽,也是Web安全中出鏡頻率最高的標簽之一,很多網站都通過iframe嵌入第三方內容;iframe標簽帶來了很多便利,同時也帶來了很多風險,比如,攻擊者入侵一個網站后,可以通過iframe嵌入自己的網馬頁面,用戶訪問該網站后,被嵌入的網馬頁面就會執行;如果父頁和子頁之間是同域,那就很容易,父頁可以通過呼叫子頁的contentWindow來操作子頁的DOM樹,同理,子頁可以呼叫父頁的contentWindow來操作父頁的DOM樹,如果它們不同域,則必須遵守同源策略,但子頁還是可以對父頁的location進行寫操作,這樣可以讓父頁重定向到其他頁面,不過對location的操作僅僅只是寫權限,而沒有讀權限,這樣就不能獲取到父頁location URL的內容,否則有可能會造成隱私資料泄露;
- 3.HTML內嵌腳本執行:JavaScript腳本除了出現在JS格式檔案里,被嵌入而執行外,還可以出現在HTML的
<script></script>標簽內、HTML的標簽on事件中,以及一些標簽的href、src等屬性的偽協議(javascript:等)中;
2.5.跨站之魂-JavaScript
- 有了XSS漏洞,就意味著可以注入任意的JavaScript,有了JavaScript,就意味著被攻擊者的任何操作都可以模擬,任何隱私資訊都可以獲取到
- DOM樹操作:1.獲取HTML內容中的隱私資料;2.獲取瀏覽器的Cookies資料(Cookies中保存了用戶的會話資訊,通過document.cookie可以獲取到,不過并不是所有的Cookies都可以獲取);3.獲取URL地址中的資料
- AJAX風險:Ajax簡直就是前端黑客攻擊中必用的技術模式;利用Ajax的攻擊顯得很詭異,無聲無息;不是任何請求頭都可以通過JavaScript進行設定的,W3C給出了一份頭部黑名單;如果目標域不設定Access-Control-Allow-Origin,雖然瀏覽器會報權限錯誤的問題,但實際上隱私數已經被目標域的代碼接收到了;默認情況下,這樣的跨域無法帶上目標域的會話(Cookies等),需要設定xhr實體的withCredentials屬性為true(IE還不支持);如果設定了Access-Control-Allow-Credentials為true,那么Access-Control-Allow-Origin就不能設定為*通配符,這也是瀏覽器為了安全進行的考慮;
- 模擬用戶發起瀏覽器請求:XMLHttpRequest物件就是一個非常方便的方式,可以模擬表單提交,它有異步與同步之分,差別在于XMLHttpRequest實體化的物件xhr的open方法的第三個引數,true表示異步,false表示同步,如果使用異步方式,就是Ajax;前端黑客攻擊中,比如XSS經常需要發起各種請求(如盜取Cookies、蠕蟲攻擊等),上面的幾種方式都是XSS攻擊常用的,而最后一個表單自提交方式經常用于CSRF攻擊中;
- Cookie安全:Cookie是一個神奇的機制,同域內瀏覽器中發出的任何一個請求都會帶上Cookie,無論請求什么資源,請求時,Cookie出現在請求頭的Cookie欄位中,服務端回應頭的Set-Cookie欄位可以添加、修改和洗掉Cookie,大多數情況下,客戶端通過JavaScript也可以添加、修改和洗掉Cookie;Cookie經常被用來存盤用戶的會話資訊,用戶登錄認證后的Session,之后同域內發出的請求都會帶上認證后的會話資訊,非常方便,攻擊者就特別喜歡盜取Cookie,這相當于盜取了在目標網站上的用戶權限;
- 本地存盤風險:本地存盤的主要風險是被植入廣告跟蹤標志,有的想刪都不一定能洗掉干凈;廣為人知的evercookie,還使用了以下存盤(Silverlight的IsolatedStorage、PNG Cache、類似PNG Cache機制的還有HTTP Etags、Web Cache、Web History、window.name);
- e4x帶來的混亂世界:對于JavaScript來說,當前只有Firefox支持E4X,這種技術是將XML作為JavaScript的物件;通過使用E4X技術,可以混淆JavaScript代碼,甚至繞開一些過濾規則;
- JavaScript函式劫持:JavaScript函式劫持很簡單,一般情況下,只要在目標函式觸發之前,重寫這個函式即可;曾經的瀏覽器劫持document.write、document.writeln也同樣是這樣的方式;
2.6.一個偽裝出來的世界-CSS
- CSS即層疊樣式表,用于控制網頁的呈現樣式,如顏色、字體、大小、高寬、透明、偏移、布局等,通過靈活運用CSS技巧,攻擊者可以偽裝出期望的網頁效果,從而進行釣魚攻擊
- CSS容錯性
- 樣式偽裝:偽裝出來的UI效果讓人感覺就是真的
- CSS偽類:曾經出現比較久的CSS History攻擊利用的就是:visited偽類技巧進行的,原理很簡單,就是準備一批常用的鏈接,加上:visited{ background:url(xxxxx) }樣式;如果其中的某鏈接之前訪問過(也就是存在于記錄中的),那么:visited就會觸發,隨后會發送一個唯一的請求到目標地址,這樣就可以知道被攻擊者的歷史記錄是否有這個鏈接,不過這個方式已經被瀏覽器修補了;但還有一些偽類是有效的,比如::selection偽類,當指定物件區域被選擇時,就會觸發::selection,這個在Chrome下有效;
- CSS3的屬性選擇符:CSS還可以內嵌腳本執行
2.7.另一個幽靈-ActionScript
- ActionScript(簡稱AS)和JavaScript一樣遵循ECMAScript標準,ActionScript由Flash的腳本虛擬機執行,運行環境就在Flash Player中,而Flash Player的運行環境主要有兩個:瀏覽器與作業系統本地,Flash有自己的安全沙箱來限制ActionScript的能力,否則通過ActionScript可以進行很多危險的操作
- flash安全沙箱:Flash安全沙箱是用來制定ActionScript的游戲規則的;安全沙箱包括遠程沙箱與本地沙箱,其實這個沙箱模型類似于瀏覽器中的同源策略,在同一域內的資源會被放到一個安全組下,這個安全組被稱為安全沙箱;
- html嵌入flash的安全相關配置
- 跨站flash:跨站Flash也稱Cross Site Flash(XSF),即通過ActionScript來加載第三方Flash檔案,攻擊者如果對這個程序可控,那么他們就可以讓目標Flash加載惡意的Flash檔案,從而造成XSF攻擊;
- 引數傳遞
- flash里的內嵌html:Flash內嵌HTML不能很隨意,且支持的標簽有限;
- 與JavaScript通信:1.getURL()與navigateToURL();2.ExternalInterface;
- 網路通信:URLLoader與URLRequest組合進行文本資料的請求,這是AS3種絕佳的組合,GET/POST資料都很方便,如果僅是發送資料出去,而不需要得到回應,則直接用sendToURL函式+URLRequest組合;如果要使用socket請求,則可以使用Socket類或XMLSocket類;AMF(Action Message Format)是Flash和服務端通信的一種常見的二進制編碼模式,其傳輸效率高,可以在HTTP層面上傳輸;分析了一些外掛,有專門模擬AMF訊息進行各種惡意操作的;
- 其他安全問題:發現Flash的一些重要資料或邏輯運算直接在本地進行,這是錯誤的,通過一些流行的反編譯工具(比如HP swfdump.exe等)就能得到ActionScript代碼;牢記,重要的資料或運算不要在本地進行;
第三章 前端黑客之XSS
3.1.XSS概述
- XSS即跨站腳本,發生在目標網站中目標用戶的瀏覽器層面上,當用戶瀏覽器渲染整個HTML檔案的程序中出現了不被預期的腳本指令并執行時,XSS就會發生
- 跨站腳本的重點不在“跨站”上,而應該在“腳本”上
- 可以通俗地總結XSS為:想盡一切辦法將你的腳本內容在目標網站中目標用戶的瀏覽器上決議執行
3.2.XSS型別
- XSS有三類:反射型XSS(也叫非持久型XSS)、存盤型XSS(也叫持久型XSS)和DOM XSS
- 反射型XSS:發出請求時,XSS代碼出現在URL中,作為輸入提交到服務端,服務端決議后回應,在回應內容中出現這段XSS代碼,最后瀏覽器決議執行
- 存盤型XSS和反射型XSS的差別僅在于:提交的XSS代碼會存盤在服務端(不管資料庫、記憶體還是檔案系統等),下次請求目標頁面時不再提交XSS代碼
- 最典型的例子是留言板XSS,存盤型XSS的攻擊是最隱蔽的
- DOM XSS和反射型XSS、存盤型XSS的差別在于,DOM XSS的XSS代碼并不需要服務器決議回應的直接參與,觸發XSS靠的就是瀏覽器端的DOM決議,可以認為完全是客戶端的事情
- DOM XSS的處理邏輯就在客戶端
3.3.哪里可以出現XSS攻擊
- XSS涉及的場景可以很廣,現在越來越多的客戶端軟體支持HTML決議和JavaScript決議,比如:HTML檔案、XML檔案、Flash、PDF、QQ、一些音樂播放器、一些瀏覽器的功能界面等
3.4.有何危害
- 掛馬
- 盜取用戶Cookie
- Dos(拒絕服務)客戶端瀏覽器
- 釣魚攻擊,高級釣魚技巧
- 撰寫針對性的XSS病毒,洗掉目標文章、惡意篡改資料、嫁禍于人
- 劫持用戶Web行為,甚至進一步滲透內網
- 爆發Web 2.0蠕蟲
- 蠕蟲式的DDoS攻擊
- 蠕蟲式掛馬攻擊、刷廣告、刷流量、破壞網上資料
第四章 前端黑客之CSRF
寫在前面
- CSRF的全稱是Cross Site Request Forgery,即跨站請求偽造
- CSRF對于那些開源網站、多用戶的網站、社交網站等來說非常值得關注,此時的CSRF可以直接攻擊管理員后臺或者其他用戶
4.1.CSRF概述
- 對于CSRF來說,它的請求有兩個關鍵點:跨站點的請求與請求是偽造的
- 可以認為:如果請求的發出不是用戶的意愿,那么這個請求就是偽造的
- 洗掉文章的示例:這個攻擊程序有三個關鍵點,跨域發出了一個GET請求、可以無JavaScript參與、請求是身份認證后的
4.2.CSRF型別
- 按照攻擊方式來說,CSRF可分為:HTML CSRF攻擊、JSON HiJacking攻擊和Flash CSRF攻擊等
- HTML中能夠設定src/href等鏈接地址的標簽都可以發起一個GET請求
- 還有通過JavaScript動態生成的標簽物件或CSS物件發起的GET請求,而發出POST請求只能通過form提交方式
- Flash的世界同樣遵循同源策略,發起的CSRF攻擊是通過ActionScript腳本來完成的
- 說到Flash CSRF,通常會想到以下兩點:跨域獲取隱私資料;跨域提交資料操作,一些如添加、洗掉、編輯等操作的請求
4.3.有何危害
- 篡改目標網站上的用戶資料
- 盜取用戶隱私資料
- 作為其他攻擊向量的輔助攻擊手法
- 傳播CSRF蠕蟲
第五章 前端黑客之界面操作劫持
5.1.界面操作劫持概述
- 界面操作劫持攻擊是一種基于視覺欺騙的Web會話劫持攻擊,它通過在網頁的可見輸入控制元件上覆寫一個不可見的框(iframe),使得用戶誤以為在操作可見控制元件,而實際上用戶的操作行為被其不可見的框所劫持,執行不可見框中的惡意劫持代碼,從而完成在用戶不知情的情況下竊取敏感資訊、篡改資料等攻擊
- 從其技術發展階段上分析,可以分為以下三種:點擊劫持、拖放劫持、觸屏劫持
- 點擊劫持:其首先劫持的是用戶的滑鼠點擊操作,它主要的劫持目標是有重要會話互動的頁面
- 拖放劫持:在瀏覽器中,拖放操作是不受“同源策略”限制的,用戶可以把一個域的內容拖放到另一個不同的域
- 觸屏劫持:智能移動設備已經成為黑客們攻擊的新目標
5.2.界面操作劫持技術原理分析
- 透明層+iframe:這里的“覆寫”是指控制元件位置之間的層次關系,“不可見的”是指頁面的透明度為零,而“框”則指的是iframe標簽,所以,“覆寫一個不可見的框”可以理解成“透明層”+ “iframe”
- 通過頁面透明度+iframe實作了對用戶的視覺欺騙,即用戶看到的操作物件與實際操作物件是不一致的,從而為界面操作劫持攻擊提供了技術手段
- dataTransfer作為event物件的一個屬性出現,用于從被拖動的物件傳遞字串到放置物件
- setData操作完成向系統剪貼板中存盤需要傳遞的資料,傳遞資料分為兩種型別:文本資料和URL資料,在HTML5的擴展中,其允許指定任意的MIME型別
- 拖放劫持的操作函式稍微復雜一些,瀏覽器中可以拖放的物件一直在不斷地增加,圖片、鏈接和文本都是可以拖動的
- IPhone Safari瀏覽器有一個特殊的功能,即可以把網頁添加到IOS作業系統的桌面當作一個程式圖示來顯示
- 在這些觸屏移動設備中,同樣可以使用透明度+iframe方法,然后配合觸屏設備中自身的API函式來發起觸屏劫持攻擊
5.3.界面操作劫持實體
- 點擊劫持:微博的關注按鈕示例
- 拖放劫持:小游戲
5.4.有何危害
- 界面操作劫持實際上突破了CSRF的防御策略,它帶來的危害可以很大,比如,洗掉與篡改資料、偷取隱私設定爆發蠕蟲
第六章 漏洞挖掘
寫在前面
- 一個漏洞的產生可能與很多因素有關,比如,瀏覽器差異(或說瀏覽器特性)、瀏覽器BUG、字符集問題、漏洞物件、所在場景等
- CSRF的漏洞挖掘只要確認以下內容即可:目標表單是否有有效的token隨機串;目標表單是否有驗證碼;目標是否判斷了Referer來源;網站根目錄下crossdomain.xml的“allow-access-fromdomain”是否是通配符;目標JSON資料似乎可以自定義callback函式等;
- 界面操作劫持的漏洞挖掘只要確認以下內容即可:目標的HTTP回應頭是否設定好了X-Frame-Options欄位;目標是否有JavaScript的Frame Busting機制;更簡單的就是用iframe嵌入目標網站試試,若成功,則說明漏洞存在;
6.1.普通XSS漏洞自動化挖掘思路
- 自動化的XSS漏洞挖掘其實是很復雜的,難度也會很高,這和我們要實作的XSS漏洞挖掘工具的需求有關,是要效率(有了廣度,卻忽略了深度),還是要檢出率(既有廣度又有深度,漏洞個數多且準確度高)
- 工具自動化的思路,是一種針對反射型XSS、存盤型XSS、頭部XSS、CookieXSS等比較普通的XSS漏洞挖掘思路
- URL上的玄機:URL的一種常見組成模式:
<scheme>://<netloc>/<path>?<query>#<fragment>; - HTML上的玄機:兩類特殊的標簽
<script>和<style>,它們是不能嵌套標簽的,而且payload構造情況會更靈活;同樣有意思的場景,比如這三類:1.輸出在src/href/action等屬性內;2.輸出在on*事件內;3.輸出在style屬性內;對IE來說,在標簽的style屬性中只要能注入expression關鍵詞,并進行適當的閉合,我們就可以認為目標存在XSS; - 請求中的玄機:“探子請求”,在真正的payload攻擊請求之前,總會發起一次無危害(不包含任何特殊符號)的請求,這個請求就像“探子”一樣,來無影去無蹤,不會被網站的過濾機制發現,就像一次正常的請求;“探子”的目的有以下兩個(1.目標引數值是否會出現在回應上,如果不出現,就完全沒必要進行后續的payload請求與分析;目標引數值出現在HTML的哪一個部分,從上面的分析我們已經知道,不同的HTML部分對待XSS的機制是不一樣的,請求的payload當然也不一樣)
- 關于存盤型xss挖掘:這里一般是表單的提交,然后進入服務端存盤中,最侄訓在某個頁面上輸出
6.2.神奇的DOM渲染
- HTML與JavaScript自解碼機制:在JavaScript執行之前,HTML形式的編碼會自動解碼;
- 具備htmlencode功能的標簽:HTML在
<textarea>中是不決議的,這樣的標簽還有title、iframe、noscript、noframes;textarea在HTML中的權重很高,允許html標簽出現在<textarea><textarea>之間; - url編碼差異
- dom修正式渲染:view-source這樣看到的“HTML編碼”實際上是靜態的;按F12鍵打開對應的除錯工具,這些除錯工具查看的原始碼是動態結果;瀏覽器在DOM渲染上進行各種修正,不同的瀏覽器進行的這種修正可能存在一些差異,這種修正式的渲染可以用于繞過瀏覽器的XSS Filter;
- 一種dom fuzzing的技巧:模糊測驗(fuzzing);
6.3.DOM XSS挖掘
- 靜態方法:一旦發現頁面存在可疑特征,就進行人工分析,這是靜態方法的代價,對人工參與要求很高
- 動態方法:動態方法很難完美的實作檢測引擎,這實際上是一次JavaScript原始碼動態審計的程序
6.4.Flash XSS挖掘
- XFS挖掘思路:XSF即Cross Site Flash;很多網站的Flash播放器都會有XSF風險,因為這些播放器需要能夠靈活加載第三方Flash資源進行播放;
- Google Flash XSS挖掘:Google對它們的域分離的非常好,把那些無關緊要的內容都放到了其他域名上,這樣,這個XSS就是雞肋了;
6.5.字符集缺陷導致的XSS
- ASCII字符集表達不了拉丁系的字符,更表達不了東亞字符,所以各種演變出現了諸多字符集,如ISO8859、GB2312、GBK、GB18030、BIG5、Shift_JIS,直到Unicode字符集出現,才看到了世界和平的曙光,但是各國的這些字符集還在沿用,不可能清零從頭開始,所以這個字符的世界還是很混亂
- Unicode字符集的編碼方式有UTF-8、UTF-16、UTF-32、UTF-7,常見的是UTF-8與UTF-7
- 編碼的目的是最終將這些字符正確地轉換為計算機可理解的二進制,對應的解碼就是將二進制最終解碼為人類可讀的字符
- 寬字符編碼帶來的安全問題:主要是吃ASCII字符(一位元組)的現象;從前端到后端的流程中,字符集編碼處理不一致可能導致SQL注入、命令執行等一系列安全問題;
- UTF-7問題:UTF-7時Unicode字符集的一種編碼方式,不過并非是標準推薦的,現在僅IE瀏覽器還支持UTF-7的決議;IE瀏覽器歷史上出現以下好幾類UTF-7 XSS(1.自動選擇UTF-7編碼;2.通過iframe方式呼叫外部UTF-7編碼的HTML檔案;不過現在IE限制了
<iframe>只能嵌入同域內的UTF-7編碼檔案;3.通過link方式呼叫外部UTF-7編碼的CSS檔案;4.通過指定BOM檔案頭;BOM的全稱為Byte Order Mark,即標記位元組順序碼,只出現在Unicode字符集中,BOM出現在檔案的最開始位置,軟體通過識別檔案的BOM來判斷它的Unicode字符集編碼方式);在實際的攻擊場景中,能控制目標網頁開頭部分的功能如下(用戶自定義的CSS樣式檔案;JSON Callback型別的鏈接;) - 瀏覽器處理字符集編碼BUG帶來的安全問題:標準總是過于美好,比如字符集標準,但是每個瀏覽器在實施這些標準時不一定就能很好地實施,所以不要輕信它們不會出現BUG
6.6.繞過瀏覽器XSS Filter
- 目前,主要是IE和Chrome兩大瀏覽器擁有XSS Filter機制,不可能有完美的過濾器
- XSS Filter主要針對反射型XSS,大體上采用的都是一種啟發式的檢測,根據用戶提交的引數判斷是否是潛在的XSS特性,并重新渲染回應內容保證潛在的XSS特性不會觸發
- 回應頭crlf注入繞過
- 針對同域的白名單:嚴格來說,針對同域的白名單機制不是繞過,而是瀏覽器的性質,這種性質給反射型XSS的利用提供了便利,IE和Chrome在這個機制上不太一樣;IE會判斷Referer來源是否是本域,如果是,則XSS Filter不生效;Chrome的同域白名單機制和IE完全不一樣,如果是
<script>嵌入同域內的js檔案,XSS Filter就不會防御,這個受CSP策略的影響; - 場景依賴性高的繞過
6.7.混淆的代碼
- 為了提高漏洞挖掘的成功率,我們經常需要對各種代碼進行混淆,以繞過過濾機制
- 瀏覽器的進制常識:在瀏覽器中常用的進制混淆有八進制、十進制和十六進制;在JavaScript中可以直接通過eval執行的字串有八進制和十六進制兩種編碼方式;需要注意的是,這兩種表示方式不能夠直接給多位元組字符編碼(如漢字、韓文等),如果代碼中應用了漢字并且進行進制編碼,那么只能進行十六進制Unicode編碼;JavaScript自身就帶有兩個函式可以處理這個事情:char.toString(jinzhi)(char為需要編碼的單字,jinzhi為需要編碼的進制,可以填寫2、8、10、16或其他之類數字)、String.fromCharCode(code, jinzhi);
- 瀏覽器的編碼常識:在JavaScript中,有三套編/解碼的函式:escape/unescape、encodeURI/decodeURI、encodeURIComponent/decodeURIComponent;除了JavaScript提供的這三種加/解密方法外,我們還需要了解HTMLEncode、URLEncode、JSEncode、UTF-7編碼、Base64編碼的相關知識;
- html中的代碼注入技巧:完整的HTML代碼分為:標簽名、屬性名、屬性值、文本、注釋,其中可以是JavaScript事件、資源鏈接或data物件;1.標簽:(由于HTML語言的松散性和各標簽的不同優先級,使得我們可以創造出很多代碼混淆或繞過方式;另外還有一種特殊的注釋:IE HTML條件控制陳述句);2.屬性:(HTML標簽中的屬性同樣也是大小寫不敏感的,并且屬性值可以用雙引號引起來,也可以用單引號,甚至不用引號在HTML語法上也是正確的;此外,標簽和屬性之間、屬性名和等號之間、等號和屬性值之間可以用空格、換行符(chr(13))、回車符(chr(10))或者tab(chr(9))等,并且個數不受限制;還有一個常識對我們來說非常重要,HTML中通過屬性定義的事件在執行時會做HTMLDecode編碼);3.HTML事件(另一種特殊的HTML屬性是事件屬性,一般以on開頭,它繼承了普通的HTML屬性的所有特點:大小寫不敏感、引號不敏感等)
- css中的代碼注入技巧:與HTML一樣,我們可以將CSS分為選擇符、屬性名、屬性值、規則和宣告幾部分;與HTML類似,CSS的語法同樣對大小寫不敏感,屬性值對單引號不敏感,對資源類屬性來說,URL部分的單雙引號以及沒有引號也都不敏感,并且凡是可以使用空格的地方使用tab制表符、回車和換行也都是可以被瀏覽器決議;1.CSS資源類屬性:(與HTML的資源類屬性類似,CSS的一些資源類屬性的XSS利用也是通過偽協議來完成的,這種利用方式目前只能在IE下被執行,并且IE9已經可以防御住;CSS還有一類資源類屬性可以嵌入XML、CSS或者JavaScript,比如,Firefox2獨有的-moz-binding、IE獨有的behavior以及規則@import);2.expression:(expression是IE所獨有的CSS屬性,其目的就是為了插入一段JavaScript代碼);3.利用UTF-7編碼進行CSS代碼混淆(介紹monyer在線加解密工具時,提過兩個加/解密:UTF7Encode和UTF7Decode,將頁面進行UTF7編碼,這為混淆我們的代碼、繞過u對方的過濾器提供了很大便利)
- JavaScript中的代碼注入技巧
- 突破url過濾:可以參考如下一些技巧來繞過過濾:URL編碼、十進制、十六進制、八進制、混合編碼、不帶http:協議、最后加個點;
- 更多經典的混淆checklist:通過大量的模糊測驗可以發現很多奇怪的XSS利用點,瀏覽器之間存在大量細微的差異,很難總結出完美的規律;可以參考html5sec.org網站上整理的Checklist,還有一個由Gareth Heyes主導構建起來的在線fuzzing平臺(shazzer.co.uk);
6.8.其他案例分享-GmailCookieXSS
- FireCookie是Firefox瀏覽器擴展Firebug的一個插件,專門用于Cookie的各種操作,非常方便
第七章 漏洞利用
- 漏洞利用要完美,就得保證利用程序的原生態,本意就是讓被攻擊者區分不出,甚至被攻擊后很長一段時間或者永遠都不知道發生過這樣的事情
7.1.滲透前的準備
- 1.目標環境:對于開源CMS的滲透,可以通過白盒、黑盒 方式了解透,大大方便后續的滲透,而對于閉源的CMS,我們只能利用黑盒進行,會更麻煩,需多走幾個步驟
- 2.目標用戶:目標用戶的角色可以很多種,如:CMS管理員、客服、普通用戶、黑客/安全人員等
- 3.預期效果:最后明確本次滲透程序中每一階段的效果,如:獲取Cookie、添加一篇文章、傳播網馬、盜取密碼、破壞資料等
7.2.偷取隱私資料
- XSS探針:xssprobe:通過它可以獲取目標頁面的通用資料;利用這些通用資料,有時能讓我們直接獲取目標用戶的權限(通過Cookies利用);
- referer惹得禍:Referer指請求來源,很多網站通過這個來判斷用戶是從哪個頁面/網站過來的,Referer是公開的,故不可在Referer中存在與身份認證或者其他隱私相關的資訊,但很多網站設計之初沒考慮到Referer的風險性,從而導致出現了安全問題;
- 瀏覽器記住的明文密碼:2010年時,各瀏覽器開始逐漸加入“記住密碼”的功能(這些瀏覽器包括Firefox、Chrome、IE、Opera、Safari等),記住密碼不同于老方式“記住登錄狀態”,“記住登錄狀態”主要是設定了持久型的Cookie,這和瀏覽器沒關系,而是Web服務自己設定的;與記住表單內容相比,記住密碼更危險,因為通過DOM就能獲取其中的密碼,而且是明文;可以在XSS利用中使用該POC獲取用戶的明文密碼,由于不同的Web環境下的密碼表單項不太一樣,此時只需要修改相關的表單項值就行;
- 鍵盤記錄器:鍵盤記錄器實際上用處并不大,還不如劫持表單項的各種事件方便;
7.3.內網滲透技術
- 內網滲透是一門獨立的學問,通過Web層面(主要是JavaScript)進行的內網滲透實際上是一種很淺的滲透,不過帶來的威力有可能很大
- 獲取內網ip:目前,內網IP的獲取還有一個比較好的方式,即通過Java Applet,但需要JRE支持
- 獲取內網ip埠:Image物件請求時,得到資源后就觸發onerror事件(因為這個資源不是正常的圖片),得不到就進入timeout機制,通過這個原理來判斷目標IP與埠是否存在,不過這個功能不太穩定;還可以嘗試通過跨域AJAX技巧或Web Socket方法實作IP埠的獲取;
- 獲取內網主機存活狀態:主機存活狀態的獲取技巧很不錯,本質是通過跨域AJAX請求進行的判斷,比較穩定;
- 開啟路由器的遠程訪問能力:默認的“遠程管理IP地址”是0.0.0.0,如果設定為255.255.255.255,則允許互聯網上任意IP進行遠程Web方式的管理,即通過瀏覽器登錄這臺FAST的外網IP,輸入用戶名與密碼即可進行管理操作;
- 內網脆弱的web應用控制:通過Referer有可能泄露內網Web應用的地址,即通過對Referer的判斷可能猜測出這個Web應用的型別,還可以通過fuzzing方式,猜測內網可能存在的Web應用;常見的內網Web應用型別有:BBS、Blog、Trac、Wiki、OA、WebMail、專案管理、客服后臺、存在漏洞的Web應用環境等;
7.4.基于CSRF的攻擊技術
- 基于CSRF的攻擊技術也是一種比較通用的思想:基于CSRF的攻擊技術也是一種比較通用的思想
- 包括如下內容:基于CSRF的SQL注入;基于CSRF的命令執行;基于CSRF的XSS攻擊;
7.5.瀏覽器劫持技術
- 瀏覽器劫持技術是指通過劫持用戶點擊鏈接操作,在打開新視窗的時候注入攻擊者的JavaScript腳本,以達到將XSS威脅延續到同域內的其他頁面
7.6.一些跨域操作技術
- ie res:協議跨域
- css string injection跨域:一個非常有趣的跨域技巧,@import方式匯入外域CSS檔案本身是一個正常的行為,然后IE通過document.body.currentStyle.fontFamily方式訪問目標樣式的font-family屬性,它的值是font-family之后的所有內容,這是CSS高容錯性導致的
- 瀏覽器特權區域風險
- 瀏覽器擴展風險:瀏覽器為了豐富自身的功能,允許第三方提供各類插件或擴展,但這些擴展的權限如果沒控制好,就會帶來嚴重的后果
- 跨子域:document.domain技術技巧:跨子域:document domain技巧非常好用,屬于瀏覽器的性質;有一個合法的性質是:這個頁面可以設定document.domain為當前子域或比當前子域更高級的域,一般頂級就到了根域;
- 更多經典的跨域索引:1.利用UNC“跨域”:通過Internet域(http協議)的代碼,比如
<iframe>標簽利用file協議呼叫本地的XSS漏洞頁面,并通過這個本地XSS執行任意的JavaScript代碼,由于是file協議,權限會更大,比如,利用AJAX讀取本地檔案;2.mhtml:協議跨域;
7.7.XSS Proxy技術
- XSS Proxy技術用到了基于瀏覽器的遠程控制上,這是一種非常好的思想,現在很多XSS利用框架,如XSS Shell、BeEF、Anehta等遠程控制都是基于XSS Proxy的
- 要實作遠程控制,必須具備以下兩個條件:遠控指令要在目標瀏覽器上“實時”執行;執行結果要能夠讓控制端看到
- XSS Proxy技術的4種思路,各有千秋
- 瀏覽器
[script]請求:<script>標簽請求內容可跨域,這是合法的功能,請求到的資料必須是合法的JavaScript語法格式;包括請求回來的是JSON+CallBack函式這樣的資料內容(這種跨域資料通信被稱為JSONP); - 瀏覽器跨域ajax請求:跨域AJAX請求也需要瀏覽器setInterval去主動發起服務端指令介面請求,唯一的好處是,這種請求時異步發起的,會顯得更加安靜;
- 服務端websocket推送指令:嚴格地說,WebSocket技術不屬于HTML5,這個技術是對HTTP無狀態連接的一種革新,本質就是一種持久性socket連接,在瀏覽器客戶端通過JavaScript進行初始化連接后,就可以監聽相關的事件和呼叫socket方法來對服務端的訊息進行讀寫操作;
- postMessage方式推送指令:HTML5的postMessage機制非常完美,是客戶端最直接的跨檔案傳輸方法,一般用在iframe中父頁與子頁之間的客戶端跨域通信;這個技巧如果用于XSS Proxy上可能有些繞,攻擊者需要動態生成,然后在客戶端進行跨域傳輸指令,這是一種思路,不過不好;
第八章 HTML5安全
- HTML5現在由WHATWG、W3C、IETF三個組織來共同開發制定
8.1.新標簽和新屬性繞過黑名單策略
- 白名單和黑名單過濾器策略是防御XSS攻擊的重要方法
- 跨站中的黑名單策略
- 新元素突破黑名單策略:要繞過這種黑名單策略,一種方法就是跨站師使用變形后的代碼繞過正則運算式的語意范圍,另一種情況是下面將要提到的HTML5新標簽和新屬性;1.HTML5中可以利用到的新標簽有音頻標簽
<audio>和視頻標簽<video>;2.HTML5中可以利用到的新屬性有formation、onformchange、onforminput、autofocus等;
8.2.HistoryAPI中的新方法
- pushstate()和replacestate():HTML5的History API中新增加了兩個新方法pushState()和replaceState(),可以在不重繪頁面的情況下添加和修改歷史條目
- 短地址+history新方法=完美隱藏url惡意代碼:短地址服務是指把一個冗長的網址轉換成一個簡潔的網址;當用戶點擊短地址的時候,并不知道它指向哪里,此時攻擊者就可以利用短地址這個特性,把注入惡意代碼的網站轉換為短地址,用戶單擊這個短地址后,就會遭到攻擊;現在可以利用History的新方法pushState()和replaceState(),在無重繪頁面的情況下改變地址欄中的URL,用戶就無法看到惡意代碼;
- 偽造歷史記錄:使用history.pushState可以對瀏覽器的歷史記錄進行偽造,而且也可以對歷史記錄發起Dos攻擊
8.3.HTML5下的僵尸網路
- 僵尸網路(英文名為Botnet)是指,通過各種手段在大量的計算機中植入特定的惡意程式,使控制著能夠通過相對集中的若干計算機直接向大量計算機發送指令的攻擊網路
- web worker的使用:HTML5中的Web Worker可以讓Web應用程式具備后臺處理能力,比如,讓Worker進行并行計算、后臺I/O操作等,而且對多執行緒支持非常好;Web Worker不會導致瀏覽器UI停止回應,短暫的Worker操作不會讓用戶察覺,但如果是長時間大量的Worker運算操作,則會消耗CPU周期,使系統變慢,用戶可能看到CPU始終保持在高位;
- cors向任意網站發送跨域請求:CORS的安全策略僅僅在于是否允許客戶端獲取服務器的回傳資料,但并不會阻止客戶端發送的請求
- 一個html5僵尸網路實體:如何控制更多的僵尸節點?蠕蟲可以將被感染的用戶瀏覽器變成僵尸節點
8.4.地理定位暴露你的位置
- 使用HTML5 Geolocation API(地理定位API),就可以請求用戶共享自己的地理位置,如果用戶同意,程式就可以定位到用戶的地理位置
- 隱私保護機制:這套隱私機制完全由瀏覽器控制;用戶對于記住共享設定的功能需要注意,尤其是用戶選擇了允許共享地理位置,這有可能使用戶一直暴露自己的地理位置;
- 通過XSS盜取地理位置:獲取這類真實地理資訊比較容易,同時,結合原生的社工技巧,攻擊成功的概率會更高
第九章 Web蠕蟲
- 蠕蟲的一個特性就是傳播性,對于Web蠕蟲來說,傳播的媒介就是Web2.0網站的瀏覽器客戶端,而傳播的基石則是廣大用戶
9.1.Web蠕蟲思想
- Web蠕蟲主要包括:XSS蠕蟲、CSRF蠕蟲、Clickjacking蠕蟲,這三類蠕蟲都與具體的漏洞風險有關系,從名字上很好區分
- Web蠕蟲的思想很簡單,就是用戶參與,而Web2.0網站正好具備這個條件
- 從XSS蠕蟲到CSRF蠕蟲,再從Clickjacking蠕蟲到文本蠕蟲,越往后,社工的成分越大
9.2.XSS蠕蟲
- 原理+一個故事:蠕蟲具有的最主要的兩個性質如下:傳播性、病毒行為;XSS蠕蟲的發生需要具備以下條件(目標網站具備Web2.0的關鍵特性:內容由用戶驅動;均存在XSS漏洞;被感染的用戶是登錄狀態,這樣XSS的權限就是登錄后的權限,能執行更多惡意的操作;XSS蠕蟲傳播利用的關鍵功能本身具備內容傳播性)
- 危害性:XSS蠕蟲的權限大(一般情況下,Web用戶有多大權限,它就有多大權限);1.對用戶資料進行任意操作(XSS蠕蟲傳播開后,可以批量對用戶資料進行惡意操作);2.拒絕服務攻擊(XSS蠕蟲可以對目標網站服務進行大面積的拒絕服務攻擊,導致用戶無法正常使用網站功能);3.分布式拒絕服務攻擊(分布式拒絕服務攻擊的目標是其他網站,XSS蠕蟲的每個被感染用戶在地理位置上可能分布在全國各個位置,甚至世界各個位置);4.散播廣告;5.傳播網頁木馬(一般情況下,網馬是利用瀏覽器與瀏覽器插件漏洞(最臭名遠昭的就是IE的ActiveX控制元件)進行本地攻擊,將網馬內的二進制資料或腳本病毒植入作業系統本地執行,本來在Web層面上的威脅,通過這些漏洞蔓延到了作業系統層面,在作業系統層面上,病毒的權限至少就是作業系統用戶賬號的權限);6.傳播輿情
- 蠕蟲需要追求原生態:框架封裝了太多優秀的函式,對XSS來說,直接呼叫就好,可以省去許多自定義代碼的麻煩,而且可以大大減少XSS蠕蟲的大小,這樣的XSS蠕蟲就是原生態的;1.代碼的原生態:簡單的幾行代碼就可以發起GET或POST請求,而且使用原生態的框架還有一個好處,它幫我們處理了各種瀏覽器兼容的問題;2.攻擊效果的原生態:那些DIV框、UI組件都是可以直接呼叫一些高度封裝的JavaScript函式來生成;
9.3.CSRF蠕蟲
- 關于原理和危害性:CSRF蠕蟲的原理和XSS蠕蟲基本類似,只是這里用到的是CSRF,攻擊代碼存在于攻擊者頁面中,目標網站傳播的內容都包含攻擊者頁面URL,這樣才能傭訓目標網站上的被攻擊者打開攻擊者頁面,然后觸發CSRF,CSRF會繼續跨域發布含攻擊者頁面URL的內容進行傳播;和XSS蠕蟲不一樣的是:XSS蠕蟲的攻擊代碼本質上是存放在目標網站上的,即使是
<script>從攻擊者域上參考進來,對JavaScript背景關系來說,也屬于目標網站;CSRF蠕蟲的危害性大多與XSS蠕蟲一樣,如:獲取用戶隱私、對用戶資料進行惡意操作、散播廣告、傳播網頁木馬、傳播輿情等; - 譯言CSRF蠕蟲:攻擊代碼可以做得非常隱蔽,順便加上了Referer判斷,而蠕蟲代碼就是靠得到的這個Referer值進行后續操作的,由于Ajax無法跨域獲取操作第三方服務器上的資源,于是使用了服務端代理來完全跨域獲取資料的操作(Microsoft.XMLHTTP控制元件的使用);有一點要強調下,蠕蟲傳播的前提是目標用戶登錄了目標網站,然后才能看到訊息并中招,之后的傳播必定會帶上目標用戶的記憶體Cookie,所以這個程序不受限于IE下的本地CookieP3P策略的宣告;
- 飯否CSRF蠕蟲-邪惡的Flash游戲:飯否CSRF蠕蟲是利用Flash進行傳播的,本質上是該Flash檔案里的ActionScript腳本向飯否發起CSRF請求;CSRF請求有兩種:一種是Get請求獲取攻擊者相關的隱私資料,第二種是POST請求提交資料,使得被攻擊者自動發送一條微博訊息并向自己的好友都發一條私信;這些Web蠕蟲都是基于用戶群的,需要大量的用戶參與,借用戶互動之勢而傳播,而用戶之間卻存在一種信任關系,一般情況下,如果是自己的好友給自己發訊息,都會去看,因為彼此很信任,飯否的這個蠕蟲傳播正是利用了這個特性;
- CSRF蠕蟲存在的可能性分析:顧名思義,CSRF蠕蟲就是利用CSRF技術進行傳播的Web蠕蟲,前者的譯言CSRF蠕蟲以及相關分析文章說明了CSRF蠕蟲存在的事實,譯言網站的這個CSRF是由用戶驅動的,蠕蟲的代碼都存放于另外一個網站上;要解決的最關鍵的問題就是CSRF蠕蟲的傳播性,即基于用戶驅動的傳播性(主動或者被動);跨域獲取資料的幾種方式:CSRF蠕蟲傳播必須面對的問題是如何獲取各種必要的唯一值,這里有三種方式:服務端代理技術、FlashAS跨域請求技術、JSONHijacking技術;通過對CSRF蠕蟲傳播原理的分析,許多廣泛存在CSRF漏洞的Web2.0網站都面臨著CSRF蠕蟲的威脅,Web2.0蠕蟲由用戶驅動(被動的或主動的),加上一些社工技巧,這將很難防御;
9.4.ClickJacking蠕蟲
- ClickJacking蠕蟲的由來:2009年初Twitter上發生的“Don't Click”蠕蟲事件;
- ClickJacking蠕蟲技術原理分析:技術分析:首先,攻擊者使用ClickJacking技術制作蠕蟲頁面,該頁面的URL地址使用TINYURL短地址轉http://tinyurl.com/amgzs6;設計要點:對iframe和button標簽進行CSS樣式設定,放置iframe標簽所在層為透明層,使iframe標簽所在層位于button標簽所在層的正上方;要發動ClickJacking蠕蟲攻擊,滿足以下兩點必要條件即可(在SNS社區網路中,找到一個可以直接使用HTTP的GET方式提交資料的頁面;這個頁面可以被
<iframe>標簽包含;) - Facebook的LikeJacking蠕蟲:Facebook遭遇的LikeJacking蠕蟲攻擊;Facebook中有一項插件服務,叫“Like Button”,用戶可以在自己的博客或自己的網站中加入“Like Button”,訪客瀏覽時,可以單擊這個按鈕表示自己喜歡這篇文章,當單擊結束后,訪客點擊的狀態資訊會在訪客的Facebook頁面上以狀態更新的方式顯示出來;攻擊者可以使用ClickJacking技術欺騙訪客單擊這個“Like Button”;
- GoogleReader的ShareJacking蠕蟲:非常流行的“一鍵分享”功能插件;這種插件可以讓用戶把在網路中看到的好文章或好資源直接以廣播訊息的形式發布到自己的社區和好友們進行分享;除了發現Google Reader存在ShareJacking蠕蟲攻擊外,還發現國內SNS環境中騰訊微博、騰訊空間、騰訊朋友、搜狐微博、人人網、淘江湖均存在這種攻擊;
- ClickJacking蠕蟲爆發的可能性:分享已經是當前SNS網路中一個很重要的社交內容,只要是帶有共享性質的網路社區,都有可能會遭受到ClickJacking蠕蟲的攻擊;Twitter的一鍵分享頁面http://twitter.com/intent/tweet已經在HTTP頭關鍵字中加入X-FRAME-OPTIONS來抵御ClickJacking攻擊,Facebook的一鍵分享頁面http://www.facebook.com/sharer/sharer.php中也使用了Frame Busting腳本來進行抵御;
第十章 關于防御
10.1.瀏覽器廠商的防御
- HTTP回應的X-頭部:HTTP回應的擴展頭部欄位都以X-打頭,用于區分標準的頭部欄位;與前端安全有關的頭部欄位有如下幾個:X-Frame-Options、X-XSS-Protection、X-Content-Security-Policy;1.X-Frame-Options的值有以下兩個:DENY(禁止被加載進任何frame)、SAMEORIGIN(僅允許被加載進同域內的frame);2.X-XSS-Protection的值有以下三個:0(表示禁用)、1(默認,對危險腳本做一些標志或修改,以阻止在瀏覽器上渲染執行,Chrome和IE這方面的行為是有差異的)、1:mode=block(強制不渲染,在Chrome下直接跳轉到空白頁,在IE下回傳一個#符號);
- 遲到的CSP策略:前面提到Web前端混亂局面,比如IE下的CSS的expression可以寫JavaScript,再如,HTML的標簽
<script>、標簽on事件、標簽style屬性、標簽src/href/action等屬性都可以內嵌JavaScript執行;HTML僅做HTML的事,JavaScript/CSS都通過加載獨立檔案的方式被執行,JavaScript/CSS獨立檔案所在的域可以配置為白名單,這樣就能有效地防止加載攻擊者域上的相關資源檔案,這大大提高了XSS攻擊的難度,這就是CSP策略的最大設計初衷;CSP策略使得Web前端更有序,從而更安全,這是一個好趨勢,W3C已經在大力推進這樣的策略;目前,Chrome支持CSP策略的頭部是X-WebKit-CSP,而不是標準的X-Content-Security-Policy;下面舉幾個應用CSP的場景(1、不允許任何外部的資源加載,且允許內嵌腳本執行;2、僅允許白名單的外部資源加載,不允許內嵌腳本執行;)
10.2.Web廠商的防御
- 域分離:域分離做得好的可以參考Google,Google將一些業務關聯性小的內容轉移到了不相干的域中
- 安全傳輸:Google很多重要的業務都完美地支持HTTPS安全傳輸(包括搜索),安全傳輸可以有效地防止局域內的明文抓包
- 安全的Cookie:可以學學Google,某些身份認證相關的Cookie肯定嚴格設定為HTTPS傳輸,肯定是HttpOnly標志,這樣XSS即使盜取了Cookie,也無法正確使用
- 優秀的驗證碼:驗證碼的出現肯定降低了用戶體驗,但是這個降低閾值是可以控制好的;Google的驗證碼公認是比較安全的(字母連著、扭曲變形、線條平滑、無噪等),暴力破解很困難,這也帶來了用戶體驗上的尷尬,經常會輸錯驗證碼,說明Google非常重視安全,寧可犧牲一點用戶體驗;
- 慎防第三方內容:第三方內容的安全性是經常被大家提起的,常見的有以下幾種形式:
<script>參考第三方js檔案;<iframe>參考第三方HTML檔案;<object>等參考第三方Flash等資源 - XSS防御方案:一些防御策略(輸入校驗:長度限制、值型別是否正確、是否包含特殊字符等;輸出編碼:根據輸出的位置進行相應的編碼,如HTML編碼、JavaScript編碼、URL編碼;)
- CSRF防御方案:針對CSRF攻擊的防御,目前常用的有以下幾種策略(1.檢查HTTP Referer欄位是否同域;2.限制Session Cookie的生命周期;3.使用驗證碼;4.使用一次性token;);一般防御CSRF有三種方法:判斷Referer、驗證碼、token;驗證碼的弊端很明顯:會對用戶造成影響;token存在的問題是:時效性無法保證;token防CSRF的原理是:無法通過AJAX等方式獲得外域頁面中的token值,XMLHttpRequest需要遵守瀏覽器同源策略;而臨時Cookie的原理是:Cookie只能在父域和子域之間設定,也遵守同源策略;
- 界面操作劫持防御:基于界面操作劫持的攻擊模式是用巧妙的視覺欺騙的方式,對Web會話進行劫持;基于界面操作劫持的攻擊模式是用巧妙的視覺欺騙的方式,對Web會話進行劫持;目前針對界面操作劫持的防御有以下幾種(1.X-Frame-Options防御:由微軟提出來的防御界面操作劫持的一種方法,Web開發人員可以在HTTP回應頭中加入一個X-Frame-Options頭,瀏覽器會根據X-Frame-Options欄位中的引數來判斷頁面是否可以被iframe嵌入;2.Frame Busting腳本防御:使用JavaScript腳本來對頁面進行控制,達到頁面無法被iframe嵌入的目的,這樣的防護腳本被稱為Frame Busting腳本;3.使用token進行防御:在業界主流的防御界面操作劫持攻擊的方法中,似乎并沒有提及防御CSRF中的token也可以對其進行防御;);X-Frame和Frame Busting方法都可以做到對界面操作劫持的防御,相對而言,X-Frame-Options的方式還是比Frame Busting更安全,X-Frame-Options是在瀏覽器中嵌入的,而Frame Busting是腳本控制,這意味著JavaScript代碼始終有被突破的可能性;
10.3.用戶的防御
- 使用安全瀏覽器組合:Firefox瀏覽器+NoScript插件:NoScript插件是由Web前端安全牛人Giorgio Maone主力研發,眾多該領域牛人的貢獻可謂是安全插件的精品,能防御DOM與反射型XSS、ClickJacking,能強制進行HTTPS請求等,還能默認攔截所有網站的JavaScript、Flash、Java等
- 遵守信任最小原則
10.4.邪惡的SNS社區
- SNS里的攻擊圍繞著信任關系進行的,其特點是:人們往往信任自己熟悉的人,信任程度的高低一般取決于熟悉的程度與目標本身的信譽
寫在后面
- pdf書籍、筆記思維導圖、隨書代碼打包下載地址:https://pan.baidu.com/s/1CItemx1hsDgxnE25kbX0fg(提取碼:uloo)
- 紙質書京東購買地址:https://u.jd.com/R5ve7p(推薦使用紙質書來學習)
- 為了方便在手機上查看,后面我會把這些筆記陸續發布到公眾號“派三派四”,可以掃碼關注一下,歡迎關注,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qiye/43681.html
標籤:Html/Css
上一篇:(html+css)云道首頁
下一篇:HTML連載85-添加選擇圓點
