How does CSRF token work? SAP Gateway

[grabz]

Update 2021-06-25: making the diagrams more precise & explicitly writing that the CSRF token is for one user session.

Update 2021-09-28: explaining cookies in more detail.

---

"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated." OWASP Cross Site Request Forgery (CSRF)

Issues come really often about CSRF token validations where developers receive errors like:

403 Forbidden CSRF Token required

403 Forbidden CSRF Token expired

The aim of this Blog is to explain how CSRF token protection works in SAP Gateway and how should developers implement it.

The ideal flow is like the following:

1. The client application sends a GET request with header X-CSRF-TOKEN: Fetch (this is usually sent in the $metadata or in a simple service document request).


2. The server then responds with 200 OK and response header: X-CSRF-TOKEN: <tokenValue> and one or more Set-Cookie headers (not highlighted below)


3. The client has to store this token and all the cookies in the Set-Cookie response header (the cookie here identifies the HTTP session) and send in every modification request* throughout its session. When the session renews the CSRF token has to be renewed as well, by requesting a token again.
   *A modification request, is a non-GET request like POST, PUT, PATCH, MERGE, DELETE (CUD). Note, that $batch requests are always sent with POST method.


4. The server will check this token and the session ID cookie(s) and if they're valid and matching, it'll process the request. If at least one of them is invalid or expired then the server will respond with 403 Forbidden, with response header: X-CSRF-TOKEN: Required, with response body: "CSRF Token required"


5. The client has to automatically send a new GET request with X-CSRF-TOKEN: Fetch and retrieve the new token from the response header.

