Background

Cross-Site Request Forgery (CSRF) is a type of web application vulnerability, in which an attacker coerces a user to issue requests via a browser that is already logged into an application. The user may not be aware of what the browser is sending to the server, but the server trusts the request because the user is authenticated.

For details on CSRF vulnerability see:

These kinds of attacks can be defeated by including a token in the request which is known to the browser and the server, but not to the attacker.

Current Protection

The CSRF checking setting in the Admin Console determines the level of CSRF protection on your server:
  • "Admin requests". This is the lowest level of CSRF protection. It guards against CSRF for all key security, permission, and container operations. It also guards actions that require site admin or folder admin permissions.
  • "All POST requests". This more secure setting guards against CSRF for all POST requests (all of the above plus all standard delete, update, and insert operations).
"Admin requests" is the default setting in 18.1 but future releases will change the default to "All POST requests." Eventually, the setting will be removed and CSRF protection will be applied for all POST actions. We strongly recommend that server administrators change the setting to "All POST requests" in 18.1, at a minimum on your test and staging servers, to ensure that all server requests POST the required token. Custom pages, custom actions, and API usage should be tested with this setting in place. Any POST that fails to include the token will fail with a message that states "This request has an invalid security context" and an HTTP response status code of 401 (unauthorized).

Implementation Details

The CSRF checking setting in the Admin Console determines which actions require CSRF verification. Forms that perform an HTTP POST to those actions must include the CSRF token using one of the approaches mentioned below. For example, a form could include the <labkey:csrf /> tag, which renders an <input> into the form that includes the CSRF token:

<input type=hidden name="X-LABKEY-CSRF" value="XXXX" />

The actual value is a randomly generated 32-digit hexadecimal value, associated with that user for the current HTTP session.

Alternatively, the CSRF token value can be sent as an HTTP header named "X-LABKEY-CSRF". LabKey's client APIs, including our Java and JavaScript libraries, automatically set the CSRF HTTP header to ensure that these requests are accepted.

When creating custom forms, developers may need to take steps to ensure the CSRF token is included in the POST:

  • JSP: use <labkey:form> instead of <form>, or include <labkey:csrf /> inside of your <form>.
  • Ext.Ajax: CSRF tokens are automatically included in all POSTs. See ext-patches.js
  • Ext.form.Panel: add this to your items array: {xtype: 'hidden', name: 'X-LABKEY-CSRF', value: LABKEY.CSRF}
  • GWT service endpoint: CSRF tokens are automatically included in all POSTs. See ServiceUtil.configureEndpoint()
NOTE: CSRF tokens are verified for POST requests only, since GET requests should never mutate server state. When coding custom actions, ensure that session or database state is never changed by GET requests.

Related Topics

Discussion

Was this content helpful?

Log in or register an account to provide feedback


previousnext
 
expand all collapse all