瀏覽器安全

瀏覽器安全簡介

瀏覽器進程：

瀏覽器進程，渲染進程，插件進程，擴展進程

瀏覽器安全發展史

• IE8 推出 XSS filter（修改其中的關鍵字符使得攻擊無效）
• firefox4 推出 content security policy。（由服務器返回一個 http 頭，並在其中描述頁面應該遵照的安全策略）

X-content-security-policy:allow 'self' ;img-src *;media-src media.com 
複製代碼

跨站腳本攻擊（XSS）

分類

1. 反射型 XSS

反射型 xss 只是簡單的把用戶輸入的數據「反射」給瀏覽器。黑客須要誘導用戶「點擊」一個惡意連接，才能攻擊成功。

1. 存儲型 XSS

存儲型 XSS 會把用戶輸入的數據「存儲」在服務器端

1. DOM Based XSS

經過修改頁面的 DOM 結點造成 XSS。從效果來看是反射型 XSS。

xss預防方式

• cookie 設置 HttpOnly

在沒有設置 HttpOnly 的 cookie 中，攻擊者能夠經過 document.cookie 獲得網站的 cookie。HttpOnly 是在 Set-Cookie 時服務端標記的。

• 輸入檢查

輸入檢查通常是檢查用戶輸入的數據中是否包含一些特殊的字符，如 <,> 等。若是發現特殊符號，則將這些字符過濾或者編碼。

比較智能的「輸入檢查」，可能會匹配 XSS 的特徵。好比查找用戶數據中是否包含<script>,javascript 等敏感字符。這種輸入檢查，叫作「XSS filter」

• 輸出檢查

  • 安全的編碼函數

• 防護 DOM Based XSS

事實上，DOM Based XSS 是從 javascript 中輸出數據到 html 頁面裏。而前面的防護手段是針對從服務器應用輸出到 html 頁面的xss 漏洞。

解決方法：從 javascript 輸出到 html 頁面，至關於一次 xss 輸出的過程，須要分語境使用不一樣的編碼函數。（javascriptencode，htmlencode）

會觸發DOm based xss 的地方：

1. document.write()
2. document.writeln()
3. xxx.innerHTML()
4. xxx.outerHTML()
5. innerHTML.replace()
6. document.attachEvent()
7. window.attachEvent()
8. document.location.replace()
9. document.locaion.assign()

跨站點請求僞造（CSRF）

概念：是攻擊者利用用戶身份操做帳戶的一種攻擊方式。

CSRF 進階

瀏覽器的 cookie 策略

瀏覽器所持有的 cookie 分爲兩類：一種是「session cookie」，也稱爲「臨時 cookie」。另外一種是「 third-party cookie」，也稱爲 「本地 cookie」。

二者的區別在於，third-party cookie 在 set-cookie 時設置了 expire 過時時間，到達過時時間時，cookie 纔會失效。session cookie 沒有設置過時時間，瀏覽器關閉，session cookie 就會過時。

session cookie 保存在瀏覽器進程中。而 third-party cookie 保存在本地。

若是瀏覽器從一個域的頁面中，要加載另外一個域的資源。因爲安全緣由，某些瀏覽器會阻止 third-party cookie 的發送。

P3P 頭的反作用

P3P Header 是 W3C 制定的一項關於隱私的標準，全稱是 The Platform for Privacy Preferences。

若是網站返回給瀏覽器的 http 頭中包含 P3P 投，則在某種程度上來講，將容許瀏覽器發送第三方 cookie 。在 IE 下即使是 <iframe>,<script> 等標籤也將再也不攔截第三方 cookie 的發送。

CSRF 的防護

1 驗證碼

驗證碼被認爲是對抗 CSRF 攻擊最簡潔而有效的防護方法。可是因爲處於用戶體驗考慮，不可能每一個請求都加上驗證碼的。

2 Referer Check

referer check 在互聯網中最多見的應用就是「防止圖片盜鏈」。同理，referer check也能夠被用於檢查是否來自合法的「源」

即便咱們能夠經過檢查 referer 是否合法來判斷用戶是否被 csrf 攻擊，也僅僅是知足了防護的充分條件。

referer check 的缺陷在於，服務器並非何時都能去到 referer。（不少用戶出於隱私保護的考慮，限制了 referer 的發送。在某些狀況下，瀏覽器也不會發送referer，好比從 https 跳轉到 http ，出於安全的考慮，瀏覽器也不會發送 referer）

3 Anti CSRF Token

CSRF 的本質

CSRF 可以攻擊成功，其本質的緣由是重要操做的全部參數都是能夠被攻擊者猜想到的。

出於這個緣由，能夠經過，把參數加密，或者使用一些隨機數，從而讓攻擊者沒法猜想到參數值。

可是因爲加密或混淆猴的 URL 將變得很是難讀，對於用戶體驗來講不是很好。對於數據分析工做來講，會帶來很大的困擾。

因此，請求攜帶一個 token（一個隨機值）是最好的方法。

Token 的使用原則（保密性和隨機性）

防護 CSRF 的 Token，是根據 「不可預測性原則」設計的方案，因此 Token 的生成必定要足夠隨機，須要使用安全的隨機數生成器生成 Token。

在使用 Token 時，應該儘可能把 Token 放在表單中。把敏感操做由 GET 變成 POST，以 form 表單（或者 ajax）的形式提交，避免 token 泄露。