CSRF

CSRF Protection, Cookie and Header

Web technologies that use cookies for maintaining sessions are vulnerable to Cross Site Request Forgery. These types of attacks allow malicious sites to make requests on the behalf of unsuspecting users.

As an example a potential attack vector to could inline the following HTML content:

<img href="http://bank.com/transfer.do?acct=MARIA&amount=100000">

When visiting a page with the example code, the browser will automatically attempt to fetch the image data defined within the HREF tag. Instead a GET request is sent to the bank.com domain, CSRF attacks use the vulnerability that if a user is logged in to bank.com and the site allows simple API transactions such as the example, the request will automatically execute since the request domain matches the real domain and domain bound to the cookie.

To prevent these requests Jarvis supports CSRF protection using the following procedure:

1. A unique token is generated and stored alongside a user’s session when they log in via Jarvis.
2. The client is served this token in a CSRF cookie alongside their normal session cookie.
3. When sending a request to Jarvis, the client must then include the CSRF token in the request headers. This may only be performed by JavaScript, and hence protects against the CSRF attack.
4. Jarvis will compare the CSRF token in the provided request headers with the value stored against the session and reject any requests that either do not match or do not contain CSRF token headers.