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請求都需要包含該令牌，如果令牌丟失或者無效，服務端會拒絕該請求。