? ? ? ? ? ?前幾天項目中遇到springSecurity問題，研究了大半天，掉進(jìn)了csrf的坑，先認(rèn)識一下csrf

CSRF概念：CSRF跨站點請求偽造(Cross—Site Request Forgery)，跟XSS攻擊一樣，存在巨大的危害性，你可以這樣來理解：
? ? ? ?攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求，對服務(wù)器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號，添加系統(tǒng)管理員，甚至于購買商品、虛擬貨幣轉(zhuǎn)賬等。?如下：其中Web A為存在CSRF漏洞的網(wǎng)站，Web B為攻擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶。

? ? ? ?CSRF攻擊攻擊原理及過程如下：

? ? ? ?1.?用戶C打開瀏覽器，訪問受信任網(wǎng)站A，輸入用戶名和密碼請求登錄網(wǎng)站A；

? ? ? ?2.在用戶信息通過驗證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時用戶登錄網(wǎng)站A成功，可以正常發(fā)送請求到網(wǎng)站A；

? ? ? ?3.?用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開一個TAB頁訪問網(wǎng)站B；

? ? ? ?4.?網(wǎng)站B接收到用戶請求后，返回一些攻擊性代碼，并發(fā)出一個請求要求訪問第三方站點A；

? ? ? ?5.?瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請求。網(wǎng)站A并不知道該請求其實是由B發(fā)起的，所以會根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請求，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行。?

所以在實際的網(wǎng)站中你可以使用，springsecurity默認(rèn)是開啟的，所以你在每次訪問的時候你得在你的前端加上頭，不會加的可以看其他博客

? ? ? ?但是在一些訪問的時候如果一些接口沒帶請求的頭就是csrf，這樣就會說沒有權(quán)限，比如支付寶，微信的回調(diào)等，這些是不會加的，所以我們要忽略。

? ? ? 在網(wǎng)上百度了很久也沒有找到,于是自己翻看源碼找到了方法。

?

第一種：配置的時候直接配置忽略方法。

? ? 代碼如下 直接如圖紅框配置即可。

?

第二種：添加RequestMatcher

代碼如下

public class CsrfSecurityRequestMatcher implements RequestMatcher { private Pattern allowedMethods = Pattern.compile("^(GET|HEAD|TRACE|OPTIONS)$"); private RegexRequestMatcher unprotectedMatcher = new RegexRequestMatcher("/unprotected", null); @Override public boolean matches(HttpServletRequest request) { if(allowedMethods.matcher(request.getMethod()).matches()){ return false; } return !unprotectedMatcher.matches(request); } }

?

將這個配置到httpconfig中

這樣一些不加頭的請求就不會被攔截了，解決了問題。

?

?有什么問題可以加我qq1058179540

?

轉(zhuǎn)載于:https://www.cnblogs.com/bingshu/p/8691445.html

總結(jié)

以上是生活随笔為你收集整理的SpringSecurity csrf验证忽略某些请求的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。