欧美日韩有精品一区二区三区

一.CSRF是什么？

　　CSRF（Cross-site request forgery），中文名稱(chēng)：跨站請求偽造，也被稱(chēng)為：one click attack/session riding，縮寫(xiě)為：CSRF/XSRF。

二.CSRF可以做什么？

　　你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號，甚至于購買(mǎi)商品，虛擬貨幣轉賬......造成的問(wèn)題包括：個(gè)人隱私泄露以及財產(chǎn)安全。

三.CSRF漏洞現狀

　　CSRF這種攻擊方式在2000年已經(jīng)被國外的安全人員提出，但在國內，直到06年才開(kāi)始被關(guān)注，08年，國內外的多個(gè)大型社區和交互網(wǎng)站分別爆出CSRF漏洞，如：NYTimes.com（紐約時(shí)報）、Metafilter（一個(gè)大型的BLOG網(wǎng)站），YouTube和百度HI......而現在，互聯(lián)網(wǎng)上的許多站點(diǎn)仍對此毫無(wú)防備，以至于安全業(yè)界稱(chēng)CSRF為“沉睡的巨人”。

四.CSRF的原理

　　下圖簡(jiǎn)單闡述了CSRF攻擊的思想：

　　從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：

　　1.登錄受信任網(wǎng)站A，并在本地生成Cookie。

　　2.在不登出A的情況下，訪(fǎng)問(wèn)危險網(wǎng)站B。

　　看到這里，你也許會(huì )說(shuō)：“如果我不滿(mǎn)足以上兩個(gè)條件中的一個(gè)，我就不會(huì )受到CSRF的攻擊”。是的，確實(shí)如此，但你不能保證以下情況不會(huì )發(fā)生：

　　1.你不能保證你登錄了一個(gè)網(wǎng)站后，不再打開(kāi)一個(gè)tab頁(yè)面并訪(fǎng)問(wèn)另外的網(wǎng)站。

　　2.你不能保證你關(guān)閉瀏覽器了后，你本地的Cookie立刻過(guò)期，你上次的會(huì )話(huà)已經(jīng)結束。（事實(shí)上，關(guān)閉瀏覽器不能結束一個(gè)會(huì )話(huà)，但大多數人都會(huì )錯誤的認為關(guān)閉瀏覽器就等于退出登錄/結束會(huì )話(huà)了......）

　　3.上圖中所謂的攻擊網(wǎng)站，可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪(fǎng)問(wèn)的網(wǎng)站。

　　上面大概地講了一下CSRF攻擊的思想，下面我將用幾個(gè)例子詳細說(shuō)說(shuō)具體的CSRF攻擊，這里我以一個(gè)銀行轉賬的操作作為例子（僅僅是例子，真實(shí)的銀行網(wǎng)站沒(méi)這么傻:>）

　　示例1：

　　銀行網(wǎng)站A，它以GET請求來(lái)完成銀行轉賬的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危險網(wǎng)站B，它里面有一段HTML的代碼如下：

　　首先，你登錄了銀行網(wǎng)站A，然后訪(fǎng)問(wèn)危險網(wǎng)站B，噢，這時(shí)你會(huì )發(fā)現你的銀行賬戶(hù)少了1000塊......

　　為什么會(huì )這樣呢？原因是銀行網(wǎng)站A違反了HTTP規范，使用GET請求更新資源。在訪(fǎng)問(wèn)危險網(wǎng)站B的之前，你已經(jīng)登錄了銀行網(wǎng)站A，而B(niǎo)中的<img>以GET的方式請求第三方資源（這里的第三方就是指銀行網(wǎng)站了，原本這是一個(gè)合法的請求，但這里被不法分子利用了），所以你的瀏覽器會(huì )帶上你的銀行網(wǎng)站A的Cookie發(fā)出Get請求，去獲取資源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，結果銀行網(wǎng)站服務(wù)器收到請求后，認為這是一個(gè)更新資源操作（轉賬操作），所以就立刻進(jìn)行轉賬操作......

　　示例2：

　　為了杜絕上面的問(wèn)題，銀行決定改用POST請求完成轉賬操作。

　　銀行網(wǎng)站A的WEB表單如下：　　

　　<form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" /></p>
　　　　<p>Money: <input type="text" name="money" /></p>
　　　　<p><input type="submit" value="Transfer" /></p>
　　</form>

　　后臺處理頁(yè)面Transfer.php如下：

　　<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
　　?>

　　危險網(wǎng)站B，仍然只是包含那句HTML代碼：

　　和示例1中的操作一樣，你首先登錄了銀行網(wǎng)站A，然后訪(fǎng)問(wèn)危險網(wǎng)站B，結果.....和示例1一樣，你再次沒(méi)了1000塊～T_T，這次事故的原因是：銀行后臺使用了$_REQUEST去獲取請求的數據，而$_REQUEST既可以獲取GET請求的數據，也可以獲取POST請求的數據，這就造成了在后臺處理程序無(wú)法區分這到底是GET請求的數據還是POST請求的數據。在PHP中，可以使用$_GET和$_POST分別獲取GET請求和POST請求的數據。在JAVA中，用于獲取請求數據request一樣存在不能區分GET請求數據和POST數據的問(wèn)題。

