XSS攻擊
跨網站腳本（Cross-site scripting，通常簡稱爲XSS或跨站腳本或跨站腳本攻擊）是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。 它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了HTML以及用戶端腳本語言。XSS 利用的是用戶對指定網站的信任。
XSS攻擊的類型
XSS 攻擊可以分成兩種，反射性 XSS / 存儲型 XSS。前者是需要用戶觸發的 XSS， 針對當前用戶的攻擊行爲。而後者存儲型 XSS 則更爲嚴重，一旦攻擊代碼被保存， 所有訪問被攻擊的頁面，都會觸發用戶被攻擊行爲。
攻擊手段和目的
盜用cookie，獲取敏感信息。
利用植入Flash，通過crossdomain權限設置進一步獲取更高權限；或者利用Java等得到類似的操作。
利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊）用戶的身份執行一些管理動作，或執行一些一般的如發微博、加好友、發私信等操作。
利用可被攻擊的域受到其他域信任的特點，以受信任來源的身份請求一些平時不允許的操作，如進行不當的投票活動。
在訪問量極大的一些頁面上的XSS可以攻擊一些小型網站，實現DDoS攻擊的效果。
防禦措施：
過濾特殊字符，在許多語言中可以直接使用工具類進行過濾。
使用 HTTP 頭指定類型
CSRF攻擊
跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站並執行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。由於瀏覽器曾經認證過，所以被訪問的網站會認爲是真正的用戶操作而去執行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發出的。CSRF 利用的是網站對用戶網頁瀏覽器的信任。
攻擊示例
假如銀行網站examplebank用以執行轉賬操作的URL地址如下：
惡意攻擊者可以在自己的網站A放置如下代碼：
如果有賬戶名爲Alice的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那麼她就會損失1000資金。
這種惡意的網址可以有很多種形式，藏身於網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味着如果服務器端沒有合適的防禦措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。
透過例子能夠看出，攻擊者並不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執行操作。
防禦措施：
①檢查Referer字段
HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪個地址。在處理敏感數據請求時，通常來說，Referer字段應和請求的地址位於同一域名下。以上文銀行操作爲例，Referer字段地址通常應該是轉賬按鈕所在的網頁地址，應該也位於www.examplebank.com之下。而如果是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，不會位於www.examplebank.com之下，這時候服務器就能識別出惡意的訪問。
這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其侷限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。並且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。
添加校驗token
②由於CSRF的本質在於攻擊者欺騙用戶去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，並且攻擊者無法僞造的數據作爲校驗，那麼攻擊者就無法再執行CSRF攻擊。這種數據通常是表單中的一個數據項。服務器將其生成並附加在表單中，其內容是一個僞亂數。當客戶端通過表單提交請求時，這個僞亂數也一併提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到並傳回這個僞亂數，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個僞亂數的值，服務器端就會因爲校驗token的值爲空或者錯誤，拒絕這個可疑請求。
使用JWT進行鑑權
關於JWT如何生成使用請查看http://www.cnblogs.com/xiekeli/p/5607107.html
下面我們從一個實例來看如何運用JWT機制實現認證：
登錄
第一次認證：第一次登錄，用戶從瀏覽器輸入用戶名/密碼，提交後到服務器的登錄處理的Action層（Login Action）；
Login Action調用認證服務進行用戶名密碼認證，如果認證通過，Login Action層調用用戶信息服務獲取用戶信息（包括完整的用戶信息及對應權限信息）；
返回用戶信息後，Login Action從配置文件中獲取Token簽名生成的祕鑰信息，進行Token的生成；
生成Token的過程中可以調用第三方的JWT Lib生成簽名後的JWT數據；
完成JWT數據簽名後，將其設置到COOKIE對象中，並重定向到首頁，完成登錄過程；
請求認證
基於Token的認證機制會在每一次請求中都帶上完成簽名的Token信息，這個Token信息可能在COOKIE
中，也可能在HTTP的Authorization頭中；
客戶端（APP客戶端或瀏覽器）通過GET或POST請求訪問資源（頁面或調用API）；
認證服務作爲一個Middleware HOOK 對請求進行攔截，首先在cookie中查找Token信息，如果沒有找到，則在HTTP Authorization Head中查找；
如果找到Token信息，則根據配置文件中的簽名加密祕鑰，調用JWT Lib對Token信息進行解密和解碼；
完成解碼並驗證簽名通過後，對Token中的exp、nbf、aud等信息進行驗證；
全部通過後，根據獲取的用戶的角色權限信息，進行對請求的資源的權限邏輯判斷；
如果權限邏輯判斷通過則通過Response對象返回；否則則返回HTTP 401；
參考：