客戶端腳本安全

參考文獻：白帽子講Web安全 （亞馬遜購買地址：連接）

前言

瀏覽器做爲客戶端，也是咱們用戶上網的直接入口，因此瀏覽器的安全就是用戶安全的第一道屏障。

同源策略

同源策略是瀏覽器最核心最基本的安全功能。它限制了來自不一樣源的「document」或腳本，對當前「document」讀取或者設置某些屬性。所謂同源是指host（域名或者ip地址）、子域名、端口和協議相同。不一樣源的客戶端腳本(javascript、ActionScript)在沒明確受權的狀況下，不能讀寫對方的資源。
但須要注意的是，對於當前頁面來講，頁面存放js文件的域並不重要，重要的是加載js的頁面所在域是什麼。例如：在a.com的頁面下經過<script src='http://b.com/b.js'></script>獲取了b.com域中的資源，可是因爲b.js是運行在a.com的頁面中，所以對於當前頁面來說，b.js的域就是a.com。
在瀏覽器中，<script>、<img>、<iframe>、<link>等標籤均可以跨域加載資源，而不受同源策略的限制，這些帶src屬性的標籤每次加載時，實際上時由瀏覽器發起了一次get請求，經過src屬性加載的資源，瀏覽器限制了javascript的權限，使其不能讀、寫返回的內容。因爲這個漏洞可以跨域讀取頁面內容，所以繞過了同源策略，成爲一個跨域漏洞。

跨站腳本攻擊（XSS）

xss（cross site script），是指經過「html注入」篡改了網頁，插入了惡意腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊
xss根據不一樣效果分爲如下幾種類型：

• 反射型xss（非持久型xss）：簡單地把用戶輸入的數據「反射」給瀏覽器，也就是說，黑客須要誘使用戶點擊一個惡意連接才能攻擊成功。

• 存儲型xss（持久型xss）：存儲型xss會把用戶輸入數據「存儲」在服務器端，因此這類攻擊具備很強的穩定性。

• 基於DOM的xss：這類xss效果上是反射型xss，可是造成緣由是經過修改頁面的DOM節點來達到攻擊目的的。

－－－－－針對上面所說的三種類型舉兩個栗子來直觀理解一下。－－－－－
栗子1:一個頁面直接把用戶輸入的參數輸出到頁面上，例如咱們在網站搜索一本名字叫《白帽子講web安全》的書，若是沒有搜到這本書，那麼網站會提示：沒有找到白帽子講web安全這本書，查看頁面源代碼，能夠看到：<div>沒有找到白帽子講web安全這本書</div>，那麼此時若是搜索的內容變爲<script>alert(/xss)</script>，再次提交搜索以後就會發現咱們提交的內容被瀏覽器執行了。即用戶輸入的script腳本被寫入到頁面中。這個栗子裏面用戶寫入的內容由於只有當前用戶看到，因此不會有特別大的危害，那麼若是是這個用戶寫入的內容能夠被其餘用戶看到的場景，當寫入一些惡意代碼的話危害就很大了。
栗子2:黑客寫了一篇包含有惡意js代碼的博客文章，文章發表以後，全部訪問該博客的用戶都會在他們的瀏覽器中執行這段惡意代碼。黑客這裏把惡意腳本保存到服務器端，因此這種xss攻擊就叫作存儲型xss。
－－－－－栗子結束－－－－－

跨站請求僞造（CSRF）

csrf（cross site request forgery），是指黑客僞形成合法用戶發起請求而形成的一種攻擊。

－－－－－舉一個栗子－－－－－
某博客網站，用戶小白在登錄本身的帳號後能夠管理本身的文章，其中有個操做是刪除某篇文章。刪除的操做是請求url：http://blog.balabala.com/manager/entry.do?m=delete&id=12345 其中12345是這篇文章的id號。接下來咱們就用這個url存在的csrf漏洞來刪除這篇文章。
攻擊者首先在本身的域內構造一個頁面，http://www.a.com/csrf.html，內容爲：
<img src="http://blog.balabala.com/manager/entry.do?m=delete&id=12345" />,而後攻擊者誘使目標用戶也就是小白同窗訪問這個頁面，他看到一張沒法顯示的圖片，可是在這這圖片的背後是csrf攻擊的巨大陰謀。
－－－－－栗子吃完了－－－－－

CSRF防護

面對csrf攻擊，用戶真的是防不勝防，那麼做爲網站建設者有什麼方法能夠防護這種攻擊呢呢。下面列幾種比較經常使用的方法。

1. 驗證碼
   驗證碼被認爲是對抗csrf攻擊最簡潔有效的防護方法。csrf攻擊每每是在用戶不知情的狀況下構造了網絡請求，而驗證碼則是強制用戶與應用進行交互來完成最終的請求。可是出於對用戶體驗的考慮，網站不會在全部的操做上都加上驗證碼，因此這隻能做爲一種輔助手段，而不是最終的解決方案。

2. referer check
   referer是http請求header中的一個參數，容許客戶端指定請求url的源資源地址。因此referer check能夠用於檢查請求是否來自合法的「源」。常見的互聯網應用，頁面與頁面之間都具備必定的邏輯關係，這使得每一個正常清請求的referer都具備必定的規律。舉個栗子，好比進行發表博客的操做，在提交發表博客的表單時，referer的值必然是編輯博客所載的頁面，若是不是這個頁面甚至不是這個網站的域那麼極有多是csrf攻擊。這種防護手段的缺陷在於，服務器不是任什麼時候候都能取得referer，因此這隻能做爲一種監控手段而沒法做爲主要的防護手段。

3. Anti CSRF Token
   如今業界針對csrf防護的一致作法是使用token。csrf可以成功的本質緣由是攻擊者能夠猜出請求中的全部參數和參數值，因此才能成功地構造一個僞造的請求。因此直觀的解決方案是：把參數加密，或者使用一些隨機數從而讓攻擊者沒法猜想到參數值，目前業界通用的方案就是使用AntiCSRFToken。那麼針對咱們開頭所說的那個栗子?，保持原有參數不變，新增一個參數token，這個token的值是隨機的，不可預測：http://blog.balabala.com/manager/entry.do?m=delete&id=12345&token=[random(seed)] 。在實際應用中，token同時放在表單和session（或者cookie）中，在提交請求的時候服務器只須要驗證表單中的token和用戶session（或者cookie）中的token是否一致從而判斷這個請求是否合法。