Legacy platform

Protecting against the CSRF attacks

You can protect against the CSRF attacks.

Procedure

  1. Open the web.xml file.
  2. 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>
  3. 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) - GET requests are not validated for CSRF token. POST/PUT/UPDATE/DELETE requests are validated for 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>POST</param-value>
</context-param>
    Notes:
    • By default, most of the applications are configured to use only POST as the validator mode. Therefore, GET requests are not validated for CSRF token. POST/PUT/UPDATE/DELETE requests are validated for CSRF token.
    • GET requests are not CSRF protected. Therefore, you must ensure that sensitive dynamic action calls do not use or allow GET requests. Instead, you can use POST as the request method.
    • If you want to retain the configuration of CSRF validator method as ALL, there is a risk of exposing CSRF tokens in the URL for GET requests, which might be logged in various intermittent layers of proxy servers and other network layers.
    • Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties through the referrer header when any off-site links are followed. Placing session and/or CSRF tokens in the URL increases the vulnerability to attacks.
    • The secure way of using CSRF validation is to use it only for POST requests (or equivalent request like PUT/DEL/UPDATE and so on.) and not for GET so that CSRF token is always passed as a POST parameter and not in a query string of URL. If you wish to enable CSRF validation for ALL types of requests, including GET, you can enable it by changing back the CSRF validator mode parameter in web.xml to ALL. However, this is not advised as it increases the risk of exposing CSRF token in URL and thereby in logs as mentioned earlier. Hence, you need to appropriately analyze the risks involved before changing this configuration.
    • If scui-csrf-validator-request-method is set to "ALL", CSRF token will be available in logs.
  4. 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.

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

    By default, most of the actions in the application are configured to allow only POST requests and not GET. Some of actions like login, logout, viewing the about page and landing pages are configured to allow GET requests as well. However, these actions are not sensitive and do not make any modify/delete/update operations at the backend, as part of the request. Hence, they are not CSRF vulnerable.

    If you want to customize any of the screens that are configured to allow GET requests, you should ensure that there are no modify/delete/update operations in the backend either in mashup, API, user-exit or service or any subsequent layers. Otherwise, the actions are CSRF vulnerable.