So the successful scenario would look like this (Set-Cookie + Cookie isn't present in the diagram):

CSRF Token - Successful

And the scenario where it fails once and the client has to re-request the CSRF token would look like this (Set-Cookie + Cookie isn't present in the diagram):

CSRF Token - Failure

[christian102094]

Thanks for the blog Akos.

I understand that the "session" between the fetch request and the modification request has to be the same. In other words, cookies has to be shared. Is this right?

Best regards.

[grabz]

Hi Christian,

With regards to the CSRF token itself only, it doesn't matter how you work with the cookies. When the Gateway checks the CSRF token, it checks only that and nothing else. So it won't check for a session ID or anything like that. But if your question is about the "share-ability" of a CSRF token between different users, then the answer is that a user must send the token that it received. If the user is sending the token of another user then it'll fail.

Hope this answers your question.

Best regards,
Ákos

[grabz]

ctapisab I've just updated my reply to be more precise. Let me know if you have any further questions.

[waynesmith]

The CSRF Token has to be requested and fetch on the fist call to the Gateway Server
then on every call there after the CSRF Token has to be sent back on every Call when doing
any PUT calls as an example. The CSRF Token in general is in and is part of the Cookie
and part of the HEADER. thou there are other ways to present the Cookie see the Link below

If there is any changes to the Connection it will fail
If the CSRF Token is not in the Cookie it will fail
If the Connection is closed and reopened it will fail

One Area you have to be careful with is redirecting the URL this can also cause
the CSRF Token to be invalidated

You can trace this calls in SAP Gateway Server via t-code SMICM and see the error messages

CSRF Tokens are session based once the connection is closed or the user disconnect

          a new request for the CSRF Token has to be done again

 

There are different methods of handling the CSRF Token

For this I would recommend taking a look at the following

SAP Help Web Page on how to

Using the CSRF Token - SAP Help Portal

Great Write up Akos thank you for creating this very helpful

 

 

 

[Pavan_Golesar]

Wow, Thanks for good post, I came across recently to this good post on same lines:

https://www.youtube.com/watch?v=a4xM5PbVNv0

 

 

[waynesmith]

One other note, if you do a GET request you will not see the CSRF Token.

Get request do not trigger the generation request for a CSRF Token as it is a Read only request.

If you do any other request PUT, DELETE and so on then you will get the CSRF Token.

 

 

[CH06]

Hello, I am a little confused, so ask for some clarification.

If I know a UserID and Password, then I can always do a GET (e.g. $metadata) to have a new xCSRF Token, and then I can always do a POST immediately afterwards using the same xCSRF Token, UserID and Password.

I am confused as to how imposing this additional -- apparently pointless -- step adds any security whatsoever in the context of REST / OData using Basic Authentication?

It does however, I admit, add a great deal of complexity (depending on your REST Client implementation)...

Regards, Cameron

 

[grabz]

Hi Cameron,

I agree regarding the complexity. I tried to write together an example for you, but then I found this OWASP cheat sheet which explains this properly:

"Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site when the user is authenticated. A CSRF attack works because browser requests automatically include all cookies including session cookies. Therefore, if the user is authenticated to the site, the site cannot distinguish between legitimate authorized requests and forged authenticated requests."

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.htm...

[CH06]

Thanks akos.grabecz for this response, but it does not however answer my question:

If I know a UserID and Password, then I can ALWAYS do a GET (e.g. $metadata) to have a new xCSRF Token and associated Session Cookie, and then I can ALWAYS do a POST immediately afterwards using the same xCSRF Token, Session Cookie, UserID and Password.

How does imposing this additional GET step add any security whatsoever in the context of REST / OData using Basic Authentication?

Regards, Cameron

[grabz]

Hi Cameron,

One part of the secret relies in the nature of HTTPS which doesn't encrypt the request method and the URL, but it does encrypt the headers and the body. As you're sending the CSRF token as a request header, the attacker cannot decrypt it. This type of attack is to exploit the bolded part above which is "browser requests automatically include all cookies including session cookies." But with CSRF protection you do not rely only on your session cookie anymore, but on your session cookie (browser provides <-- problem!) + your CSRF token (inaccessible for an attacker). There are other techniques as well, like using the SameSite cookie, which you can read more about here: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.htm...

[former_member631508]

Hello again akos.grabecz. I am sorry to say that I remain confused about the benefits of CSRF in the context of HttpS. As you state, "your CSRF token [is] (inaccessible for an attacker)" owing to the fact that HttpS "does encrypt the headers and the body".

As you are no doubt aware, Session Cookies are equally passed via Headers, and are encrypted at the same time and in the same way as the CSRF Token ?

If a hacker ever manages to get access to the Session Cookie -- despite HttpS -- then they also will have acces to the CSRF Token ?

Regards, Cameron HUNT

[grabz]

Hi cameron.hunt

Now I see that I didn't answer your question correctly, sorry. If the attacker already knows the username and password then CSRF token protection cannot help. This type of prevention is for a vulnerability when the attacker doesn't even have to know the credentials, but still can do bad stuff.

And if I understand your recent question correctly then you ask if the CSRF cookie and CSRF header are the same value or not. Actually unfortunately in some implementation they are indeed the same which is indeed not the best. It's better if they can have different values.

Regards, Ákos

[babuilyas]

It helped in postman testing. Thanks for the blog and diagrams.

[grabz]

I'm glad that it helped you Muhammad.

[LinglingQian]

Hi Akos,

Our system is the SAP S/4HANA Cloud, public edition. I know that tokens that remain inactive for 30 minutes will become invalid. May I ask how long this token can be used if it remains active?

Thanks,

Lingling

[grabz]

Hi Lingling,

This is a great question, thanks for raising it! The default is 24 hour, however this can be customized. Disclosure: This information might not be up to date since I left this product area for quite some time.

Thanks,
Ákos

[LinglingQian]

Hi Ákos,

Thank you, the default is 24 hours. You said it can be modified. May I ask what this parameter is?  i only know   http://security_session_timeout

Thanks,

Lingling

[grabz]

Hi Lingling,

Unfortunately I'm not sure about the exact parameter name. I suggest to open a support ticket on component: BC-SEC or maybe BC-MID-ICF

Best regards,
Ákos

[LinglingQian]

Hi Ákos,

Thanks, i will create a tickent,

[grabz]

To be more precise: even though the Gateway itself doesn't check for the matching cookie, the session cookie has to be sent, but the check for their matching happens on the ICF level (before the GW).

[shreyashagrwl]

Hi Akos,

Thanks for explaining this. I do have a question, since CSRF token validation process involves a Cookie usage, does it not make the whole process stateful which contradicts OData concept of being stateless?

Thanks,

Shreyash