Skip to main content
Kinetic Community

Cross Site Request Forgery Protection

Cross-Site Request Forgery (CSRF) is an exploit where malicious code uses the trust (authentication) of one site to operate on another.

Details

To prevent CSRF, an HTML input element is automatically added to all forms in the application to send a unique token with the form post that can be verified on the server side.  The token is generated on the server for the user session, so it is not possible to guess the value from a remote web site.  In general, no service items need to be modified by the customer as the system is automatically adding the input field to all service items.

This feature comes enabled on new v5.2 installations, but can be disabled by explicitly changing the "Web CSRF Protection" configuration item from the Kinetic Request Service Catalog Console configuration manager page, and setting the value to "DISABLED".

By default, upgraded applications will have this configuration item installed, but the feature will be disabled.  The reason this feature is disabled for upgrades is to give the customer a chance to fix any forms or pages that may need the CSRF input element added.  For most service items, the input field is automatically added by the system.  If the customer has any custom JSP pages that are used for login, those pages will need to be updated as described below in the Bundles section.

 

Configuration Item:  "Web CSRF Protection"

  • If the value is DISABLED, the CSRF protection filter is disabled.
  • If the value is ENABLED, the CSRF protection filter is enabled.

 

Configuration Item: "Web CSRF Whitelist" - Added in v5.2.4

Sometimes a page must be excluded from the CSRF protection for various reasons.  A real world example is the post-back page from a SAML authenticator.  The SAML service cannot be passed a CSRF token, so it cannot pass it back.  The solution is to add the post back page to the whitelist so it is excluded from the CSRF protection filter.

  • The value corresponds to a page in the web application relative to the web application root directory.  So for example, if the value is "/AuthenticationLandingPage.jsp", this would correspond to a file located at <web_server_deployment_directory>/kinetic/AuthenticationLandingPage.jsp.
  • If multiple files need to be added to the whitelist, do not use one configuration value with a filename on separate lines, or separated by any other character.  Simply add one configuration value for each file.

 

Bundles

If CSRF protection is enabled after an upgrade, it may be necessary to make minor changes to the bundles used by Kinetic Request.  This is simply a matter of adding an input field to any html form elements that are submitting as a POST (not including AJAX POST requests).  For most bundles, the only page that will need to be changed is the custom login page JSP.

The CSRF token value can be obtained on the server-side (JSP code) directly from a session attribute, or on the client-side (JS code) from a cookie.  An example of each method is described below.

 

Server-Side Example (JSP)

In a JSP, the token can be obtained directly from a session attribute.

<!-- add a hidden input element to the HTML form, and set the value to the CSRF token session attribute -->
<% if (session.getAttribute("CsrfToken") != null) { %>
<input type="hidden" id="CsrfToken" name="CsrfToken" value="<%=session.getAttribute("CsrfToken")%>"/>
<% } %>

 

Client-Side Example (Javascript)

The form element can also be set from client-side code from the CsrfToken cookie.

<!-- include the Kinetic Core javascript libraries to read the cookie value -->
<script type="text/javascript" src="<%=request.getContextPath()+"/resources/js/kd_core.js"%>"></script>
<!-- add a hidden input element to the HTML form -->
<input type="hidden" id="CsrfToken" name="CsrfToken"/>
// Hook into a onPageLoad javascript event to set the input field value
var tokenEl = document.getElementById("CsrfToken");
tokenEl.setAttribute("value", KD.utils.Util.getCookie("CsrfToken"));

This method would apply to implementations that are using Template login service items that define the login form in a dynamic text element rather than a JSP page.  

 

Force Password Change

The system default catalog contains a service item named "Force Password Change".  This service item is used as a form to collect the user's new password information when the Remedy server determines the password has expired.  Included is an updated 'Force Password Change' service item template that contains code to insert the CSRF token.  This updated template will be imported automatically into the System Defaults catalog during the setup process.

If any existing catalogs contain a custom Force Password Change service item to override the system default, each of these templates will require the CsrfToken as explained above in the Bundles section.  You can simply copy the code from the template in the System Defaults catalog, or from the syntax in the example above.