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.
Background
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.
LabKey CSRF Protection
LabKey enforces CSRF protection on all "mutating" requests, those that change server state. These state changes can be inserts, updates, or deletes to the database, but also include changes to the file system, server session, and other persisted state. A few examples of protected mutating requests include:
- Insert, import, update, or delete to data tables
- Changes to administrative settings
- Updates to security groups and role assignments
- File uploads and deletes
Every page includes a CSRF token that must be included with each mutating request; if not included, the request will fail immediately with a message that states "This request has an invalid security context".
All custom pages, custom actions, and API usage must use one of the approaches described below to ensure the CSRF token is conveyed with mutating requests.
CSRF tokens are verified for POST requests only, since GET requests should be read only and never mutate server state. When coding custom actions, ensure that session or database state is never changed by GET requests.
Implementation Details
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. See
HTTP Interface for obtaining and using the CSRF token when not using one of LabKey's client APIs.
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>.
- LABKEY.Ajax: CSRF tokens are automatically sent with all requests. See Ajax.js
- Ext.Ajax: CSRF tokens are automatically sent with 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()
Fetching CSRF Tokens
Related Topics