一个常见的问题是：“我需要保护 javascript 所做的 JSON 请求吗？” 答案很简单，这要看情况而定。但是，你必须非常小心，因为 CSRF 漏洞可能会影响 JSON 请求。例如，恶意用户可以 使用以下形式使用 JSON 创建 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 结构

{ "amount": 100,
"routingNumber": "evilsRoutingNumber",
"account": "evilsAccountNumber",
"ignore_me": "=test"
}

如果应用程序没有验证内容类型，那么它将暴露于此漏洞。根据设置，仍然可以通过更新 URL 后缀以 ".json" 结尾来利用验证 Content-Type 的 Spring MVC 应用程序，如下所示：

<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>

如果我的应用程序是无状态的呢？这并不一定意味着你受到了保护。事实上，如果用户对于给定的请求不需要在 web 浏览器中执行任何操作，那么他们可能仍然容易受到 CSRF 攻击。

例如，考虑一个应用程序使用一个自定义 cookie，其中包含用于身份验证的所有状态，而不是 JSESSIONID。当进行 CSRF 攻击时，将按照与前面示例中发送 JSESSIONID cookie 相同的方式发送带有请求的自定义 cookie。

使用基本身份验证的用户也容易受到 CSRF 攻击，因为浏览器将以与前面示例中发送 JSESSIONID cookie 相同的方式在任何请求中自动包括用户名密码。

防止 CSRF 攻击的第一步是确保你的网站使用适当的 HTTP 动词。具体地说，在使用 Spring Security 的 CSRF 支持之前，你需要确定你的应用程序正在对任何修改状态的东西使用 PATCH、POST、PUT 和/或 DELETE。

这不是 Spring Security 支持的限制，而是对适当的 CSRF 预防的一般要求。原因是在 HTTP GET 中包含私有信息会导致信息泄漏。关于敏感信息的使用 POST 而不是 GET 的一般指南，请参阅 RFC 2616 小节 15.1.3 在 URI 中编码敏感信息。

下一步是在应用程序中包含 Spring Security 的 CSRF 保护。有些框架通过无效用户会话来处理无效的 CSR F令牌，但这会导致其自身的问题。默认情况下，Spring Security 的 CSRF 保护将产生拒绝 HTTP 403 访问。这可以通过配置 AccessDeniedHandler 以不同的方式处理 InvalidCsrfTokenException 来定制。

在 Spring Security 4.0 中，默认情况下启用 XML 配置的 CSRF 保护。如果你想禁用 CSRF 保护，可以在下面看到相应的 XML 配置。

<http>
	<!-- ... -->
	<csrf disabled="true"/>
</http>

默认情况下，使用 Java 配置启用 CSRF 保护。如果你想禁用CSRF，可以在下面看到相应的 Java 配置。在配置 CSRF 保护时，请参考 csrf() 的 JavaDoc 来进行其他自定义。

@EnableWebSecurity
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http
			.csrf().disable();
	}
}

一个问题是，预期的 CSRF 令牌存储在 HttpSession 中，所以一旦 HttpSession 期满，配置的 AccessDeniedHandler 将收到 InvalidCsrfTokenException。如果你使用默认的 AccessDeniedHandler，浏览器将获得 HTTP 403 并显示低劣的错误消息。

	Note
	人们可能会问，为什么默认的 CsrfToken 默认不存储在 cookie 中。这是因为有已知的漏洞，其中报头（即指定 cookies）可以由另一个域来设置。这也是 Ruby on Rails 当 X-Requested-With 在时不再跳过 CSRF 检查的原因。有关如何执行漏洞的详细信息，请参阅 webappsec.org 线程。另一个缺点是，通过删除状态（即超时），如果令牌被破坏，你将失去强制终止令牌的能力。

减轻活动用户超时的简单方法是使用一些J avaScript，让用户知道他们的会话即将到期。用户可以单击一个按钮来继续并刷新会话。

或者，指定自定义 AccessDeniedHandler 允许你以任何你喜欢的方式处理 InvalidCsrfTokenException。有关如何自定义 AccessDeniedHandler 的示例，请参阅所提供的 xml 和 Java 配置的链接。

最后，应用程序可以被配置为使用不会过期的 CookieCsrfTokenRepository。如前所述，这并不像使用会话那样安全，但在许多情况下可能是足够好的。

为了防止伪造登录请求，登录表单也应该受到保护，防止 CSRF 攻击。由于 CsrfToken 存储在 HttpSession 中，这意味着一旦访问 CsrfToken 令牌属性，就会创建 HttpSession。虽然在 RESTful / 无状态架构中这听起来很糟糕，但实际情况是状态对实现实际安全性是必要的。没有状态，我们没有什么可以做，如果一个令牌妥协。实际上，CSRF 令牌的规模很小，对我们的架构应该没有不可忽视的影响。

保护表单登录的常用技术是使用 JavaScript 函数在表单提交之前获得有效的 CSRF 令牌。通过这样做，不需要考虑会话超时（在上一节中讨论），因为会话是在表单提交之前创建的（假设没有配置 CookieCsrfTokenRepository），所以用户可以停留在登录页上并当他想要的时候提交用户名/密码，为了实现这一点，你可以利用 Spring Security 提供的 CsrfTokenArgumentResolver 并公开一个端点，就像这里描述的那样。

仅使用 HTTP POST 时添加 CSRF 将更新 LogoutFilter。这确保注销需要 CSRF 令牌，并且恶意用户不能强制注销你的用户。

一种方法是使用表单注销。如果你真的想要一个链接，你可以使用 JavaScript 让链接执行一个 POST（也就是说，在一个隐藏的表单上）。对于禁用 JavaScript 的浏览器，可以选择让链接将用户带到将执行 POST 的注销确认页面。

如果你真的想使用注销的 HTTP GET，你可以这样做，但是记住这是不推荐的。例如，下面的 Java 配置将执行注销，URL /logout 是用任何 HTTP 方法请求的：

@EnableWebSecurity
public class WebSecurityConfig extends
WebSecurityConfigurerAdapter {

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		http
			.logout()
				.logoutRequestMatcher(new AntPathRequestMatcher("/logout"));
	}
}

使用 multipart/form-data 时使用 CSRF 保护有两种选择。每个选项都有它的折衷。

	Note
	在将 Spring Security 的 CSRF 保护与 multipart 文件上传集成之前，请确保可以先上传而不需要 CSRF 保护。有关在 Spring 中使用 multipart 表单的更多信息，可以在 Spring 参考的 17.10 Spring 的 multipart（文件上传）支持部分以及 MultipartFilter javadoc 中找到。

public class SecurityApplicationInitializer extends AbstractSecurityWebApplicationInitializer {

	@Override
	protected void beforeSpringSecurityFilterChain(ServletContext servletContext) {
		insertFilters(servletContext, new MultipartFilter());
	}
}

<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>

<form action="./upload?${_csrf.parameterName}=${_csrf.token}" method="post" enctype="multipart/form-data">

应该在 Spring Security 过滤器之前放置 HiddenHttpMethodFilter。一般来说，这是正确的，但是它可以在保护 CSRF 攻击时具有额外的含义。

注意，HiddenHttpMethodFilter 只覆盖 POST 上的 HTTP 方法，因此这实际上不太可能导致任何实际问题。然而，它仍然是最好的做法，以确保它被放置在 Spring Security 的过滤器之前。