- 1、什麼是CSRF
- 2、CSRF的攻擊過程和原理
- 3、CSRF的型別有哪些
- 4、CSRF的防禦
- 5、CSRF與XSS有何不同
- 6、沒有防禦的CSRF
1、什麼是CSRF
跨站請求偽造（Cross-site request forgery），CSRF是指利用受害者尚未失效的身份認證資訊（登入狀態中的Cookie等），誘騙受害者點選惡意連結，或者訪問包含攻擊程式碼的頁面，在受害者不知情的情況下以受害者的身份向伺服器傳送請求，從而完成非法操作。
可以這樣說，攻擊者盜用了你的身份，以你的名義傳送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作。
在伺服器看來，所有請求都是合法正常的。
2、CSRF的攻擊過程和原理
攻擊過程大致如下：
-
使用者開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A。
-
在使用者資訊透過驗證後，網站A產生cookie資訊並返回給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A。
-
使用者未退出網站A之前，在同一瀏覽器中，開啟一個另一個頁面訪問網站B。
-
B網站收到使用者請求後返回一些訪問A網站的惡意程式碼。
-
瀏覽器在接收到這些惡意程式碼後，根據網站B的請求，在使用者不知情的情況下攜帶使用者的cookie資訊，向網站A發出請求。
-
網站A並不知道該請求其實是由網站B發起的，所以會根據使用者的cookie資訊以使用者的許可權處理該請求，導致來自網站B的惡意程式碼被執行。
CSRF產生的條件：
-
使用者已經登入了網站A，並且在本地瀏覽器記錄了cookie。
-
使用者在沒有退出網站A的情況下（cookie生效的情況下）在同一瀏覽器又訪問了攻擊者提供的引誘網站B（攻擊者構造訪問網站A的URL）。
需要精心構造操作網站A的資料包，可利用CSRFTester構造匯出。
-
網站A沒有做任何的CSRF防禦。
CSRF攻擊是攻擊者利用受害者的cookie騙取伺服器的信任，攻擊者並不能拿到cookie，也看不到cookie的內容。
攻擊者所能做的只是給伺服器傳送請求，以執行請求中的命令，在伺服器端直接改變資料的值，而非竊取伺服器中的資料。
根本原因：Web的身份驗證機制雖然可以保證某個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者知曉並允許傳送的。
3、CSRF的型別有哪些
CSRF的利用必須要對操作產生的資料包完全瞭解，以便構造完全符合要求的資料包。
GET型別
誘使使用者訪問構造的GET請求的惡意URL。
正常轉賬URL：http://bank/transfer?amount=10000&for=bob
偽造的轉賬URL：http://bank/transfer?amount=10000&for=hacker
POST型別
誘導使用者跳轉到駭客網站，網站的HTML中有一個自動提交的隱藏表單，只要使用者開啟頁面，就會發起轉賬請求。
<form action="http://bank/transfer" method=POST>
<input type="hidden" name="account" value="user" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
其他
在受害網站的評論區放置一個a標籤，點選跳轉時發起偽造請求。
<a href="http://bank/transfer?amount=10000&for=hacker" taget="_blank">大八卦<a/>
在受害網站的評論區發表偽裝的圖片，實際是一個惡意請求。
4、CSRF的防禦
CSRF安全問題黑盒怎麼判斷：
-
看頁面來源檢查 HTTP Referer 欄位
-
看看有無憑據是否存在 Token驗證
-
看關鍵操作有無驗證 驗證碼
防禦措施：
1 驗證 HTTP Referer 欄位
在HTTP頭中有一個欄位 Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站。（同源策略）
但是在某些情況下 Referer 欄位是可以被修改的。
2 在請求地址中新增 token 並驗證
在HTTP請求中以引數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。
抵禦CSRF，關鍵在於在請求中放入駭客所不能偽造的資訊，並且該資訊不存在於 cookie 之中。
3 在 HTTP 頭中自定義屬性並驗證
這種方法也是使用token並進行驗證，和上一種方法不同的是，這裡並不是把token以引數的形式置於HTTP請求之中，而是把它放到HTTP頭中自定義的屬性裡。
csrf_token 的位置以及原理和繞過？
CSRF token 通常是一個隨機生成的字串，被包含在請求中，伺服器會驗證該 Token 的有效性，以確保請求來源合法。
1、在表單中，可以作為隱藏欄位嵌入在表單中
2、在請求頭中， 可以在請求頭中透過自定義的 Header 欄位傳送
3、在URL引數中，也可以作為URL引數傳送，不過這種方式相對不安全
5、CSRF與XSS有何不同
CSRF和XSS它們的主要區別在於攻擊的方式和目標：
攻擊方式：
-
CSRF 是透過利用使用者當前已經透過身份驗證的會話來執行未經授權的操作，攻擊的範圍有限，僅限於使用者可以執行的操作。
-
XSS 是透過注入惡意指令碼程式碼到目標網頁中，然後這些程式碼會在使用者瀏覽器中執行，攻擊的影響範圍更直接，它可以直接影響到網站的內容和使用者的瀏覽器。
攻擊目標：
-
CSRF 目標是利用受害者的身份來執行未經授權的操作，誘導受害者使用者執行他們不打算執行的操作，例如更改密碼、傳送惡意請求等。
-
XSS 目標是在受害者的瀏覽器中執行任意js程式碼，從而竊取使用者資訊、篡改網頁內容等。
通常XSS漏洞比CSRF漏洞的危害更加嚴重：
CSRF被認為是一種“單向”漏洞，即攻擊者可以誘導受害者發出HTTP請求，但他們無法獲取該請求的響應；而XSS是一種“雙向的”，因為攻擊者注入的指令碼可以發出任意請求，讀取響應，並將資料傳送到攻擊者指定的地址。
6、沒有防禦的CSRF
地址：All labs | Web Security Academy (portswigger.net)
CSRF vulnerability with no defenses
題目的目標是利用CSRF漏洞更改受害者的電子郵件地址。
首先登入到給定的受害者使用者wiener:peter的更改郵箱介面。
站在攻擊者視角，我們需要做的就是以受害者的身份去更改他的郵箱，使用Burp攔截更改郵箱的請求。
該請求依賴於會話cookie來識別帳戶，接下來要做的就是構造一個可以提交更改郵箱的請求頁面，傳送給受害者。Burp有自動生成指令碼的功能，右鍵Generate CSRF PoC，Burp會生成一個html表單，script部分會自動提交表單。
去到 exploit server 複製生成的html到body，點選 View exploit 檢視漏洞，最後 Deliver to victim，傳送給受害者。
站在受害者視角，瀏覽器會出現一閃而過的的html頁面，這是因為這個頁面是自動提交的。可以透過開發者工具看到這次的請求，請求地址為更改郵箱的地址。
由於當前受害者沒有退出賬戶，所以請求攜帶的session是有效會的，繞過了身份驗證，以受害者的身份傳送請求。
當受害者在看到這個偽造頁面時就被攻擊了，郵箱在受害者不知情的情況下被修改。
