XSS/XSRF

1、XSS

1.1 xss的含義

跨站腳本攻擊(Cross Site Scripting)，爲不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫爲XSS。惡意攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

XSS攻擊一般指的是經過利用網頁開發時留下的漏洞，經過巧妙的方法注入惡意指令代碼到網頁，使用戶加載並執行攻擊者惡意製造的網頁程序。這些惡意網頁程序一般是JavaScript，但實際上也能夠包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻擊成功後，攻擊者可能獲得更高的權限（如執行一些操做）、私密網頁內容、會話和cookie等各類內容。

爲了防止這些攻擊，您應該始終檢查用戶發送到您的服務器的數據（若是須要顯示它），請儘可能不顯示用戶提供的HTML內容。 Intead，您應該處理用戶提供的數據，以便不會逐字顯示。幾乎全部市場上的框架都實現了一個最小的過濾器，從任何用戶發送的數據中刪除HTML <script>，<iframe>和<object>元素。這有助於減輕風險，但不必定根除它。

1.2 經常使用的XSS攻擊手段和目的有：

• 盜用cookie，獲取敏感信息。
• 利用植入Flash，經過crossdomain權限設置進一步獲取更高權限；或者利用Java等獲得相似的操做。
• 利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊）用戶的身份執行一些管理動做，或執行一些通常的如發微博、加好友、發私信等操做。
• 利用可被攻擊的域受到其餘域信任的特色，以受信任來源的身份請求一些平時不容許的操做，如進行不當的投票活動。
• 在訪問量極大的一些頁面上的XSS能夠攻擊一些小型網站，實現DDoS攻擊的效果。

1.3 漏洞的防護和利用

1.31 過濾特殊字符
避免XSS的方法之一主要是將用戶所提供的內容進行過濾，許多語言都有提供對HTML的過濾：
PHP的htmlentities()或是htmlspecialchars()。
Python的cgi.escape()。
ASP的Server.HTMLEncode()。
ASP.NET的Server.HtmlEncode()或功能更強的Microsoft Anti-Cross Site Scripting Library
Java的xssprotect (Open Source Library)。
Node.js的node-validator。

1.32 使用HTTP頭指定類型
不少時候可使用HTTP頭指定內容的類型，使得輸出的內容避免被做爲HTML解析。如在PHP語言中使用如下代碼：
<?php
   header('Content-Type: text/javascript; charset=utf-8');
?>
便可強行指定輸出內容爲文本/JavaScript腳本（順便指定了內容編碼），而非能夠引起攻擊的HTML。

1.33 用戶方面
包括Internet Explorer、Mozilla Firefox在內的大多數瀏覽器皆有關閉JavaScript的選項，但關閉功能並不是是最好的方法，由於許多網站都須要使用JavaScript語言才能正常運做。一般來講，一個常常有安全更新推出的瀏覽器，在使用上會比好久都沒有更新的瀏覽器更爲安全。

 

2、 XSRF

2.1 XSRF的含義

跨站請求僞造（英語：Cross-site request forgery），也被稱爲 one-click attack 或者 session riding，一般縮寫爲 CSRF 或者 XSRF， 是一種挾制用戶在當前已登陸的Web應用程序上執行非本意的操做的攻擊方法。

跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。

跨站請求攻擊，簡單地說，是攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個本身曾經認證過的網站並執行一些操做（如發郵件，發消息，甚至財產操做如轉帳和購買商品）。因爲瀏覽器曾經認證過，因此被訪問的網站會認爲是真正的用戶操做而去執行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的。

2.2 防護措施

2.21 檢查Referer字段

HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪一個地址。在處理敏感數據請求時，一般來講，Referer字段應和請求的地址位於同一域名下。以上文銀行操做爲例，Referer字段地址一般應該是轉帳按鈕所在的網頁地址，應該也位於www.examplebank.com之下。而若是是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，不會位於www.examplebank.com之下，這時候服務器就能識別出惡意的訪問。
這種辦法簡單易行，工做量低，僅須要在關鍵訪問處增長一步校驗。但這種辦法也有其侷限性，因其徹底依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並沒有法保證來訪的瀏覽器的具體實現，亦沒法保證瀏覽器沒有安全漏洞影響到此字段。而且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。
2.22 添加校驗token
因爲CSRF的本質在於攻擊者欺騙用戶去訪問本身設置的地址，因此若是要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，而且攻擊者沒法僞造的數據做爲校驗，那麼攻擊者就沒法再執行CSRF攻擊。這種數據一般是表單中的一個數據項。服務器將其生成並附加在表單中，其內容是一個僞亂數。當客戶端經過表單提交請求時，這個僞亂數也一併提交上去以供校驗。正常的訪問時，客戶端瀏覽器可以正確獲得並傳回這個僞亂數，而經過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個僞亂數的值，服務器端就會由於校驗token的值爲空或者錯誤，拒絕這個可疑請求。

參考資料：

https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%B6%B2%E7%AB%99%E6%8C%87%E4%BB%A4%E7%A2%BC

https://zh.wikipedia.org/wiki/%E8%B7%A8%E7%AB%99%E8%AF%B7%E6%B1%82%E4%BC%AA%E9%80%A0