關于 Web 安全，99% 的網站都忽略了這些
作者：肖光宇
</blockquote>
野狗科技聯合創始人，先后在貓撲、百度、搜狗任職。技術棧較廣，曾經致力于數據分析，異常檢測領域，通過數學模型和機器學習解決用戶輸入和搜索廣告中的反作弊難題。也曾做過java開發，熟悉從網絡到前端的全部技術。
公眾訂閱號：wilddogbaas
Web安全是一個如何強調都不為過的事情，我們發現國內的眾多網站都沒有實現全站https，對于其他安全策略的實踐更是很少，本文的目的并非討論安全和攻擊的細節，而是從策略的角度引發對安全的思考和重視。
1. 數據通道安全
http協議下的網絡連接都是基于明文的，信息很有可能被泄露篡改，甚至用戶都不知道通信的對方是否就是自己希望連接的服務器。因此，信息通道安全有以下兩個目標：
身份認證
</li>數據不被泄漏和篡改
</li> </ul>幸運的是https解決了上述問題的（更多關于https的細節可以看下上一篇干貨扒一扒https網站的內幕)。理論上https是安全的，即使如此，https依然應該被重視，因為理論上理論和實踐是一樣的，但實踐中又是另外一回事。前段時間爆發的心血漏洞就是一個例子。
2. 瀏覽器安全
https解決了點到點的安全問題和身份認證問題，接下來會出現問題的地方就只有2個：瀏覽器和服務器，這個層面上的安全問題并沒有https一樣的銀彈可以一次性解決。
2.1 origin 源
了解瀏覽器安全，有一個概念特別重要，那就是源(origin) 什么是源呢？
相同的HOST
</li>相同的協議
</li>相同的端口
</li> </ul>舉栗子：
https://www.wilddog.com和http://www.wilddog.com非同源，因為協議不同。
</li>http://wilddog.com和http://www.wilddog.com非同源，因為域名不同。
</li>http://wilddog.com和http://wilddog.com:8080非同源，因為端口不同。
</li> </ul>源這個概念為甚這么重要，這要從同源策略說起。
2.2 同源策略
同源策略限制了一個源（origin）中加載文本或腳本與來自其它源（origin）中資源的交互方式。簡單的說就是一個源的頁面上的js只能訪問當前源的資源，不能訪問其他源的資源。那么資源是什么呢？
DOM
</li>通過AJAX請求的網絡資源
</li>Cookie
</li>WebStorage，webSql
</li>...
</li> </ul>很顯然，同源策略以源為單位，把資源天然分隔，保護了用戶的信息安全。
同源策略是一堵墻，然而墻并非不透風。有很多方法可以繞過同源策略讓javascript訪問其他源的資源。比如：
JSONP：基于iframe的方法（iframe+window.name iframe+window.domain iframe+webMessage）
</li>CORS：我認為只有CORS是"正當的"繞過同源策略的方法 同源策略是瀏覽器安全策略的基礎，但同源策略面對很多攻擊是無能為力的，比如XSS
</li> </ul>2.3 XSS (Cross-Site Script)
跨站腳本攻擊，名字跟同源策略很像，事實上他們之間基本沒有關系。跨站腳本攻擊本質上是一種注入攻擊（有興趣了解更多注入攻擊可以看 Injection Theory）。其原理，簡單的說就是利用各種手段把惡意代碼添加到網頁中，并讓受害者執行這段腳本。XSS的例子只要百度一下有很多。XSS能做用戶使 用瀏覽器能做的一切事情。可以看到同源策略無法保證不受XSS攻擊，因為此時攻擊者就在同源之內。
XSS攻擊從攻擊的方式可以分為：
反射型
</li>存儲型
</li>文檔型
</li> </ul>這種分類方式有些過時，長久以來，人們認為XSS分類有以上三種，但實際情況中經常無法區分，所以更明確的分類方式可以分為以下兩類：
client(客戶端型)
</li>server(服務端型)
</li> </ul>當一端XSS代碼是在服務端被插入的，那么這就是服務端型XSS，同理，如果代碼在客戶端插入，就是客戶端型XSS。
2.4 防止XSS攻擊--轉義
無論是服務端型還是客戶端型XSS，攻擊達成需要兩個條件：
代碼被注入
</li>代碼被執行
</li> </ul>其實只要做好無論任何情況下保證代碼不被執行就能完全杜絕XSS攻擊。詳情可以看下XSS (Cross Site Scripting) Prevention Cheat Sheet這篇文章。
這里簡單說下結論：任何時候都不要把不受信任的數據直接插入到dom中的任何位置,一定要做轉義。2.4.1 對于某些位置,不受信任的數據做轉義就可以保證安全：
div body的內部html
</li>一般的標簽屬性值
</li> </ul>2.4.2 對于某些位置，即使做了轉義依然不安全：
<script>中
</li>注釋中
</li>表簽的屬性名名
</li>標簽名
</li>css標簽中
</li> </ul>2.4.3 使用JSON.parse 而不是eval,request 的content-type要指定是Content-Type: application/json;
2.4.4 如果鏈接的URL中部分是動態生成的，一定要做轉義。
2.5 HTML 轉義
2.6 使用瀏覽器自帶的 XSS-filter
現代瀏覽器都對反射型XSS有一定的防御力，其原理是檢查url和dom中元素的相關性。但這并不能完全防止反射型XSS。另外，瀏覽器對于存儲型XSS并沒有抵抗力，原因很簡單，用戶的需求是多種多樣的。所以，抵御XSS這件事情不能指望瀏覽器。
可以通過http頭控制是否打開XSS-filter,當然默認是打開的.X-XSS-Protection
2.7 CSP(Content Security Policy)
從原理上說防止XSS是很簡單的一件事，但實際中，業務代碼非常多樣和復雜，漏洞還是時不時會出現。CSP并不是用來防止XSS攻擊的，而是最小化 XSS發生后所造成的傷害。事實上，除了開發者自己做好XSS轉義，并沒有別的方法可以防止XSS的發生。CSP可以說是html5給Web安全帶來的最 實惠的東西。CSP的作用是限制一個頁面的行為不論是否是javacript控制的。
如何引入CSP呢？
2.7.1 通過response頭
//只允許腳本從本源加載Content-Security-Policy: script-src 'self'2.7.2 通過html的meta標簽
//作用同上<meta http-equiv="Content-Security-Policy" content="script-src 'self'">那么CSP除了限制script-src之外還能限制什么呢？
base-uri: 限制這篇文檔的uri；
</li>child-src: 限制子窗口的源(iframe、彈窗等),取代frame-src；
</li>connect-src: 限制腳本可以訪問的源；
</li>font-src: 限制字體的源；
</li>form-action: 限制表單能夠提交到的源；
</li>frame-ancestors: 限制了當前頁面可以被哪些頁面以iframe,frame,object等方式加載；
</li>frame-src: deprecated with child-src,限制了當前頁面可以加載哪些源，與frame-ancestors對應；
</li>img-src: 限制圖片可以從哪些源加載；
</li>media-src: 限制video,audio, source,track能夠從哪些源加載；
</li>object-src: 限制插件可以從哪些源加載；
</li>sandbox: 強制打開沙盒模式；
</li> </ul>可以看出，CSP是一個強大的策略，幾乎可以限制了所有能夠用到的資源的來源。使用好CSP可以很大成都降低XSS帶來的風險。另外，CSP還提供 一個報告的頭Content-Security-Policy-Report-Only，使用這個頭瀏覽器向服務器報告CSP狀態，細節先不討論。
Content-Security-Policy-Report-Only:script-src'self'; report-uri/csp-report-endpoint/CSP 目前有兩版：CSP1和CSP2。
兩版的支持狀態可以在http://caniuse.com/#search=csp中查到。
CSP1:
CSP2:
2.8 X-Frame-Options
這是response頭，現在正在使用，但以后可以被CSP的frame-ancestors取代。目前支持的狀態比起CSP frame-ancestors要好，使用的方式：
X-Frame-Options:DENY//這個頁面不允許被以frame的方式加載
</li>X-Frame-Options:SAMEORIGIN//這個頁面只允許同源頁面加載
</li>X-Frame-Options:<uri> //這個頁面只能被特定的域加載
</li> </ul>2.9 Http-Only
使用Http-only保護cookie，可以保證即使發生了XSS，用戶的cookie也是安全的。使用Http-only保護的cookie是不會被javascript讀寫的。
2.10 iframe沙箱環境
雖然有同源策略，iframe的問題還是有很多的，比如各種利用iframe進行跨源。HTML5為iframe提供了安全屬性sandbox，如果使用此屬性，iframe的能力將會被限制,細節我們將會在以后的文章中詳細討論。
2.11 其他安全相關的HTTP頭
X-Content-Type-Options阻止瀏覽器進行content-type 嗅探。告訴瀏覽器相信此服務器下發的資源的類型，防止類型嗅探攻擊。
HPKP(Public Key Pinning)Public Key Pinning是一個response頭，用來檢測一個證書的公鑰是否發生了改變，防止中間人攻擊。
HSTS (HTTP Strict-Transport-Security) 強制使用TSL作為數據通道，在扒一扒HTTPS網站的內幕中也有詳細介紹。
說了這么多我們看以下一些各個網站實現的情況：
谷歌是行業的標桿，在互聯網無出其右，學習Google就對了！
我們野狗的官網https://www.wilddog.com/同樣也實現了幾個重要的http頭。
百度做的就比較差了，一家如此大規模的互聯網公司，對于安全，對于技術如此不敏感，只能說是很悲哀，充分說明中國互聯網企業對安全的重視是非常低的！值得注意的是，百度的http到https的跳轉居然是服務端做的。
我們再來看下行業笑話12306。
3. HTML5 對 Web 安全的影響
HTML5帶來了很多新的特性，讓瀏覽器和javascript獲得了更大的能力。然而能力越大，被攻破后的危險就越大。
HTML5對XSS的影響主要體現在:
更大的攻擊面，HTML5帶來來更多的標簽和更多的屬性，XSS發生的可能性更大。
</blockquote>
更大的危害，HTML5更多的資源可以被XSS利用。黑客可以利用瀏覽器的一切權限，比如本地存儲，GEO，WebSocket，Webworker。遺憾的是HTML并沒有針止XSS和XSRF帶來系統性解決方案。在這個前提下，CSP變得非常重要，可以大大降低XSS后的危害。
HTML5時代實際對開發者提出來更高的要求，因為有更多的交互，更多的前端行為，HTML5有更多的API。希望共勉，不做蒙古大夫，與廣大的開發者一同提高中國互聯網的用戶體驗！
4. references
安全相關的HTTP頭 https://www.owasp.org/index.php/List_of_useful_HTTP_headers
</li>同源策略 https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
</li>- </li>
HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
</li>w3c iframe element http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html
</li>MDN web security https://developer.mozilla.org/en-US/docs/Web/Security
</li>XSS cheet sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
</li>野狗科技官網 https://www.wilddog.com/
</li> </ul> </div> 來自：http://segmentfault.com/a/1190000003852910