　　示例3：

　　經(jīng)過(guò)前面2個(gè)慘痛的教訓，銀行決定把獲取請求數據的方法也改了，改用$_POST，只獲取POST請求的數據，后臺處理頁(yè)面Transfer.php代碼如下：

　　<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

　　然而，危險網(wǎng)站B與時(shí)俱進(jìn)，它改了一下代碼：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
　　　　 iframe = document.frames["steal"];
　　　　 iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>

　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用戶(hù)仍是繼續上面的操作，很不幸，結果將會(huì )是再次不見(jiàn)1000塊......因為這里危險網(wǎng)站B暗地里發(fā)送了POST請求到銀行!

　　總結一下上面3個(gè)例子，CSRF主要的攻擊模式基本上是以上的3種，其中以第1,2種最為嚴重，因為觸發(fā)條件很簡(jiǎn)單，一個(gè)<img>就可以了，而第3種比較麻煩，需要使用JavaScript，所以使用的機會(huì )會(huì )比前面的少很多，但無(wú)論是哪種情況，只要觸發(fā)了CSRF攻擊，后果都有可能很?chē)乐亍?/p>

　　理解上面的3種攻擊模式，其實(shí)可以看出，CSRF攻擊是源于WEB的隱式身份驗證機制！WEB的身份驗證機制雖然可以保證一個(gè)請求是來(lái)自于某個(gè)用戶(hù)的瀏覽器，但卻無(wú)法保證該請求是用戶(hù)批準發(fā)送的！

五.CSRF的防御

　　我總結了一下看到的資料，CSRF的防御可以從服務(wù)端和客戶(hù)端兩方面著(zhù)手，防御效果是從服務(wù)端著(zhù)手效果比較好，現在一般的CSRF防御也都在服務(wù)端進(jìn)行。

　　1.服務(wù)端進(jìn)行CSRF防御

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

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

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

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

　　在表單里增加Hash值，以認證這確實(shí)是用戶(hù)發(fā)送的請求。

　　<?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>

　　然后在服務(wù)器端進(jìn)行Hash值驗證

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

　　這個(gè)方法個(gè)人覺(jué)得已經(jīng)可以杜絕99%的CSRF攻擊了，那還有1%呢....由于用戶(hù)的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會(huì )放棄了，某些除外，所以如果需要100%的杜絕，這個(gè)不是最好的方法。
　　(2).驗證碼

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

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

　　在實(shí)現One-TimeTokens時(shí)，需要注意一點(diǎn)：就是“并行會(huì )話(huà)的兼容”。如果用戶(hù)在一個(gè)站點(diǎn)上同時(shí)打開(kāi)了兩個(gè)不同的表單，CSRF保護措施不應該影響到他對任何表單的提交?？紤]一下如果每次表單被裝入時(shí)站點(diǎn)生成一個(gè)偽隨機值來(lái)覆蓋以前的偽隨機值將會(huì )發(fā)生什么情況：用戶(hù)只能成功地提交他最后打開(kāi)的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會(huì )影響選項卡式的瀏覽或者利用多個(gè)瀏覽器窗口瀏覽一個(gè)站點(diǎn)。

　　以下我的實(shí)現:

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

     <?php
     function gen_token() {
　　　　//這里我是貪方便，實(shí)際上單使用Rand()得出的隨機數作為令牌，也是不安全的。
　　　　//這個(gè)可以參考我寫(xiě)的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){
　　　　　　　　//沒(méi)有值，賦新值
　　　　　　　　$_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).服務(wù)端核對令牌：

　　這個(gè)很簡(jiǎn)單，這里就不再啰嗦了。

　　上面這個(gè)其實(shí)不完全符合“并行會(huì )話(huà)的兼容”的規則，大家可以在此基礎上修改。

　　其實(shí)還有很多想寫(xiě)，無(wú)奈精力有限，暫且打住，日后補充，如果錯漏，請指出:>

　　PS：今天下午寫(xiě)這篇文檔的時(shí)候FF崩潰了一次，寫(xiě)了一半文章的全沒(méi)了，郁悶好久T_T.......

　　轉載請說(shuō)明出處，謝謝[hyddd(http://www.cnblogs.com/hyddd/)]

六.參考文獻

[1].Preventing CSRF

[2].Security Corner: Cross-Site Request Forgeries

[3].《深入解析跨站請求偽造漏洞：原理剖析》

[4].《Web安全測試之跨站請求偽造（CSRF）》

[5].《深入解析跨站請求偽造漏洞：實(shí)例講解》

[6].http://baike.baidu.com/view/1609487.htm

本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請點(diǎn)擊舉報。

欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久