學習筆記之CSRF初級篇

什么是CSRF

CSRF（Cross-siterequestforgery跨站請求偽造，也被稱為“oneclickattack”或者sessionriding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，并且***方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS***相比，CSRF***往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性。

 

Xss與CSRF異同

CSRF與XSS在***手段上有點類似，都是在客戶端執行惡意代碼，有些文章中認為CSRF與XSS的區別在于CSRF不注重于獲取用戶Cookie，筆者認為可能還有區別在于CSRF不僅可以在源站發起***，還可以引導用戶訪問其他危險網站的同時發起***。

XSS全程是跨站腳本***，即***者向某個Web頁面中插入惡意的JavaScript腳本。而當普通用戶訪問時，該惡意腳本自動執行而從盜取用戶的Cookie等信息。對于XSS的防御手段主要就是輸入檢查與輸出檢查，譬如對用戶輸入的文本框內容進行<、>這樣的特殊字符檢查。而輸出檢查則是指對于輸出到網頁的內容進行過濾或者編解碼，譬如使用HTML編碼將<轉義。

CSRF為跨站請求偽造，其與XSS有點類似，不過區別在于CSRF不一定依賴于JavaScript，并且不僅可以在源站發起***，還有可能當用戶訪問惡意網站時引導其訪問原網站。CSRF***是源于WEB的隱式身份驗證機制，WEB的身份驗證機制雖然可以保證一個請求是來自于某個用戶的瀏覽器，但卻無法保證該請求是用戶批準發送的。對于CSRF的防御也分為服務端防御與客戶端防御兩種，服務端防御典型的譬如給某個頁面添加隨機數，使得無法從第三方頁面直接提交。在客戶端防御的話可以利用譬如Firefox提供的一些檢查工具。注意，CSRF并沒有打破同源策略。

 

CSRF的危害

你這可以這么理解CSRF***：***者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至于購買商品，

虛擬貨幣轉賬等等造成的問題包括：個人隱私泄露以及財產安全。

 

 

　　下圖簡單闡述了CSRF***的思想：

從上圖可以看出，要完成一次CSRF***，受害者必須依次完成兩個步驟：

　　1.登錄受信任網站A，并在本地生成Cookie。

　　2.在不登出A的情況下，訪問危險網站B。

　　看到這里，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的***”。是的，確實如此，但你不能保證以下情況不會發生：

1.你不能保證你登錄了一個網站后，不再打開一個tab頁面并訪問另外的網站。

2.你不能保證你關閉瀏覽器了后，你本地的Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認為關閉瀏覽器就等于退出登錄/結束會話了......）

3.上圖中所謂的***網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。同樣也可以是一個惡意的url。

 

SCRF觸發條件

1、被***者的用戶cookies

2、惡意的url或表單

 

CSRF的防御

CSRF的防御可以從服務端和客戶端兩方面著手，防御效果是從服務端著手效果比較好，現在一般的CSRF防御也都在服務端進行。

 

　　1.服務端進行CSRF防御

　　服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。

　　(1).Cookie Hashing(所有表單都包含同一個偽隨機值)：

　　這可能是最簡單的解決方案了，因為***者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗了

<?php
　　　　//構造加密的Cookie信息
　　　　$value = “DefenseSCRF”;
　　　　setcookie(”cookie”, $value,time()+3600);
　　?>
　　

   在表單里增加Hash值，以認證這確實是用戶發送的請求。

　　<?php
　　　　$hash = md5($_COOKIE['cookie']);
　　?>
　　<form method=”POST”action=”transfer.php”>
　　　　<input type=”text”name=”toBankId”>
　　　　<input type=”text” name=”money”>
　　　　<input type=”hidden” name=”hash”value=”<?=$hash;?>”>
　　　　<input type=”submit” name=”submit”value=”Submit”>

　　</form>

　　然后在服務器端進行Hash值驗證

   <?php
　　     if(isset($_POST['check'])) {
     　　      $hash =md5($_COOKIE['cookie']);
         　　 if($_POST['check'] == $hash) {
               　　doJob();
　　          } else {
　　　　　　　　//...
         　　 }
　　     } else {
　　　　　　//...
　　     }
     ?>

　　這個方法目前覺得已經可以杜絕大多數***了，那還有少數由于用戶的Cookie很容易由于網站的XSS漏洞而被盜取，一般的***者看到有需要算Hash值，基本都會放棄了，當然也有些人除外，所以如果需要100%的杜絕，這并不是最好的方法。

　　(2).驗證碼

　　這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，厄....這個方案可以完全解決CSRF，但個人覺得在易用性方面似乎不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。

　　(3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)

　　在實現One-Time Tokens時，需要注意一點：就是“并行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成一個偽隨機值來覆蓋以前的偽隨機值將會發生什么情況：用戶只能成功地提交他最后打開的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

　　以下我的實現:

　　1).先是令牌生成函數(gen_token())：

  <?php
    function gen_token() {
　　　　          $token = md5(uniqid(rand(), true));
         return $token;
    }

   

　　2).然后是Session令牌生成函數(gen_stoken())：  

  <?php
     　　function gen_stoken() {
　　　　　　$pToken = "";
　　　　　　if($_SESSION[STOKEN_NAME]  == $pToken){
　　　　　　　　//沒有值，賦新值
　　　　　　　　$_SESSION[STOKEN_NAME] =gen_token();
　　　　　　}   
　　　　　　else{
　　　　　　　　//繼續使用舊的值
　　　　　　}
     　　}
    ?>

　　3).WEB表單生成隱藏輸入域的函數：　　

<?php
　　    function gen_input() {
     　　     gen_stoken();
　　         echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
         　　     value=\”". $_SESSION[STOKEN_NAME] . “\”> “;
     　　}
    ?>

　　

   4).WEB表單結構： 

  <?php
         session_start();
         include(”functions.php”);
    ?>
    <form method=”POST” action=”transfer.php”>
         <input type=”text” name=”toBankId”>
         <input type=”text” name=”money”>
         <? gen_input(); ?>
         <input type=”submit” name=”submit” value=”Submit”>
    </FORM>

　　5).服務端核對令牌