10.6.1?CSRF Attacks
在討論Spring Security?如何保護(hù)應(yīng)用程序免受CSRF攻擊之前风纠，我們將解釋什么是CSRF攻擊。讓我們看一個(gè)具體的例子柴墩，以便更好地理解茴扁。
假設(shè)您的銀行網(wǎng)站提供了一個(gè)表單，允許將資金從當(dāng)前登錄的用戶轉(zhuǎn)移到另一個(gè)銀行帳戶涉馁。例如门岔，HTTP請(qǐng)求可能如下所示：
POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876
現(xiàn)在假設(shè)你通過(guò)了銀行網(wǎng)站的身份驗(yàn)證，然后烤送，不注銷(xiāo)寒随，訪問(wèn)一個(gè)邪惡的網(wǎng)站。邪惡網(wǎng)站包含一個(gè)HTML頁(yè)面帮坚，其格式如下：
<form action="https://bank.example.com/transfer" method="post">
<input type="hidden" name="amount" value="100.00"/>
<input type="hidden" name="routingNumber" value="evilsRoutingNumber"/>
<input type="hidden" name="account" value="evilsAccountNumber"/>
<input type="submit" value="Win Money!"/>
</form>
你喜歡贏錢(qián)妻往，所以你點(diǎn)擊提交按鈕。在此過(guò)程中试和，您無(wú)意中將100美元轉(zhuǎn)移給了惡意用戶讯泣。這是因?yàn)椋m然邪惡的網(wǎng)站看不到您的cookie阅悍，但與您的銀行相關(guān)聯(lián)的cookie仍然隨請(qǐng)求一起發(fā)送好渠。
最糟糕的是，整個(gè)過(guò)程可以使用JavaScript實(shí)現(xiàn)自動(dòng)化节视。這意味著你甚至不需要點(diǎn)擊按鈕拳锚。那么，我們?nèi)绾伪Ｗo(hù)自己免受這種攻擊呢寻行？
10.6.2?Synchronizer Token Pattern
問(wèn)題是霍掺，來(lái)自銀行網(wǎng)站的HTTP請(qǐng)求和來(lái)自邪惡網(wǎng)站的請(qǐng)求完全相同。這意味著無(wú)法拒絕來(lái)自邪惡網(wǎng)站的請(qǐng)求只允許來(lái)自銀行網(wǎng)站的請(qǐng)求寡痰。為了防止CSRF攻擊抗楔，我們需要確保邪惡站點(diǎn)無(wú)法提供請(qǐng)求中的某些內(nèi)容。
一種解決方案是使用 ?Synchronizer Token Pattern拦坠。這個(gè)解決方案是為了確保除了會(huì)話cookie之外连躏，每個(gè)請(qǐng)求都需要一個(gè)隨機(jī)生成的令牌作為HTTP參數(shù)。提交請(qǐng)求時(shí)贞滨，服務(wù)器必須查找參數(shù)的預(yù)期值入热，并將其與請(qǐng)求中的實(shí)際值進(jìn)行比較拍棕。如果值不匹配，則請(qǐng)求應(yīng)失敗勺良。
我們可以放寬期望绰播，只需要更新?tīng)顟B(tài)的每個(gè)HTTP請(qǐng)求的令牌。這可以安全地完成尚困，因?yàn)橥床呗源_保邪惡的站點(diǎn)無(wú)法讀取響應(yīng)蠢箩。此外，我們不希望在HTTP GET中包含隨機(jī)令牌事甜，因?yàn)檫@可能導(dǎo)致令牌泄漏谬泌。
讓我們看看我們的示例將如何改變。假設(shè)隨機(jī)生成的令牌存在于名為 _csrf 的HTTP參數(shù)中逻谦。例如掌实，轉(zhuǎn)賬請(qǐng)求如下：
POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876&_csrf=<secure-random>
您會(huì)注意到我們使用隨機(jī)值添加了_csrf參數(shù)。現(xiàn)在邪惡網(wǎng)站無(wú)法猜測(cè)CSRF參數(shù)的正確值（必須在邪惡網(wǎng)站上明確提供）邦马，當(dāng)服務(wù)器將實(shí)際令牌與預(yù)期令牌進(jìn)行比較時(shí)贱鼻，傳輸將失敗。
10.6.3?When to use CSRF protection
什么時(shí)候應(yīng)該使用CSRF保護(hù)滋将？我們的建議是對(duì)正常用戶可以通過(guò)瀏覽器處理的任何請(qǐng)求使用CSRF保護(hù)邻悬。如果您只創(chuàng)建一個(gè)非瀏覽器客戶端使用的服務(wù)，那么您可能希望禁用CSRF保護(hù)耕渴。
CSRF protection and JSON
一個(gè)常見(jiàn)的問(wèn)題是拘悦，“我需要保護(hù)JavaScript發(fā)出的JSON請(qǐng)求嗎齿兔？”簡(jiǎn)而言之橱脸，這要看情況而定。但是分苇，您必須非常小心添诉，因?yàn)榇嬖诳赡苡绊慗SON請(qǐng)求的CSRF漏洞。例如医寿，惡意用戶可以使用以下表單使用JSON創(chuàng)建CSRF：
<form action="https://bank.example.com/transfer" method="post" enctype="text/plain">
<input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
<input type="submit"
? ? value="Win Money!"/>
</form>
這將生成以下JSON結(jié)構(gòu)
{?
"amount": 100,
"routingNumber": "evilsRoutingNumber",
"account": "evilsAccountNumber",
"ignore_me": "=test"
}
如果應(yīng)用程序沒(méi)有驗(yàn)證 Content-Type栏赴，那么它將暴露于此漏洞中。根據(jù)設(shè)置的不同靖秩，驗(yàn)證 Content-Type 的SpringMVC應(yīng)用程序仍然可以通過(guò)更新url后綴以“.json”結(jié)尾來(lái)利用须眷，如下所示：
<form action="https://bank.example.com/transfer.json" method="post" enctype="text/plain">
<input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
<input type="submit"
? ? value="Win Money!"/>
</form>
CSRF and Stateless Browser Applications
如果我的應(yīng)用程序是無(wú)狀態(tài)的呢？這并不一定意味著你受到了保護(hù)沟突。事實(shí)上花颗，如果用戶對(duì)于給定的請(qǐng)求不需要在Web瀏覽器中執(zhí)行任何操作，那么他們可能仍然容易受到CSRF攻擊惠拭。????
例如扩劝，假設(shè)一個(gè)應(yīng)用程序使用一個(gè)自定義cookie，該cookie包含它內(nèi)部的所有狀態(tài)來(lái)進(jìn)行身份驗(yàn)證，而不是JSessionID棒呛。當(dāng)進(jìn)行CSRF攻擊時(shí)聂示，定制cookie將與請(qǐng)求一起發(fā)送，發(fā)送方式與上一個(gè)示例中發(fā)送JSessionID cookie的方式相同簇秒。
使用 basic 認(rèn)證的用戶也容易受到CSRF攻擊鱼喉，因?yàn)闉g覽器將自動(dòng)在任何請(qǐng)求中包含用戶名密碼，其方式與我們上一個(gè)示例中發(fā)送JSessionID cookie的方式相同趋观。
10.6.4?Using Spring Security CSRF Protection
那么蒲凶，使用Spring Security保護(hù)我們的站點(diǎn)免受CSRF攻擊所必需的步驟是什么？使用Spring Security的CSRF保護(hù)的步驟概述如下：????
Use proper HTTP verbs?使用正確的HTTP動(dòng)詞
防止CSRF攻擊的第一步是確保您的網(wǎng)站使用正確的HTTP動(dòng)詞拆内。具體來(lái)說(shuō)旋圆，在Spring Security的CSRF支持可以使用之前，您需要確保您的應(yīng)用程序正在使用 ?PATCH麸恍、POST灵巧、PUT和/或 DELETE 來(lái)修改狀態(tài)。
這不是Spring Security支持的限制抹沪，而是正確預(yù)防CSRF的一般要求刻肄。原因是在HTTP GET中包含私有信息會(huì)導(dǎo)致信息泄漏。請(qǐng)參閱 ?RFC 2616 Section 15.1.3 Encoding Sensitive Information in URI’s?融欧，以獲取有關(guān)使用POST而不是GET獲取敏感信息的一般指導(dǎo)敏弃。
Configure CSRF Protection?配置CSRF保護(hù)
下一步是在你的應(yīng)用程序中引入Spring Security 的CSRF保護(hù)。一些框架通過(guò)使用戶的會(huì)話無(wú)效來(lái)處理無(wú)效的CSRF令牌噪馏，但這會(huì)導(dǎo)致自身的問(wèn)題麦到。相反，默認(rèn)情況下欠肾，Spring Security的CSRF保護(hù)將導(dǎo)致HTTP 403訪問(wèn)被拒絕瓶颠。這可以通過(guò)配置 AccessDeniedHandler 以不同方式處理 InvalidCsrfTokenException?來(lái)定制。
從Spring Security 4.0開(kāi)始刺桃，CSRF保護(hù)默認(rèn)通過(guò)XML配置啟用粹淋。如果要禁用CSRF保護(hù)，可以在下面看到相應(yīng)的XML配置瑟慈。
<http>
????????<!-- ... -->
????????<csrfdisabled="true"/>
</http>
CSRF保護(hù)在使用Java配置時(shí)默認(rèn)啟用桃移。如果您想禁用CSRF，可以看下面相應(yīng)的Java配置葛碧。有關(guān)CSRF保護(hù)的其他自定義配置借杰，請(qǐng)參閱csrf()的javadoc。
@EnableWebSecurity
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
? ? @Override
? ? protected void configure(HttpSecurity http) throws Exception {
? ? ? ? http
? ? ? ? ? ? .csrf().disable();
? ? }
}
Include the CSRF Token
Form Submissions 表單提交
最后一步是確保在所有 PATCH, POST, PUT 和 DELETE? 方法中都包含CSRF令牌吹埠。一種方法是使用 _csrf 請(qǐng)求屬性獲取當(dāng)前 CsrfToken 第步。使用JSP執(zhí)行此操作的示例如下所示：
<c:url var="logoutUrl" value="/logout"/>
<form action="${logoutUrl}"? method="post">
????????<input type="submit" value="Log out" />
????????<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
</form>
一種更簡(jiǎn)單的方法是使用SpringSecurityJSP標(biāo)記庫(kù)中的?the csrfInput tag?標(biāo)記疮装。
如果您使用的是spring mvc<form:form> tag或 Thymeleaf 2.1+，并且使用的是 @enableWebSecurity粘都，則會(huì)自動(dòng)為你包含 CsrfToken? （使用 CsrfRequestDataValueProcessor ）廓推。
Ajax and JSON Requests
如果你正在使用JSON，那么就不可能在HTTP參數(shù)中提交CSRF令牌翩隧。相反樊展，您可以在HTTP頭中提交令牌。典型的模式是在 <meta> 中包含CSRF令牌堆生。帶有JSP的示例如下所示：
<html>
<head>
? ? <meta name="_csrf" content="${_csrf.token}"/>
? ? <!-- default header name is X-CSRF-TOKEN -->
? ? <meta name="_csrf_header" content="${_csrf.headerName}"/>
? ? <!-- ... -->
</head>
<!-- ... -->
你可以使用Spring Security JSP標(biāo)記庫(kù)中更簡(jiǎn)單的 ?csrfMetaTags tag专缠，而不是手動(dòng)創(chuàng)建meta標(biāo)記。
然后可以在所有Ajax請(qǐng)求中包含該令牌淑仆。如果您使用的是jquery涝婉，則可以通過(guò)以下方法完成：
$(function () {
????var token = $("meta[name='_csrf']").attr("content");
????var header = $("meta[name='_csrf_header']").attr("content");
????$(document).ajaxSend(function(e, xhr, options) {
? ? ????xhr.setRequestHeader(header, token);
????});
});
作為jquery的替代方案，我們建議使用cujojs的rest.js蔗怠。js模塊為以RESTful方式處理HTTP請(qǐng)求和響應(yīng)提供了高級(jí)支持墩弯。核心功能是通過(guò)將攔截器鏈接到客戶機(jī)來(lái)根據(jù)需要添加行為，從而將HTTP客戶機(jī)上下文化的能力寞射。
var client = rest.chain(csrf, {
token: $("meta[name='_csrf']").attr("content"),
name: $("meta[name='_csrf_header']").attr("content")
});
配置的客戶端可以與應(yīng)用程序的任何組件共享渔工，這些組件需要向受CSRF保護(hù)的資源發(fā)出請(qǐng)求。rest.js和jquery之間的一個(gè)顯著區(qū)別是桥温，只有使用配置的客戶端進(jìn)行的請(qǐng)求才會(huì)包含CSRF令牌引矩，而jquery中的所有請(qǐng)求都將包含該令牌。確定接收令牌的請(qǐng)求范圍的能力有助于防止CSRF令牌泄漏給第三方侵浸。有關(guān)rest.js的更多信息旺韭，請(qǐng)參閱rest.js參考文檔。
CookieCsrfTokenRepository
在某些情況下通惫，用戶可能希望在cookie中保留 CsrfToken?茂翔。默認(rèn)情況下混蔼，CookieCsrfTokenRepository?將在cookie中寫(xiě)入名為 XSRF-TOKEN 的 token履腋，并從名為 X-XSRF-TOKEN 的頭或http參數(shù) _csrf 讀取該 token。這些默認(rèn)值來(lái)自AngularJS
可以使用以下方法在XML中配置 CookieCsrfTokenRepository?：
<http>
? ? <!-- ... -->
? ? <csrf token-repository-ref="tokenRepository"/>
</http>
<b:bean id="tokenRepository"
? ? class="org.springframework.security.web.csrf.CookieCsrfTokenRepository"
? ? p:cookieHttpOnly="false"/>
示例顯式設(shè)置 cookieHttpOnly=false惭嚣。這是允許JavaScript（即AngularJS）讀取它所必需的遵湖。如果不需要直接使用javascript讀取cookie，建議省略 ?cookieHttpOnly=false?以提高安全性晚吞。
10.6.5?CSRF Caveats
在實(shí)施CSRF時(shí)有一些注意事項(xiàng)延旧。
Timeouts
一個(gè)問(wèn)題是預(yù)期的CSRF令牌存儲(chǔ)在 HttpSession 中，因此一旦 HttpSession 過(guò)期槽地，配置的 AccessDeniedHandler?將收到一個(gè)無(wú)效的 InvalidCsrfTokenException迁沫。如果您使用的是默認(rèn)的 AccessDeniedHandler芦瘾，瀏覽器將得到一個(gè)HTTP403并顯示一條錯(cuò)誤消息。
有人可能會(huì)問(wèn)集畅，為什么默認(rèn)情況下預(yù)期的 CsrfToken? 沒(méi)有存儲(chǔ)在cookie中近弟。這是因?yàn)榇嬖谝阎穆┒矗渲蓄^（即指定cookie）可以由另一個(gè)域設(shè)置挺智。這也是RubyonRails在存在頭X-requested-with時(shí)不再跳過(guò)CSRF檢查的原因祷愉。有關(guān)如何執(zhí)行該漏洞攻擊的詳細(xì)信息，請(qǐng)參閱此webappsec.org線程赦颇。另一個(gè)缺點(diǎn)是二鳄，通過(guò)刪除狀態(tài)（即超時(shí)），您將失去在令牌受到威脅時(shí)強(qiáng)制終止令牌的能力媒怯。
緩解活動(dòng)用戶超時(shí)的一個(gè)簡(jiǎn)單方法是使用一些JavaScript讓用戶知道他們的會(huì)話即將到期订讼。用戶可以單擊按鈕繼續(xù)并刷新會(huì)話。
或者扇苞，指定一個(gè)自定義的accessdeniedHandler允許您以任何方式處理invalidCSRFtokenException躯嫉。有關(guān)如何自定義AccessDeniedHandler?的示例，請(qǐng)參閱所提供的XML和Java配置的鏈接杨拐。
最后祈餐，可以將應(yīng)用程序配置為使用不會(huì)過(guò)期的 CookicsrftokenRepository。如前所述哄陶，這并不像使用會(huì)話那樣安全帆阳，但在許多情況下，這已經(jīng)足夠好了屋吨。
Logging In
為了防止偽造登錄請(qǐng)求蜒谤，登錄表單也應(yīng)防止CSRF攻擊。由于 CsrfToken?存儲(chǔ)在 HttpSession 中至扰，這意味著一旦訪問(wèn)CsrfToken?屬性鳍徽，就會(huì)創(chuàng)建 HttpSession?。雖然這在一個(gè)RESTful/無(wú)狀態(tài)的體系結(jié)構(gòu)中聽(tīng)起來(lái)很糟糕敢课，但事實(shí)是狀態(tài)對(duì)于實(shí)現(xiàn)真正的安全是必要的阶祭。沒(méi)有狀態(tài)，一旦token被破壞我們就無(wú)能為力直秆。實(shí)際上濒募，CSRF令牌的大小非常小，對(duì)我們的體系結(jié)構(gòu)的影響應(yīng)該可以忽略不計(jì)圾结。
保護(hù)登錄表單的常見(jiàn)技術(shù)是在表單提交之前使用javascript函數(shù)獲取有效的CSRF令牌瑰剃。通過(guò)這樣做，無(wú)需考慮會(huì)話超時(shí)（在上一節(jié)中討論）筝野，因?yàn)闀?huì)話是在表單提交之前創(chuàng)建的（假設(shè)沒(méi)有配置 CookieCsrfTokenRepository）晌姚，因此用戶可以留在登錄頁(yè)面上粤剧，并在需要時(shí)提交用戶名/密碼。為了實(shí)現(xiàn)這一點(diǎn)挥唠，您可以利用Spring Security?提供的CsrfTokenArgumentResolver?俊扳，并像這里描述的那樣公開(kāi)一個(gè)端點(diǎn)馋记。
Logging Out
啟動(dòng)了CSRF梯醒，將更新 LogoutFilter 只能使用 HTTP POST（不啟用CSRF時(shí)腌紧，GET請(qǐng)求也是可以正常退出的壁肋，因?yàn)槠洳恍枰狢SRF token）浸遗。這可以確保注銷(xiāo)需要CSRF令牌跛锌，并且惡意用戶無(wú)法強(qiáng)制注銷(xiāo)您的用戶髓帽。
一種方法是使用表單注銷(xiāo)郑藏。如果你真的想要一個(gè)鏈接，你可以使用javascript讓鏈接執(zhí)行一個(gè)POST（也就是說(shuō)拌牲，可能在一個(gè)隱藏的表單上）。對(duì)于禁用了javascript的瀏覽器阁吝，您可以讓鏈接把用戶帶到一個(gè)注銷(xiāo)的確認(rèn)頁(yè)面（POST提交）突勇。
如果您真的想在注銷(xiāo)時(shí)使用HTTP GET甲馋，可以這樣做定躏，但請(qǐng)記住痊远，通常不建議這樣做碧聪。例如，下面的Java配置將執(zhí)行注銷(xiāo)辞嗡，URL ?/logout?是用任何HTTP方法請(qǐng)求的：
@EnableWebSecurity
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {
? ? @Override
? ? protected void configure(HttpSecurity http) throws Exception {
? ? ? ? http
? ? ? ? ? ? .logout()
? ? ? ? ? ? ? ? .logoutRequestMatcher(new AntPathRequestMatcher("/logout"));
? ? }
}
Multipart (file upload)
對(duì) multipart/form-data 使用CSRF保護(hù)有兩個(gè)選項(xiàng)。每個(gè)選項(xiàng)都有其權(quán)衡猎贴。
?Placing MultipartFilter before Spring Security
在將Spring Security的CSRF保護(hù)與多部分文件上傳集成之前她渴，請(qǐng)確保您可以先上傳而不需要CSRF保護(hù)趁耗。有關(guān)將多部分表單與Spring一起使用的更多信息苛败，可以在?17.10 Spring’s multipart (file upload) support?章節(jié)和?MultipartFilter javadoc?中找到罢屈。
Placing MultipartFilter before Spring Security
第一個(gè)選項(xiàng)是確保在Spring Security 過(guò)濾器之前指定 MultipartFilter?缠捌。在Spring安全過(guò)濾器之前指定 MultipartFilter? 意味著沒(méi)有調(diào)用 MultipartFilter??的授權(quán)曼月，這意味著任何人都可以在服務(wù)器上放置臨時(shí)文件。但是炎辨，只有授權(quán)用戶才能提交由您的應(yīng)用程序處理的文件碴萧。一般來(lái)說(shuō)破喻，這是推薦的方法低缩，因?yàn)榕R時(shí)文件上載對(duì)大多數(shù)服務(wù)器都會(huì)產(chǎn)生不可忽略的影響。
為了確保在使用Java配置的Spring Security 過(guò)濾器之前指定?MultipartFilter?玩般，用戶可以覆蓋beforeSpringSecurityFilterChain?礼饱，如下所示：
public class SecurityApplicationInitializer extends AbstractSecurityWebApplicationInitializer {
? ? @Override
? ? protected void beforeSpringSecurityFilterChain(ServletContext servletContext) {
? ? ? ? insertFilters(servletContext, new MultipartFilter());
? ? }
}
為了確保 MultipartFilter?在使用xml配置的spring?Security 過(guò)濾器之前被指定匀伏，用戶可以確保 ?MultipartFilter?的 <filter mapping>?元素放在web.xml中的 springSecurityFilterChain?之前够颠，如下所示：
<filter>
? ? <filter-name>MultipartFilter</filter-name>
? ? <filter-class>org.springframework.web.multipart.support.MultipartFilter</filter-class>
</filter>
<filter>
? ? <filter-name>springSecurityFilterChain</filter-name>
? ? <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
? ? <filter-name>MultipartFilter</filter-name>
? ? <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
? ? <filter-name>springSecurityFilterChain</filter-name>
? ? <url-pattern>/*</url-pattern>
</filter-mapping>
Include CSRF token in action
如果不允許未經(jīng)授權(quán)的用戶上傳臨時(shí)文件，則可以將 MultipartFilter?放在spring Security 過(guò)濾器之后剃诅，并將 CSRF?作為查詢參數(shù)包含在表單的action屬性中矛辕。下面是一個(gè)帶有JSP的示例
<form action="./upload?${_csrf.parameterName}=${_csrf.token}" method="post" enctype="multipart/form-data">
這種方法的缺點(diǎn)是可以泄漏查詢參數(shù)堡牡。一般來(lái)說(shuō)杨刨，最好的做法是將敏感數(shù)據(jù)放在主體或頭中，以確保不會(huì)泄漏惠勒。其他信息可在?RFC 2616 Section 15.1.3 Encoding Sensitive Information in URI’s.中查找。
HiddenHttpMethodFilter
HiddenHttpMethodFilter?應(yīng)該放在Spring Security過(guò)濾器之前涂臣。一般來(lái)說(shuō)赁遗，這是正確的岩四，但在防止CSRF攻擊時(shí)，它可能會(huì)有額外的影響哥攘。
請(qǐng)注意剖煌，HiddenHttpMethodFilter?只重寫(xiě)HTTP?的POST方法，因此這實(shí)際上不太可能導(dǎo)致任何實(shí)際問(wèn)題逝淹。但是耕姊，最好還是將其放在Spring Security過(guò)濾器之前。
10.6.6?Overriding Defaults
SpringSecurity的目標(biāo)是提供保護(hù)您的用戶免受攻擊的默認(rèn)值栅葡。這并不意味著您必須接受它的所有默認(rèn)值茉兰。
例如，您可以提供一個(gè)自定義的 CsrfTokenRepository?來(lái)覆蓋 CSRFtoken 的存儲(chǔ)方式妥畏。為了保證在分布式系統(tǒng)中可以使用邦邦，用Redis來(lái)存儲(chǔ)是比較常見(jiàn)的實(shí)現(xiàn)方式燃辖。
您還可以指定一個(gè)自定義的 RequestMatcher?來(lái)確定哪些請(qǐng)求受CSRF保護(hù)（也就是說(shuō)氏身，您可能不關(guān)心logout是否安全）陷虎。簡(jiǎn)而言之凿掂，如果Spring Security的CSRF保護(hù)行為不完全符合您的要求惨恭，那么您可以自定義該行為。有關(guān)如何使用XML和java配置來(lái)進(jìn)行這些自定義的詳細(xì)信息脓规，詳見(jiàn)the section called “<csrf>”章節(jié)熔恢。
