diff --git a/docs/spring-security/servlet-configuration-xml-namespace.md b/docs/spring-security/servlet-configuration-xml-namespace.md
new file mode 100644
index 0000000000000000000000000000000000000000..1469d97c9f98edfa1f18984b152feb5c8f1deea4
--- /dev/null
+++ b/docs/spring-security/servlet-configuration-xml-namespace.md
@@ -0,0 +1,249 @@
+# 安全名称空间配置
+
+## 导言
+
+自 Spring 框架的2.0版本以来,名称空间配置一直可用。它允许你使用额外的XML模式中的元素来补充传统的 Spring bean应用程序上下文语法。你可以在 Spring [参考文献](https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/)中找到更多信息。名称空间元素可以简单地用于允许以更简洁的方式配置单个 Bean,或者更强大地,用于定义替代配置语法,该语法更紧密地匹配问题域,并向用户隐藏潜在的复杂性。一个简单的元素可能掩盖了一个事实,即多个bean和处理步骤正在被添加到应用程序上下文中。例如,将以下元素从安全名称空间添加到应用程序上下文中,将启动一个嵌入式LDAP服务器,以测试在应用程序中的使用情况:
+
+```
+
+```
+
+这比连接等效的 Apache 目录服务器bean要简单得多。最常见的替代配置需求由`ldap-server`元素上的属性支持,并且用户不必担心需要创建哪些bean以及 Bean 属性名称是什么。。]在编辑应用程序上下文文件时使用一个好的XML编辑器,应该提供关于可用的属性和元素的信息。我们建议你尝试[Eclipse IDE with Spring Tools](https://spring.io/tools),因为它具有用于处理标准 Spring 名称空间的特殊功能。
+
+要在应用程序上下文中开始使用安全名称空间,你需要在 Classpath 上使用`spring-security-config`jar。然后,你所需要做的就是将架构声明添加到应用程序上下文文件中:
+
+```
+
+ ...
+
+```
+
+在你将看到的许多示例中(以及在示例应用程序中),我们通常使用“security”作为默认名称空间,而不是“bean”,这意味着我们可以省略所有安全名称空间元素上的前缀,从而使内容更易于阅读。如果你将你的应用程序上下文划分为不同的文件,并且将大多数安全配置都放在其中一个文件中,那么你可能也想这样做。然后,你的安全应用程序上下文文件将像这样启动
+
+```
+
+ ...
+
+```
+
+在本章中,我们将假设从现在开始使用这种语法。
+
+### 命名空间的设计
+
+名称空间旨在捕捉框架的最常见用途,并提供简化和简明的语法,以便在应用程序中启用它们。该设计基于框架内的大规模依赖关系,可以分为以下几个方面:
+
+* *Web/HTTP安全性*-最复杂的部分。设置用于应用框架身份验证机制的过滤器和相关服务bean,以保护URL,呈现登录和错误页面等等。
+
+* *业务对象(方法)安全性*-用于保护服务层的选项。
+
+* *身份验证管理器*-处理来自框架其他部分的身份验证请求。
+
+* *AccessDecisionManager*-提供Web和方法安全性的访问决策。将注册一个默认的,但你也可以选择使用一个自定义的,使用正常的 Spring Bean 语法声明。
+
+* *身份验证提供者*s-身份验证管理器对用户进行身份验证的机制。名称空间提供了对几个标准选项的支持,也是添加使用传统语法声明的自定义bean的一种方式。
+
+* *UserDetailsService*-与身份验证提供程序密切相关,但通常也需要其他bean。
+
+我们将在下面的小节中看到如何配置这些功能。
+
+## 安全名称空间配置入门
+
+在本节中,我们将研究如何构建名称空间配置,以使用框架的一些主要特性。让我们假设你最初希望尽快启动和运行,并通过一些测试登录向现有的Web应用程序添加身份验证支持和访问控制。然后,我们将研究如何转换为针对数据库或其他安全存储库进行身份验证。在后面的部分中,我们将介绍更高级的名称空间配置选项。
+
+### web.xml配置
+
+你需要做的第一件事是将以下过滤器声明添加到你的`web.xml`文件中:
+
+```
+
+springSecurityFilterChain
+org.springframework.web.filter.DelegatingFilterProxy
+
+
+
+springSecurityFilterChain
+/*
+
+```
+
+这提供了一个到 Spring 安全Web基础设施的钩子。`DelegatingFilterProxy`是一个 Spring 框架类,它委托给一个过滤器实现,该过滤器实现在你的应用程序上下文中被定义为 Spring Bean。在这种情况下, Bean 被命名为“SpringSecurityFilterChain”,这是由名称空间创建的内部基础设施 Bean,用于处理Web安全。请注意,你自己不应该使用这个名称。一旦你把这个添加到你的`web.xml`中,你就可以开始编辑你的应用程序上下文文件了。Web安全服务使用``元素进行配置。
+
+### 最小\配置
+
+要启用Web安全性,你所需要做的就是从一开始就启用它。
+
+```
+
+
+
+
+
+```
+
+这表示我们希望我们的应用程序中的所有URL都是安全的,需要角色`ROLE_USER`来访问它们,我们希望使用带有用户名和密码的表单登录到应用程序,并且我们希望注册一个注销URL,这将允许我们从应用程序中注销。``元素是所有与Web相关的命名空间功能的父元素。``元素定义了一个`pattern`,它使用 Ant 路径样式语法,用于匹配实际执行方式的更多详细信息。]你还可以使用正则表达式匹配作为一种选择(有关更多详细信息,请参见名称空间附录)。`access`属性定义了匹配给定模式的请求的访问要求。对于默认配置,这通常是一个逗号分隔的角色列表,其中一个必须允许用户提出请求。前缀“role\_”是一个标记,表示应该与用户的权限进行简单的比较。换句话说,应该使用正常的基于角色的检查。 Spring 安全中的访问控制并不限于使用简单的角色(因此使用前缀来区分不同类型的安全属性)。稍后我们将看到解释如何改变。在 Spring Security3.0中,还可以使用[EL表达式](../authorization/expression-based.html#el-access)填充属性。
+
+| |你可以使用多个``元素来为不同的URL集定义不同的访问要求,但它们将按照列出的顺序进行计算,并使用第一个匹配项。,因此,你必须将最具体的匹配项放在顶部,
还可以添加一个`method`属性,以将匹配限制为特定的HTTP方法(`GET`,`POST`,`PUT`等)。|
+|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+要添加一些用户,你可以直接在名称空间中定义一组测试数据:
+
+```
+
+
+
+
+
+
+
+
+
+```
+
+这是存储相同密码的安全方法的一个示例。密码的前缀是`{bcrypt}`,指示`DelegatingPasswordEncoder`,该命令支持任何配置的`PasswordEncoder`进行匹配,并使用bcrypt对密码进行哈希:
+
+```
+
+
+
+
+
+
+
+
+
+
+```
+
+如果你熟悉该框架的预命名空间版本,你可能已经可以大致猜到这里发生了什么。``元素负责创建`FilterChainProxy`和它所使用的过滤器bean。常见的问题,如不正确的过滤器排序不再是一个问题,因为过滤器的位置是预先定义的。
+
+``元素创建一个`DaoAuthenticationProvider` Bean,而``元素创建一个`InMemoryDaoImpl`。所有`authentication-provider`元素必须是``元素的子元素,该元素创建一个`ProviderManager`并向其注册身份验证提供者。你可以在[名称空间附录](../appendix/namespace/index.html#appendix-namespace)中找到有关创建的bean的更详细信息。如果你想开始了解框架中的重要类是什么以及它们是如何使用的,特别是如果你想在以后定制这些类,那么值得对此进行交叉检查。
+
+上面的配置定义了两个用户、他们的密码和他们在应用程序中的角色(将用于访问控制)。还可以使用`user-service`上的`properties`属性从标准属性文件加载用户信息。有关文件格式的更多详细信息,请参见[内存中身份验证](../authentication/passwords/in-memory.html#servlet-authentication-inmemory)一节。使用``元素意味着用户信息将被身份验证管理器用于处理身份验证请求。你可以使用多个``元素来定义不同的认证源,并依次对每个元素进行查询。
+
+此时,你应该能够启动你的应用程序,并且需要登录才能继续。尝试一下,或者尝试一下项目附带的“教程”示例应用程序。
+
+#### 设置默认的登录后目标
+
+如果试图访问受保护的资源时没有提示表单登录,那么`default-target-url`选项就会起作用。这是用户成功登录后将被带到的URL,默认为“/”。通过将`always-use-default-target`属性设置为“true”,你还可以配置一些东西,以便用户*总是*最终在此页面结束(无论登录是“按需”还是他们明确选择登录)。如果你的应用程序总是要求用户从“主页”页面开始,这是有用的,例如:
+
+```
+
+
+
+
+
+```
+
+为了获得对目的地的更多控制,你可以使用`authentication-success-handler-ref`属性作为`default-target-url`的替代选项。引用的 Bean 应该是`AuthenticationSuccessHandler`的实例。
+
+## 高级Web功能
+
+### 添加自己的过滤器
+
+如果你以前使用过 Spring 安全性,那么你就会知道,该框架维护了一系列过滤器,以便应用其服务。你可能希望在特定位置将自己的筛选器添加到堆栈中,或者使用 Spring 安全筛选器,该筛选器目前没有名称空间配置选项(例如,CAS)。或者,你可能希望使用标准名称空间过滤器的定制版本,例如`UsernamePasswordAuthenticationFilter`,它是由``元素创建的,利用了一些额外的配置选项,这些额外的配置选项可以通过显式地使用 Bean 来获得。既然过滤器链不是直接公开的,那么如何使用名称空间配置来实现这一点呢?
+
+在使用名称空间时,总是严格执行过滤器的顺序。在创建应用程序上下文时,过滤器bean按名称空间处理代码进行排序,标准 Spring 安全过滤器在名称空间和众所周知的位置中都有一个别名。
+
+| |在以前的版本中,排序是在应用程序上下文的后处理过程中,在过滤器实例被创建之后进行的,
在版本3.0中,排序现在是在 Bean 元数据级别完成的,在类被实例化之前。
这对于如何将自己的筛选器添加到堆栈有影响,因为在解析``元素期间,必须知道整个筛选器列表,所以语法在3.0中略有变化。|
+|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+创建过滤器的过滤器、别名和名称空间元素/属性在[标准过滤器别名和排序](#filter-stack)中显示。过滤器是按照它们在过滤器链中出现的顺序列出的。
+
+| Alias | Filter Class |名称空间元素或属性|
+|------------------------------|-----------------------------------------------------|-------------------------------------------------------|
+| CHANNEL\_FILTER | `ChannelProcessingFilter` |`http/[[email protected]](/cdn-cgi/l/email-protection)`|
+| SECURITY\_CONTEXT\_FILTER | `SecurityContextPersistenceFilter` |`http`|
+| CONCURRENT\_SESSION\_FILTER | `ConcurrentSessionFilter` |`session-management/concurrency-control`|
+| HEADERS\_FILTER | `HeaderWriterFilter` |`http/headers`|
+| CSRF\_FILTER | `CsrfFilter` |`http/csrf`|
+| LOGOUT\_FILTER | `LogoutFilter` |`http/logout`|
+| X509\_FILTER | `X509AuthenticationFilter` |`http/x509`|
+| PRE\_AUTH\_FILTER |`AbstractPreAuthenticatedProcessingFilter` Subclasses|不适用|
+| CAS\_FILTER | `CasAuthenticationFilter` |不适用|
+| FORM\_LOGIN\_FILTER | `UsernamePasswordAuthenticationFilter` |`http/form-login`|
+| BASIC\_AUTH\_FILTER | `BasicAuthenticationFilter` |`http/http-basic`|
+|SERVLET\_API\_SUPPORT\_FILTER | `SecurityContextHolderAwareRequestFilter` |`http/@servlet-api-provision`|
+| JAAS\_API\_SUPPORT\_FILTER | `JaasApiIntegrationFilter` |`http/@jaas-api-provision`|
+| REMEMBER\_ME\_FILTER | `RememberMeAuthenticationFilter` |`http/remember-me`|
+| ANONYMOUS\_FILTER | `AnonymousAuthenticationFilter` |`http/anonymous`|
+| SESSION\_MANAGEMENT\_FILTER | `SessionManagementFilter` |`session-management`|
+|EXCEPTION\_TRANSLATION\_FILTER| `ExceptionTranslationFilter` |`http`|
+|FILTER\_SECURITY\_INTERCEPTOR | `FilterSecurityInterceptor` |`http`|
+| SWITCH\_USER\_FILTER | `SwitchUserFilter` |不适用|
+
+你可以将自己的筛选器添加到堆栈中,使用`custom-filter`元素和其中一个名称来指定筛选器应该出现在以下位置:
+
+```
+
+
+
+
+
+```
+
+如果希望在堆栈中的另一个过滤器之前或之后插入过滤器,还可以使用`after`或`before`属性。名称“first”和“last”可以与`position`属性一起使用,以表明你希望你的筛选器分别出现在整个堆栈之前或之后。
+
+| |避免过滤器位置冲突
如果你要插入一个自定义过滤器,该过滤器的位置可能与名称空间创建的标准过滤器的位置相同,那么这一点很重要你没有错误地包含名称空间版本。,
删除任何创建过滤器的元素,这些过滤器的功能是你想要替换的,
注意,你不能替换使用``元素本身创建的过滤器-`SecurityContextPersistenceFilter`,`ExceptionTranslationFilter`或`FilterSecurityInterceptor`。
默认情况下添加了其他一些过滤器,但你可以禁用它们。
默认情况下添加了一个`AnonymousAuthenticationFilter`,除非你禁用了[session-fixation protection](../authentication/session-management.html#ns-session-fixation),否则还将向过滤器链中添加一个`SessionManagementFilter`。|
+|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+如果要替换需要身份验证入口点的名称空间过滤器(即未经身份验证的用户试图访问安全资源而触发身份验证过程),还需要添加自定义入口点 Bean。
+
+## 方法安全性
+
+Spring 从版本2.0开始,安全性在很大程度上改进了对向服务层方法添加安全性的支持。它提供了对JSR-250注释安全性的支持,以及框架的原始`@Secured`注释。从3.0开始,你还可以使用New[基于表达式的注释](../authorization/expression-based.html#el-access)。你可以对单个 Bean 应用安全性,使用`intercept-methods`元素来装饰 Bean 声明,或者可以使用AspectJ样式的切入点在整个服务层中保护多个bean。
+
+## 默认的accessesdecisionManager
+
+本节假定你对 Spring Security中的访问控制的底层体系结构有一定的了解。如果你不这样做,你可以跳过它,稍后再来讨论它,因为这一部分只与那些需要进行一些定制以使用比简单的基于角色的安全性更多功能的人相关。
+
+当你使用名称空间配置时,将自动为你注册一个`AccessDecisionManager`的默认实例,该实例将用于为方法调用和Web URL访问做出访问决策,基于你在`intercept-url`和`protect-pointcut`声明中指定的访问属性(如果你使用的是注释安全方法,则在注释中指定)。
+
+默认的策略是使用`AffirmativeBased``AccessDecisionManager`和`RoleVoter`。你可以在[授权](../authorization/architecture.html#authz-arch)一章中找到更多有关这些的信息。
+
+### 自定义accessDecisionManager
+
+如果需要使用更复杂的访问控制策略,那么很容易为方法和Web安全性设置替代方案。
+
+对于方法安全性,你可以通过将`global-method-security`上的`access-decision-manager-ref`属性设置为应用程序上下文中适当的`id` Bean 中的`id`来实现此目的:
+
+```
+
+...
+
+```
+
+Web安全性的语法是相同的,但是在`http`元素上:
+
+```
+
+...
+
+```
+
+---
+
+[1](#_footnoteref_1)。你可以在关于Xref的章节中找到有关`ldap-server`元素使用情况的更多信息: Servlet/authentication/unpwd/ldap.ADOC# Servlet-authentication-ldap[ldap身份验证]
+
+[2](#_footnoteref_2)。参见Xref部分: Servlet/exploits/firewall.ADOC# Servlet-HttpFirewall[`HttpFirewall`
+
+[3](#_footnoteref_3)。对`access`属性中逗号分隔的值的解释取决于所使用的[AccessDecisionManager](#ns-access-manager)的实现。
+
+[Kotlin Configuration](kotlin.html)[Testing](../test/index.html)
+
diff --git a/docs/spring-security/servlet-exploits-csrf.md b/docs/spring-security/servlet-exploits-csrf.md
new file mode 100644
index 0000000000000000000000000000000000000000..92ce7c70e3a351c4711d8fdb750366feaa12d834
--- /dev/null
+++ b/docs/spring-security/servlet-exploits-csrf.md
@@ -0,0 +1,389 @@
+# Servlet 环境中的跨站点请求伪造
+
+本节讨论 Spring Security对 Servlet 环境的[跨站点请求伪造](../../features/exploits/csrf.html#csrf)支持。
+
+## 使用 Spring 安全CSRF保护
+
+使用 Spring Security的CSRF保护的步骤概述如下:
+
+* [使用适当的HTTP动词](#servlet-csrf-idempotent)
+
+* [配置CSRF保护](#servlet-csrf-configure)
+
+* [包括CSRF令牌](#servlet-csrf-include)
+
+### 使用适当的HTTP动词
+
+防止CSRF攻击的第一步是确保你的网站使用正确的HTTP动词。这在[安全的方法必须是幂等的。](../../features/exploits/csrf.html#csrf-protection-idempotent)中有详细介绍。
+
+### 配置CSRF保护
+
+下一步是在应用程序中配置 Spring Security的CSRF保护。 Spring 默认情况下,Security的CSRF保护是启用的,但你可能需要定制配置。下面是一些常见的定制。
+
+#### 自定义CSRFTokenRepository
+
+Spring 默认情况下,Security使用`HttpSessionCsrfTokenRepository`将预期的CSRF令牌存储在`HttpSession`中。在某些情况下,用户可能希望配置自定义`CsrfTokenRepository`。例如,可能希望将cookie中的`CsrfToken`持久化到[支持基于JavaScript的应用程序](#servlet-csrf-include-ajax-auto)。
+
+默认情况下,`CookieCsrfTokenRepository`将写到一个名为`XSRF-TOKEN`的cookie,并从一个名为`X-XSRF-TOKEN`的头部或HTTP参数`_csrf`读取它。这些默认值来自[AngularJS](https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection)
+
+可以使用以下方法在XML中配置`CookieCsrfTokenRepository`:
+
+例1.使用XML配置在cookie中存储CSRF令牌
+
+```
+
+
+
+
+
+```
+
+| |示例显式设置`cookieHttpOnly=false`.
这是允许JavaScript(即Angularjs)读取它所必需的。
如果不需要直接使用JavaScript读取cookie的能力,建议省略`cookieHttpOnly=false`以提高安全性。|
+|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+你可以在 Java 配置中使用以下方法配置`CookieCsrfTokenRepository`:
+
+例2.在cookie中存储CSRF令牌
+
+Java
+
+```
+@EnableWebSecurity
+public class WebSecurityConfig extends
+ WebSecurityConfigurerAdapter {
+
+ @Override
+ protected void configure(HttpSecurity http) {
+ http
+ .csrf(csrf -> csrf
+ .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
+ );
+ }
+}
+```
+
+Kotlin
+
+```
+@EnableWebSecurity
+class SecurityConfig : WebSecurityConfigurerAdapter() {
+
+ override fun configure(http: HttpSecurity) {
+ http {
+ csrf {
+ csrfTokenRepository = CookieCsrfTokenRepository.withHttpOnlyFalse()
+ }
+ }
+ }
+}
+```
+
+| |示例显式设置`cookieHttpOnly=false`.
这是允许JavaScript(即Angularjs)读取它所必需的。
如果不需要直接使用JavaScript读取cookie的能力,建议省略`cookieHttpOnly=false`(通过使用`new CookieCsrfTokenRepository()`代替)以提高安全性。|
+|---|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+#### 禁用CSRF保护
+
+默认情况下启用了CSRF保护。但是,如果CSRF保护[对你的应用程序来说是有意义的](../../features/exploits/csrf.html#csrf-when),则禁用CSRF保护非常简单。
+
+下面的XML配置将禁用CSRF保护。
+
+例3.禁用CSRF XML配置
+
+```
+
+
+
+
+```
+
+下面的 Java 配置将禁用CSRF保护。
+
+例4.禁用CSRF
+
+Java
+
+```
+@Configuration
+@EnableWebSecurity
+public class WebSecurityConfig extends
+ WebSecurityConfigurerAdapter {
+
+ @Override
+ protected void configure(HttpSecurity http) {
+ http
+ .csrf(csrf -> csrf.disable());
+ }
+}
+```
+
+Kotlin
+
+```
+@Configuration
+@EnableWebSecurity
+class SecurityConfig : WebSecurityConfigurerAdapter() {
+
+ override fun configure(http: HttpSecurity) {
+ http {
+ csrf {
+ disable()
+ }
+ }
+ }
+}
+```
+
+### 包括CSRF令牌
+
+为了使[同步器令牌模式](../../features/exploits/csrf.html#csrf-protection-stp)能够抵御CSRF攻击,我们必须在HTTP请求中包含实际的CSRF令牌。这必须包含在请求的一部分(即表单参数、HTTP头等)中,而该部分不是由浏览器自动包含在HTTP请求中的。
+
+Spring Security的[CsrfFilter](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfFilter.html)将[CsrfToken](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/csrf/CsrfToken.html)公开为名为`HttpServletRequest`的属性。这意味着,任何视图技术都可以访问`CsrfToken`以将预期的令牌公开为[form](#servlet-csrf-include-form-attr)或[meta tag](#servlet-csrf-include-ajax-meta-attr)。幸运的是,下面列出的集成使得在[form](#servlet-csrf-include-form)和[ajax](#servlet-csrf-include-ajax)请求中包含令牌变得更加容易。
+
+#### 表单URL编码
+
+为了发布HTML表单,CSRF令牌必须作为隐藏输入包含在表单中。例如,呈现的HTML可能看起来像:
+
+例5. CSRF令牌HTML
+
+```
+
+```
+
+接下来,我们将讨论将CSRF令牌以一种形式包含为隐藏输入的各种方法。
+
+##### CSRF令牌自动包含
+
+Spring Security的CSRF支持通过其[CsrfrequestDataValueProcessor](https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/servlet/support/csrf/CsrfRequestDataValueProcessor.html)提供与 Spring 的[RequestDataValueProcessor](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/support/RequestDataValueProcessor.html)的集成。这意味着,如果你利用[Spring’s form tag library](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc-view-jsp-formtaglib)、[Thymeleaf](https://www.thymeleaf.org/doc/tutorials/2.1/thymeleafspring.html#integration-with-requestdatavalueprocessor)或与`RequestDataValueProcessor`集成的任何其他视图技术,那么具有不安全的HTTP方法(即POST)的窗体将自动包括实际的CSRF令牌。
+
+##### csrfinput标记
+
+如果你正在使用JSP,那么你可以使用[Spring’s form tag library](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc-view-jsp-formtaglib)。但是,如果这不是一个选项,你也可以很容易地将令牌包含在[csrfInput](../integrations/jsp-taglibs.html#taglibs-csrfinput)标记中。
+
+##### CSRFToken请求属性
+
+如果用于在请求中包含实际CSRF令牌的[其他选择](#servlet-csrf-include)不起作用,则可以利用以下事实:`CsrfToken`[is exposed](#servlet-csrf-include)作为`HttpServletRequest`属性,该属性名为`_csrf`。
+
+使用JSP执行此操作的示例如下所示:
+
+例6.具有请求属性的表单中的CSRF令牌
+
+```
+
+
+```
+
+#### Ajax和JSON请求
+
+如果你正在使用JSON,那么就不可能在HTTP参数中提交CSRF令牌。相反,你可以在HTTP头中提交令牌。
+
+在下面的部分中,我们将讨论在基于JavaScript的应用程序中将CSRF令牌作为HTTP请求头包含在内的各种方法。
+
+##### 自动包含
+
+Spring 安全性可以很容易地[configured](#servlet-csrf-configure-custom-repository)将预期的CSRF令牌存储在cookie中。通过将预期的CSRF存储在Cookie中,像[AngularJS](https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection)这样的JavaScript框架将自动在HTTP请求头中包含实际的CSRF令牌。
+
+##### 元标签
+
+[在cookie中暴露CSRF](#servlet-csrf-include-form-auto)的另一种模式是在`meta`标记中包含CSRF标记。HTML可能看起来是这样的:
+
+例7. CSRF元标记HTML
+
+```
+
+
+
+
+
+
+
+```
+
+一旦元标记包含CSRF令牌,JavaScript代码将读取元标记并将CSRF令牌作为报头。如果你正在使用jQuery,可以通过以下方式完成此操作:
+
+例8. Ajax发送CSRF令牌
+
+```
+$(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);
+ });
+});
+```
+
+###### CSRFMeta标签
+
+如果你正在使用JSP,那么将CSRF令牌写入`meta`标记的一种简单方法是利用[csrfMeta](../integrations/jsp-taglibs.html#taglibs-csrfmeta)标记。
+
+###### CSRFToken请求属性
+
+如果用于在请求中包含实际CSRF令牌的[其他选择](#servlet-csrf-include)不起作用,则可以利用以下事实:`CsrfToken`[is exposed](#servlet-csrf-include)作为`HttpServletRequest`属性,该属性名为`_csrf`。使用JSP执行此操作的示例如下所示:
+
+例9. CSRF元标记JSP
+
+```
+
+
+
+
+
+
+
+
+```
+
+## CSRF考虑因素
+
+在实施针对CSRF攻击的保护时,有几个特殊的考虑因素需要考虑。本节讨论与 Servlet 环境相关的那些考虑因素。有关更一般性的讨论,请参见[CSRF考虑因素](../../features/exploits/csrf.html#csrf-considerations)。
+
+### 登录
+
+这是重要的[需要CSRF才能登录](../../features/exploits/csrf.html#csrf-considerations-login)请求,以防止伪造日志的企图。 Spring Security的 Servlet 支持是开箱即用的。
+
+### 注销
+
+重要的是[需要CSRF才能注销](../../features/exploits/csrf.html#csrf-considerations-logout)请求,以防止伪造注销尝试。如果启用了CSRF保护(默认), Spring Security的`LogoutFilter`将仅处理HTTP POST。这确保了注销需要CSRF令牌,并且恶意用户不能强制注销你的用户。
+
+最简单的方法是使用表单注销。如果你真的想要一个链接,可以使用JavaScript让该链接执行一个POST(例如,可能在一个隐藏的表单上)。对于禁用了JavaScript的浏览器,你可以选择让链接将用户带到将执行POST的注销确认页面。
+
+如果你真的想使用HTTP GET与注销,你可以这样做,但请记住,这通常是不推荐的。例如,以下 Java 配置将使用任何HTTP方法请求的URL执行注销:
+
+例10.用HTTP GET登出
+
+Java
+
+```
+@EnableWebSecurity
+public class WebSecurityConfig extends
+ WebSecurityConfigurerAdapter {
+
+ @Override
+ protected void configure(HttpSecurity http) {
+ http
+ .logout(logout -> logout
+ .logoutRequestMatcher(new AntPathRequestMatcher("/logout"))
+ );
+ }
+}
+```
+
+Kotlin
+
+```
+@EnableWebSecurity
+class SecurityConfig : WebSecurityConfigurerAdapter() {
+
+ override fun configure(http: HttpSecurity) {
+ http {
+ logout {
+ logoutRequestMatcher = AntPathRequestMatcher("/logout")
+ }
+ }
+ }
+}
+```
+
+### CSRF和会话暂停
+
+默认情况下, Spring Security将CSRF令牌存储在`HttpSession`中。这可能导致会话过期的情况,这意味着没有预期的CSRF令牌来验证。
+
+我们已经讨论了[一般解决方案](../../features/exploits/csrf.html#csrf-considerations-login)到会话的超时。本节讨论CSRF超时的细节,因为它与 Servlet 支持有关。
+
+将预期的CSRF令牌的存储更改为cookie中的存储是很简单的。有关详细信息,请参阅[自定义CSRFTokenRepository](#servlet-csrf-configure-custom-repository)部分。
+
+如果一个令牌确实过期了,你可能希望通过指定一个自定义`AccessDeniedHandler`来定制它的处理方式。自定义`AccessDeniedHandler`可以以任何方式处理`InvalidCsrfTokenException`。对于如何自定义`AccessDeniedHandler`的示例,请参阅为[xml](../appendix/namespace/http.html#nsa-access-denied-handler)和[Java configuration](https://github.com/spring-projects/spring-security/tree/5.6.2/config/src/test/java/org/springframework/security/config/annotation/web/configurers/NamespaceHttpServerAccessDeniedHandlerTests.java#L64)提供的链接。
+
+###
+
+我们有[已经讨论过了](../../features/exploits/csrf.html#csrf-considerations-multipart)如何保护多部分请求(文件上传)不受CSRF攻击导致[鸡和蛋](https://en.wikipedia.org/wiki/Chicken_or_the_egg)问题。本节讨论如何在 Servlet 应用程序中实现将CSRF令牌放置在[body](#servlet-csrf-considerations-multipart-body)和[url](#servlet-csrf-considerations-multipart-url)中。
+
+| |关于使用具有 Spring 的多部分表单的更多信息,可以在 Spring 引用的[1.1.11. 多部分旋转变压器](https://docs.spring.io/spring/docs/5.2.x/spring-framework-reference/web.html#mvc-multipart)部分和[MultipartFilter Javadoc](https://docs.spring.io/spring/docs/5.2.x/javadoc-api/org/springframework/web/multipart/support/MultipartFilter.html)中找到。|
+|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+#### 将CSRF标记放入体内
+
+我们有[已经讨论过了](../../features/exploits/csrf.html#csrf-considerations-multipart-body)在主体中放置CSRF标记的权衡。在本节中,我们将讨论如何配置 Spring 安全性,以便从主体读取CSRF。
+
+为了从主体中读取CSRF令牌,在 Spring 安全过滤器之前指定了`MultipartFilter`。在 Spring 安全过滤器之前指定`MultipartFilter`意味着没有调用`MultipartFilter`的授权,这意味着任何人都可以在你的服务器上放置临时文件。但是,只有经过授权的用户才能提交由你的应用程序处理的文件。通常,这是推荐的方法,因为临时文件上传对大多数服务器的影响可以忽略不计。
+
+为了确保`MultipartFilter`是在 Spring 安全过滤器 Java 配置之前指定的,用户可以在SpringSecurityFilterchain之前覆盖,如下所示:
+
+例11.初始化器MultipartFilter
+
+Java
+
+```
+public class SecurityApplicationInitializer extends AbstractSecurityWebApplicationInitializer {
+
+ @Override
+ protected void beforeSpringSecurityFilterChain(ServletContext servletContext) {
+ insertFilters(servletContext, new MultipartFilter());
+ }
+}
+```
+
+Kotlin
+
+```
+class SecurityApplicationInitializer : AbstractSecurityWebApplicationInitializer() {
+ override fun beforeSpringSecurityFilterChain(servletContext: ServletContext?) {
+ insertFilters(servletContext, MultipartFilter())
+ }
+}
+```
+
+为了确保在使用XML配置的 Spring 安全过滤器之前指定`MultipartFilter`,用户可以确保将`MultipartFilter`元素的\元素放置在web.xml中的SpringSecurityFilterchain之前,如下所示:
+
+示例12.web.xml-multipartfilter
+
+```
+
+ MultipartFilter
+ org.springframework.web.multipart.support.MultipartFilter
+
+
+ springSecurityFilterChain
+ org.springframework.web.filter.DelegatingFilterProxy
+
+
+ MultipartFilter
+ /*
+
+
+ springSecurityFilterChain
+ /*
+
+```
+
+#### 在URL中包含CSRF令牌
+
+如果允许未经授权的用户上传临时文件是不可接受的,则另一种选择是将`MultipartFilter`置于 Spring 安全过滤器之后,并将CSRF作为查询参数包含在表单的动作属性中。由于`CsrfToken`被公开为`HttpServletRequest`[请求属性](#servlet-csrf-include),因此我们可以使用它来创建带有CSRF令牌的`action`。下面显示了一个带有JSP的示例。
+
+例13. CSRF令牌正在运行
+
+```
+