CSRF 跨站請求偽造 漏洞
0x00 CSRF 漏洞概述
-
跨站請求偽造 (Cross- site request forgery, CSRF）是一種攻擊，它強制終端使用者在當前對其進行身份驗證後的 web 應用程式上執行非本意的操作。CSRF 攻擊的著重點在偽造更改狀態的請求 ，而不是盜取資料 ，因為攻擊者無法檢視對偽造請求的響應。
-
藉助社工的一些幫助（例如通過電子郵件或聊天傳送連結），攻擊者可以誘騙使用者執行攻擊者選擇的操作 。如果受害者是普通使用者 ，則成功的 CSRF 攻擊可以強制使用者執行狀態更改的請求 ，例如轉移資金，更改其電子郵件地址等。如果受害者是管理帳戶 ，CSRF 可能會危及整個 Web 應用程式 。
0x01 CSRF 漏洞原理
- CSRF 是一種 欺騙 受害者提交惡意請求的攻擊。它 繼承了受害者的身份和許可權 ，代表受害者執行 非本意、惡意 的操作。
關鍵點
- 大多數站點，瀏覽器請求自動傳送與站點關聯的所有憑據，例如使用者的會話 cookie，IP 地址，Windows 域憑據等。如果使用者當前已對該站點進行了身份驗證，則該站點將無法區分受害者傳送的偽造請求和受害者傳送的合法請求。
CSRF 攻擊兩個條件
-
登入受信任網站 A，並在本地生成 Cookie 。
-
在不登出 A 的情況下，訪問危險網站 B。
0x02 CSRF 漏洞危害
-
攻擊者盜用了使用者的身份後，以使用者的名義傳送惡意請求
。 -
CSRF 的惡意操作：以使用者名稱義傳送郵件，發訊息，盜取賬號，購買商品 ，虛擬貨幣轉賬 等等
-
造成的問題包括：個人隱私洩露 以及財產安全 問題
0x03 CSRF 漏洞防禦
-
驗證 Referer 欄位 ：如果 Referer 是其他網站 的話，就有可能是 CSRF 攻擊，則拒絕該請求。
-
新增 Token 驗證 ： 可以在 HTTP 請求中以引數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確 ，則認為可能是 CSRF 攻擊而拒絕該請求。
-
二次驗證 ：在轉賬等關鍵操作之前
提供當前使用者的密碼 或者驗證碼 -
使用者養成良好的習慣 ：下要隨意點選連結和圖片、及時退出長時間不使用的已登入賬戶、安裝合適的安全防護軟體
0x04 CSRF 漏洞利用
- GET型別
-
直接GET請求偽裝成短連結
-
利用src屬性發起請求 ，可以利用標籤<script><img><iframe>構造請求後，在寫在html或php檔案中，放在公網伺服器，並將訪問此html或php檔案的url連結偽裝成短連結
- POST型別
-
利用form表單、burp抓包外掛生成，js自動提交，document.getElementById.submit()
-
ajax 非同步請求
<script src="http://code.jquery.com/jquery-latest.js"></script>
<script type="text/javascript">
$.ajax({
url: "http://172.16.12.2/csrfpost/csrf_post_edit.php",
type: "POST",
crossDomain:true, //設定跨域為true
xhrFields: {
withCredentials: true //預設情況下，標準的跨域請求是不會發送cookie的
},
data: {
sex:"girl",
phonenum:"18622222225",
add:"usaaa",
email:"2",
submit:"submit"
}
//dataType: 'json' // tell jQuery not to process the data // tell jQuery not to set contentType
});
</script>
0x05 CSRF VS XSS
-
原理角度
-
XSS是將惡意的程式碼插入到html頁 面中，當用戶瀏覽頁面時，插入的html程式碼會被執行，從而達到最終目的,
-
CSRF是一種欺騙受害者 提交惡意請求的攻擊。代表受害者執行非本意、惡意 的操作
-
其他角度
-
CSRF比XSS漏洞危害更高，相對XSS而言較難防禦。
-
CSRF可以做到的事情，XSS都可以做到。
-
XSS有侷限性，而CSRF沒有侷限性。
-
XSS是利用合法使用者 獲取其資訊，而CSRF是偽造成合法使用者 發起請求
0x06 同源策略
什麼是源
- 通常理解的源，就是指的是URL中的協議、域名和埠的組合
同源的定義
-
如果兩個頁面的協議，埠 (如果有指定)和域名 都相同 ，則兩個頁面具有相同的源
-
舉例：相對http://a.xyz.com/dir/page.html同源檢測的示例：
同源策略是什麼
-
概述
-
同源策略是瀏覽器的一個安全功能 ，不同源的 客戶端指令碼在沒有明確授權 的情況下，不能讀寫對方資源。
-
同源策略限制了從同—個源載入的文件或指令碼如何與來自另一個源的資源進行互動
-
這是一個用於隔離潛在惡意檔案 的重要安全機制。
-
受約束物件：DOM、 Cookie、第三方外掛 以及 XmlHttpRequest 都受到同源策略的約束
-
-
不受約束物件
-
頁面中的連結 ，重定向 以及表單 提交是不會受到同源策略限制的。
-
跨域資源的引入 是可以的。但是js不能讀寫載入的內容。如嵌入到頁面中的<script>,<img>,<link>,<iframe>等
-
帶src屬性的標籤。
-
-
非同源受到的限制
-
Cookie、 LocalStorage和 IndexDB無法讀取
-
DOM無法獲得
-
AJAX請求不能傳送
0x07 跨域問題
跨域的概念
-
受前面所講的瀏覽器同源策略的影響，不同源的指令碼不能操作其他源下面的物件。想要操作另—個源下的物件是就需要跨域
-
簡單的說，我們把不同域 之間請求資料 的操作，稱為跨域
跨域的方法
-
document.domain跨域
-
說明：若兩個頁面一級域名相同，只是二級域名不同 ，那麼瀏覽器可以通過設定 document.domain 來共享 Cookie
-
特點
-
只能在父域名 與子域名 之間使用
-
存在安全性問題 ，當一個站點被攻擊後，另一個站點會引起安全漏洞
-
只適用於 Cookie 和 iframe 視窗。
-
舉例：
- 網頁A：[http://a.ichunqiu.com/index.html]
- 網頁B：[http://b.ichunqiu.com/index.html]
- 將document.domain設定成相同，如：document.domain='[chunqiu.com]'，就實現以上任意兩個頁面之間的通訊了
-
JSONP跨域
-
說眀：利用<script>的src不受同源策略約束 實現跨域獲取資料。
-
存在問題：
-
存在安全性問題 ，需要網站雙方商議基礎 token的身份驗證
-
只能是GET ，不能POST。
-
可能被注入惡意程式碼，篡改頁面內容，可以採用字串過濾來規避此問題。
-
-
舉例:
a.com/jsonp.html想得到b.com/main.js中的資料。在a.com的jsonp.html裡建立一個回撥函式 xxx，動態新增