Expand my Community achievements bar.

csrf enabled but empty through /libs/granite/csrf/token.json

Avatar

Level 1

Hi,

I have two questions regarding CSRF in AEM 6.1 which we recently migrated to.

Question 1. Empty CSRF token. 

Locally, when accessing http://127.0.0.1:4502/libs/granite/csrf/token.json I can see a json object with "token" key, like

{ token:"eyJle.........Gec" }

However, on the server, when I go to the /libs/granite/csrf/token.json, it returns an empty json { }.

The fact that I can get to the location means dispatcher is configured correctly to get to the url, and caching shouldn't be a problem. Double checked OSGi modules, and it seems csrf modules are all active. Where should I be looking that generates the token?

Question 2. CSRF architecture.

Why having granite.jquery to ajax load a csrf token via the URL and post via http header? If a public api is available to expose such token, a 3rd party can still inject client side script to request a legit token on client side and still get a legit csrf key for the client. That defeats the purpose of csrf protection from my understanding. Please correct me if I'm wrong (which I hope I am). 

Thanks,

Jason

10 Replies

Avatar

Employee Advisor

Question 1- Do you see any exceptions in the log when you access the URL on the server ? Have you replicated the crypto key under /etc/keys to all of your publish instances https://docs.adobe.com/docs/en/aem/6-1/develop/security/csrf-protection.html ? The token is generated by CSRF servlet which is part of com.adobe.granite.csrf bundle. 

Question 2 - First, the CSRF in AEM is only meant to be used for authenticated requests and not for public anonymous users request. You are right when you say that a third party can get the token when it can inject a javscript code to get the legit token. But doesn't that mean you have an open door for the third party to inject the javascript code via XSS (cross site scripting attack). If you are protected from XSS by escaping the form inputs and using the Antisamy filter then a third party won't be able to inject the code in the first place. https://docs.adobe.com/docs/en/cq/5-6-1/deploying/security_checklist.html#Protect%20against%20Cross-...

Avatar

Level 3

Jason,

 

Did you resolve your first issue?

I have a situation where the csrf token is empty ("{}") when I make an unauthenticated call to /libs/granite/csrf/token.json.  However, when making an authenticated call I receive a token as expected:  

{"token":"ey....U0"}

 

Thanks,

 

Rob.

Avatar

Employee

Hi,

CSRF is checked server side or authenticated users, so an unauthenticated call for the token will result in an empty token.

Regards,

Opkar

Avatar

Level 3

Thanks Opkar.

I had just done some more reading and came to the same conclusion.  I was just about to answer my own question.

Thanks again for your reply.

Rob.

Avatar

Level 4

Hi,

Stupid question but if this is for authenticated users only what should we do for anonymous users ?

Chris 

Avatar

Level 4

Hi Opkar,

How would it work for forms on public websites? Since public websites does not need any authentication and any anonymous user can submit the form. If csrf does not generate for this form then form is susceptible for attack.

We can though implement captcha on these forms but I am curious to know if there is any OOTB solution for this kind of scenario?

 

Thanks,

Rajeev

Avatar

Level 2

I second this. It makes no sense to require the 'csrf.token' for unauthenticated users as 'token.json' returns an empty response. There should be a way to allow csrf generation even for these types of users.

Avatar

Level 3

Hi Rajeev

Did you get any solution for this? We are also working on a similar issue where bot attacks are happening on our application's public forms. We are planning to contact Security team but would be great to know if AEM provides any OOTB solution for the same.

Thanks

Dipti

Avatar

Level 2

Hi Opkar,

I am exactly facing the same issue but it is showing empty when logged in authenticated user i.e admin. 

Any inputs would be appreciated.

Thanks,
Keerthi.