Web UI framework security - protecting against CSRF attacks

Use this procedure in the Web UI framework to protect against CSRF attacks.

Procedure

Open the web.xml file.
To validate the token that is used to protect against CSRF attacks, create a request validator that will be registered in the application (if the validator is not already present in the web.xml file).
Example:
```
<context-param>
  <param-name>scui-request-validator-10</param-name>
  <param-value>
com.sterlingcommerce.ui.web.platform.security.SCUICSRFTokenValidator
  </param-value>
</context-param>
```
Set up the modes in which the validator can operate:
- ALL - Both POST and GET requests will be validated for the CSRF token.
- POST (default) - Only POST requests will be validated for the CSRF token.
- NONE - The validator will not validate any request for the CSRF token.
You can specify the validator mode in the context parameter of either the config.xml file or the web.xml file (if the validator mode is not already present in the web.xml file).

The mode defaults to POST if the mode is not specified or if a context parameter is not specified for the validate mode. IBM® recommends using POST mode for validating requests.

Example:
```
<context-param>
   <param-name>scui-csrf-validator-request-method</param-name>
   <param-value>ALL</param-value>
</context-param>
```
If necessary, set up URI (Universal Resource Indicator) inclusion and exclusion lists for the validator, using the following guidelines:
- If a URI is on the exclusion list, it will not be validated for the CSRF token.
- If a URI is on the inclusion list, and is not on the exclusion list, it will be validated for the CSRF token.
Use the following context parameters in the web.xml file to create inclusion and exclusion lists. Any number of parameters can be provided.
- csrf-include-uri
  Any request with a URI that is the same as the value is validated for the CSRF token.
  
  Example (for web.xml):
```
<context-param>
   <param-name>csrf.include.uri.endswith.stk.1</param-name>
   <param-value>.do</param-value>
</context-param>
```
- csrf-include-uri-endswith
  Any request with a URI that ends with the value is validated for the CSRF token.
  
  Example (for web.xml):
```
<context-param>
  <param-name>csrf.include.uri.endswith.stk.2</param-name>
  <param-value>.xml</param-value>
</context-param>
```
- csrf-include-uri-regex
  Any request with a URI that matches the regex (provided as a value for the parameter) is validated for the CSRF token.
  
  Example (for web.xml):
```
<context-param>
  <param-name>csrf.include.uri.stk.1</param-name>
  <param-value>/stk/home.jsp</param-value>
</context-param>
```
- csrf-bypass-uri
  Any request with a URI that matches the value is bypassed and not checked for the CSRF token.
  
  Example (for web.xml):
```
<context-param>
  <param-name>csrf.bypass.uri.stk.1</param-name>
  <param-value>/console/login.jsp</param-value>
</context-param>
```
- csrf-bypass-uri-endswith
  Any request with a URI that ends with the value is bypassed
  
  Example (for web.xml):
```
<context-param>
   <param-name>csrf.bypass.uri.endswith.stk.1</param-name>
   <param-value>.js</param-value>
</context-param>
```
- csrf-bypass-uri-regex
  Any request with a URI that matches the regex (provided as a value for the parameter) is not checked for the CSRF token.
  
  Example (for web.xml):
```
<context-param>
   <param-name>csrf.bypass.uri.regex.stk.1</param-name>
   <param-value>[a-zA-Z0-0]*servlet/param-value> 
</context-param>
```
By default, all URIs are in the inclusion list, even if a csrf-include parameter is not provided. You must explicitly specify that a URI is in the exclusion list. If no inclusion list is provided, by default all URIs are considered to be in the inclusion list. Specific URIs can be added to an inclusion list by the application to avoid all URIs being validated for the CSRF token.

By default, the framework provides an exclusion list to bypass CSRF validation for requests for gif, png, css, or js-type files.
Most CSRF attacks work just by replicating POST requests into its GET equivalent. Because most applications do not differentiate between POST and GET requests, the attacks usually work. To differentiate between GET and POST requests, in your Struts action definitions, set up the modes in which the validator can operate, using the requestMethodSupported parameter of the action:
- POST - (default) Only POST requests are allowed.
  If requestMethodSupported is not set or is an unknown value, then it defaults to POST.
- ALL - Both GET and POST requests are allowed.
Example:
```
<action name="accountTransfer" class="com.AccountTransfer">
  <param name="requestMethodSupported">POST</param>
  <param name="resourceId">AccountTransfer_Action002</param>
</action> 
```