Cross-Site Request Forgery

A cross-site request forgery (CSRF) attack works by exploiting the trust between a website and the user. Here, the attacker guesses that a user might be logged on to a secure website.

 

If the guess is correct, then the user’s browser session will contain some sort of authentication or session cookie.

 

In the figure, the attacker sends the victim an e-mail inviting him to visit his fraudulent website and guesses that the victim’s browser still contains a valid authentication cookie, so he does the following:

• Constructs a request to the online banking service to transfer some money
• Hides the request URL as the src parameter of an <img> tag

 

When the browser issues the URL to fetch the “image”, the valid authentication cookie unknowingly authenticates the fraudulent request.

 

 

 

The Solution

The token is stored as a cookie and must be returned in all subsequent requests.

 

The attacker can deduce that such a token is required, but cannot possibly know the token’s value because the coding to generate the fraudulent request executes on the hacker’s webserver – where it has no access to the browser’s cookies.

 

Fetch CSRF Token Value

The CSRF protection mechanism for all state-modifying requests (POST, PUT, DELETE) requires an X-CSRF-Token along with an asap-XSRF_<SID>_<Client> cookie. The token is encrypted and stored as part of the anti-CSRF cookie. It is bound to a certain user and is validated against a value of the anti-CSRF cookie.

 

To receive a token, send the following HTTP header with a GET request: X-CSRF-Token: Fetch

 

The lifetime of a token is bound to the lifetime of the session cookie.

 

The gateway returns the following header if the token expires: X-CSRF-Token: Required

 

 

PUT Request With X-CSRF-Token

The figure shows an example of an HTTP PUT request that uses a CSRF token.

 

The server responds with an HTTP 204 response status code if successful. The body of the HTTP response is empty.

 

 

Gateway Client Handling of CSRF Tokens

When testing OData services using the SAP Gateway client, the developer does not have to bother with the handling of CSRF tokens.

 

The SAP Gateway client automatically fetches a token and sends it along with an update request as shown in the figure.

 

 

Confidential Data Handling

Some services may return confidential or person related data, where the user agent is involved, and this data might implicitly be cached depending on the user's setting.

To remove this behavior, SAP Gateway can instruct the user agent not to cache specific data if needed.

 

To avoid caching of confidential data, all GET methods returning such data must set the Cache-Control header by using the method, /IWBEP/IF_MGW_CONV_SRV_RUNTIME~SET_HEADER().

 

data: ls_header type ihttpnvp.
ls_header-name = 'Cache-Control'.
ls_header-value = 'no-cache, no-store'.
ls_header-name = 'Pragma'.
ls_header-value = 'no-cache'.
set_header( ls_header ).

You can do this either directly or in a private method, such as no_cache(), which is called whenever necessary.

 

Confidential Data Contained in URL Parameters

Confidential data might be contained in URL parameters, for example, if a query is performed for a credit card using the card number as a query parameter.

 

Even if HTTPS is being used, the query parameters are not secured as part of the URL and could potentially be retrieved from server logs where the HTTPS connection of a request gets terminated.

 

If such a request is sent via $batch, the URL becomes part of the HTTP payload and gets secured via HTTPS.