[書籍精讀]《Web前端黑客技術揭秘》精讀筆記分享

寫在前面

• 書籍介紹：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（推薦使用紙質書來學習）
• 為了方便在手機上查看，後面我會把這些筆記陸續發佈到公眾號“派三派四”，可以掃碼關註一下，歡迎關註。