CSRF
現在的網站都有利用CSRF令牌來防止CSRF，就是在請求包的字段加一個csrf的值，防止csrf，要想利用該漏洞，要和xss組合起來，利用xss獲得該csrf值，在構造的請求中将csrf值加進去，就可以繞過csrf防禦，利用該漏洞。
該漏洞與xss的差別：xss是通過執行惡意腳本，擷取到使用者的cookie等資訊，再利用cookie等資訊進行繞過登入限制，做一些使用者可以做的事。
而csrf是僞造請求，讓使用者自己執行攻擊者僞造的請求，這個過程是使用者自己完成的。
漏洞原理
跨站請求僞造，攻擊者僞造一個請求（通常是一個惡意連結）發送給使用者，使用者在登入的情況下點選該連結，伺服器就會以使用者的身份去執行攻擊者僞造的這個請求，進而造成攻擊。
漏洞危害
1. 修改使用者資訊：修改郵箱，更改密碼、轉賬等。
如果修改的資訊是GET方式送出的，我們就直接将修改資訊的url發送給使用者，使用者登入情況下點選該連結，就把他的資訊修改為我們url中的值了。
如果是POST傳參，那我們就需要搭建一個公網伺服器，僞造一個自動送出的修改使用者資訊的表單，同樣發送給使用者一個連結，讓使用者在登入存在漏洞網站的情況下通路我們構造的這個表單，進而修改使用者資訊。
防禦繞過
1. 切換請求方式繞過CSRF令牌驗證：
某些應用程式隻在POST請求中驗證CSRF令牌，是以我們将請求方法改為GET，就可以繞過CSRF令牌驗證。
抓包，利用burp的 Change request method，來将請求改為GET方式。
再利用CSRF poc生成器生成一個自動送出腳本代碼的poc。
2. 令牌存在即驗證：
我們可以直接将CSRF令牌參數删除，看能否繞過，因為有的應用程式隻有令牌存在時進行驗證，如果不存在令牌，則不驗證。
3. 令牌未綁定到使用者會話繞過：
應用程式沒有将CSRF令牌與使用者會話進行綁定，隻是在他的令牌池中進行驗證，隻要請求中的令牌存在于令牌 池中，則通過驗證。攻擊者就可以使用自己的賬戶登入，拿到一個有效令牌，然後在攻擊者将該令牌提供給正常使用者，就會繞過令牌驗證，造成攻擊。
4. 令牌未綁定到會話cookie:
雖然令牌綁定了cookie，但未将令牌綁定到用于跟蹤會話的cookie上。當應用程式使用兩個不同的架構時，很容易發生這種情況。一個cookie用于會話處理，一個用于CSRF保護，他倆沒有內建在一起。
漏洞利用
利用burp 的CSRF poc生成器生成poc。再将poc複制到自己的vps中，讓使用者進行通路該poc，就完成攻擊。
因為要自動送出修改資訊的請求，是以在burp中，還要勾選include auto-submit script，重新生成一個可以自動送出的poc。
防禦措施
1. 增加token驗證：
在http請求中以參數的形式加入一個随機産生的token，并在服務端來驗證這個token值，如果token不存在或者不正确，則拒絕該請求。
2. 驗證Referer字段：
驗證http請求表referer字段值，該字段值記錄了http請求的來源url，如果來源位址不一樣，則說明該請求不合法，服務端拒絕該請求。
這個防禦方法攻擊者可以進行繞過，攻擊者自定義referer字段來繞過；或者直接删除Referer字段值，也可繞過。
3. 對關鍵操作進行二次身份驗證：
修改密碼、重置密碼等要進行二次身份驗證，或者增加驗證碼驗證。
4. 使用SameSite cookie
SameSite屬性用來控制在跨站請求中是否包含cookie。通常與CSRF令牌一起使用。
如果該屬性設定為SameSite=Strict; 則浏覽器不會在來自其他站點的任何請求中包含cookie，這種方法雖然防禦性最好，但是影響使用者體驗，使用者通路第三方連結時，用顯示未登入。需要再次登入才能正常與網站互動。
如果設定為SameSite=Lax; 浏覽器會判斷跨站請求是GET還是POST請求方式，如果是GET請求，則會給該請求包含cookie，如果是其他請求方法，會不包含cookie。并且還會判斷該請求是否是使用者的頂級導航（單擊連結 ）,如果是其他請求，例如：由腳本發起的請求，則也會不包含cookie。
Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Strict;
Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Lax; 5. CSRF令牌驗證
在服務端應用程式生成，并包含在後續的http請求中，後面所有的http請求都需要包含該令牌，如果令牌丢失或者無效，服務端會拒絕該請求。