[書籍精讀]《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字符集表達不了拉丁系的字符，更表達不了東亞字符，因此各類演變出現了諸多字符集，如ISO885九、GB23十二、GBK、GB18030、BIG五、Shift_JIS，直到Unicode字符集出現，纔看到了世界和平的曙光，可是各國的這些字符集還在沿用，不可能清零從頭開始，因此這個字符的世界仍是很混亂
• Unicode字符集的編碼方式有UTF-八、UTF-1六、UTF-3二、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爲須要編碼的進制，能夠填寫二、八、十、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的場景（一、不容許任何外部的資源加載，且容許內嵌腳本執行；二、僅容許白名單的外部資源加載，不容許內嵌腳本執行；）

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（推薦使用紙質書來學習）
• 爲了方便在手機上查看，後面我會把這些筆記陸續發佈到公衆號「派三派四」，能夠掃碼關注一下，歡迎關注。