Question on CSRF framework ?

[Kunal_Gaba_]

I have a question related to protection in AEM against CSRF attacks. In AEM 6.1, CSRF framework protection was introduced which checks that all POST requests should have a valid token. The token should be passed in the request body or in the header.

As per the framework, the token is injected into the HTML form pages using granite csrf javascript. The javascript makes an AJAX call to http://localhost:4502/libs/granite/csrf/token.json to get a valid token (which has some expiration time) and then inject it into the form body. 

My question is how this makes sure that client requests are legitimate as the token URL is exposed publicly and anybody can get a new valid token and make forge requests? 

[1] https://docs.adobe.com/docs/en/aem/6-1/develop/security/csrf-protection.html

"The framework makes use of tokens to guarantee that the client request is legitimate. The tokens are generated when the form is sent to the client and validated when the form is sent back to the server."

[smacdonald2008]

I sent this question to some of our ENg members. 

[lkrapf]

Hello kunal23

The CSRF token is bound to the user who requested it and will only be valid to perform POSTs for that user. An attacker cannot get a token for another user and therefore cannot make forged requests on that user's behalf.

Best greetings

Lars

[Kunal_Gaba_]

Thanks Lars. But the token URL is publicly available (/libs/granite/csrf/token.json ) and an attacker can get a new token from it and submit forged requests.  I am able to submit requests with a different user agents and with different tokens. 

[smacdonald2008]

Is that data showing up on a public domain where an attacker can access? 

[lkrapf · Accepted solution]

> But the token URL is publicly available (/libs/granite/csrf/token.json)

Yes. This is correct and by design.

> and an attacker can get a new token from it and submit forged requests.

But, as mentioned above, this token will be bound to the user requesting it and therefore only be valid for requests performed by the attacker (it cannot be used to CSRF another user).

> I am able to submit requests with a different user agents and with different tokens. 

This would obviously be a severe security issue, but I'm not able to reproduce this behavior. Using the CSRF token I seem only to be able to POST as the user that requested the token. 

Do you test with a browser or with curl (note that curl is considered a 'safe' user-agent)? Do you test with two different user-accounts?

If you found a way to circumvent the CSRF protection framework, please contct PSIRT (https://helpx.adobe.com/security/alertus.html) and provide detailed reproduction steps and configurations.

Thanks!

[Opkar_Gill]

Hi Kunal,

CSRF is only required for authenticated users, are you sure the URL you are posting to requires authentication? If it is not, then the CSRF token will be ignored. Can you share the URL you are posting to?

Regards,

Opkar

[Kunal_Gaba_]

Yes I was referring to the unauthenticated users.

Suppose I have a donation form on a page and I want all people to donate money without authentication then how can I prevent CSRF in such a scenario ? Is CSRF really required here ? As per the following thread CSRF protection is indeed required for such use cases - http://security.stackexchange.com/questions/85886/csrf-protection-for-unauthenticated-requests-actio...