利用使用者已經登入的身份，在使用者毫不知情的情況下，以使用者的名義完成非法操作
使用者登入web**，此時瀏覽器含有使用者登入資訊
黑客構造惡意**
使用者主動訪問惡意網頁，轉賬到黑客使用者。
真正完成轉賬的關鍵在於：瀏覽器cookie存放有使用者的登入憑證，當瀏覽器傳送請求時，會繼續帶上已有的cookie, 而受害**本身也存在csrf漏洞，如無token校驗，無法區別請求是使用者還是攻擊者
惡意網頁的構造技巧：含有攻擊的網頁不會顯示任何內容，只會在載入的時候提交新的請求，實現轉賬操作
referer是瀏覽器自動帶上的，基於認為瀏覽器沒有相關漏洞的前提下，我們可以認為攻擊者是沒法偽造referer頭的，也就是檢測referer頭的方法是可靠的。
當前主流的框架為了預防這種攻擊，都是採用token機制。也就是說當使用者與服務端進行互動的時候，傳遞乙個加密字串到服務端，服務端來檢測這個字串是否是合法的，如果不合法就有可能是黑客偽造使用者資訊進行請求的。
那麼這個加密字串是怎麼生成的那？加密字串是由後端程式生成，然後賦值到頁面之上。一般是由當前控制器，方法，金鑰，時間組合在一起加密而成。傳遞到服務端以後，服務端重新生成一遍，如果一致就是合法的，否則就是不合法的。
如上面的轉賬提交操作，如果採用token校驗，需要使用者先去訪問轉賬頁面，正常伺服器返回轉賬頁面並返回乙個與頁面對應token, 使用者在填寫完轉賬資訊提交時候需要帶上token資訊，這樣伺服器就知道這個轉賬申請是不是是由自己傳送的。因為csrf中攻擊者是直接提交轉賬申請，並沒有前面訪問轉賬頁面獲取token的過程。
擴充套件：那為什麼現在的轉賬申請還需要驗證碼或簡訊校驗的操作？
原因是，既然攻擊者可以偽造轉賬申請提交頁面，完全有可能通過偽造一串行的頁面完成訪問轉賬頁面生成token，並提交轉賬申請的操作。這個時候，如果伺服器端通過簡訊校驗的方式呢，使用者一收到簡訊，就知道自己賬號存在洩密風險了。就可能將這些偽造頁面給戳破了。
web安全問題 csrf
1.原理 使用者登入a a 確認身份 b 向a 發起請求 帶a 身份 cookie會保留在網頁中 2.csrf攻擊危害 www.a.com前端 www.a.com後端 www.b.com前端 www.a.com後端 b 向a 請求帶a cookies 不訪問a 前端 refer為b 1.cookie...
web安全 CSRF漏洞
描述 跨站點偽裝請求 csrf 漏洞會在以下情況下發生 1.web 應用程式使用會話 cookie。2.應用程式未驗證請求是否經過使用者同意便處理 http 請求。nonce 是隨訊息一起傳送的加密隨機值，可防止 replay 攻擊。如果該請求未包含證明其 的 nonce，則處理該請求的 將易受到 ...
web安全 CSRF（防禦篇）
csrf防禦之驗證碼 目前，驗證碼被認為是對抗csrf攻擊最簡單有效的防禦措施。用到驗證碼就是在請求過程中強制使用者與應用進行互動，但是乙個站點 乙個好的產品要考慮到使用者的體驗，顯然如果在所有的操作上都加入驗證碼對使用者來說就很不友好。因此驗證碼只能是一種防禦csrf攻擊的輔助手段，並不能成為主要...