diff --git a/docs/manual/src/docbook/csrf.xml b/docs/manual/src/docbook/csrf.xml index 9526f0505d..62233b9d4b 100644 --- a/docs/manual/src/docbook/csrf.xml +++ b/docs/manual/src/docbook/csrf.xml @@ -191,6 +191,57 @@ public class WebSecurityConfig extends One approach is to use a form for log out. If you really want a link, you can use JavaScript to have the link perform a POST (i.e. maybe on a hidden form). For browsers with JavaScript that is disabled, you can optionally have the link take the user to a log out confirmation page that will perform the POST. +
+ Multipart (file upload) + There are two options to using CSRF protection with multipart/form-data. Each option has its tradeoffs. More information about using multipart forms with Spring can be + found within the + 17.10 Spring's multipart (file upload) support + section of the Spring reference. +
+ Placing MultipartFilter before Spring Security + The first option is to ensure that the MultipartFilter is specified before the Spring + Security filter. Specifying the MultipartFilter after the Spring Security filter means that there is no authorization for invoking the + MultipartFilter which means anyone can place temporary files on your server. However, only authorized users will be able to submit a File that is processed + by your application. In general, this is the recommended approach because the temporary file upload should have a negligble impact on most servers. + To ensure MultipartFilter is specified before the Spring Security filter with java configuration, users can override beforeSpringSecurityFilterChain as + shown below: + + To ensure MultipartFilter is specified before the Spring Security filter with XML configuration, users can ensure the <filter-mapping> element + of the MultipartFilter is placed before the springSecurityFilterChain within the web.xml as shown below: + + MultipartFilter + org.springframework.web.multipart.support.MultipartFilter + + + springSecurityFilterChain + org.springframework.web.filter.DelegatingFilterProxy + + + MultipartFilter + /* + + + springSecurityFilterChain + /* + +]]> +
+
+ CSRF token as query parameter + If allowing unauthorized users to upload temporariy files is not acceptable, an alternative is to place the MultipartFilter after the Spring Security + filter and include the CSRF as a query parameter in the action attribute of the form. An example with a jsp is shown below + ]]> + The disadvantage to this approach is that query parameters can be leaked. More genearlly, + it is considered best practice to place sensitive data within the body or headers to ensure it is not leaked. Additional information can be found in + RFC 2616 Section 15.1.3 Encoding Sensitive Information in URI's. +
+
HiddenHttpMethodFilter The HiddenHttpMethodFilter should be placed before the Spring Security filter. In general this is true, but it could have additional implications when @@ -198,7 +249,7 @@ public class WebSecurityConfig extends Note that the HiddenHttpMethodFilter only overrides the HTTP method on a POST, so this is actually unlikely to cause any real problems. However, it is still best practice to ensure it is placed before Spring Security's filters.
- +
Overriding Defaults Spring Security's goal is to provide defaults that protect your users from exploits. This does not mean that you are forced to accept all of its defaults.