Advanced CSRF Attacks

[Pankaj Kumar, modificado hace 6 años.]

Hi,

Recently our application scanned for security vulnerabilities and we found below CSRF attack.

IF we hit any url e.g. https://www.test123.com/abc
and its Referer value is :https://www.test123.com/abc

we get 200 response after again second request send then Refere value becomes https://www.caZBVNWhcvAsLEstawS.com/abc
and respone comes 200.

Does Liferay provide any Out of the box property to fix this vulnerabilities.
Currently i am trying to write filter for this to match Host and Refere value .

Thanks & Regards,
Pankaj Semwal

[Olaf Kock, modificado hace 6 años.]

Do you mean: When you send a referrer from another page, you still get results? If you wouldn't you'd prohibit other sites to link to yours.

[Pankaj Kumar, modificado hace 6 años.]

Burp tool is used to scan these urls.
So when Refere values get changed still we get 200 response.

And as per Burp tool recommendation we should do below thing.

To validate that Host and Referer headers in relevant requests are both present and contain the same domain name.
But this approach is somewhat less robust: historically, quirks in browsers and plugins have often enabled attackers to forge cross-domain requests that manipulate these headers to bypass such defenses.

So to do this i wrote filter .Just want to know does Liferay Provide any Out of box things to avoid this security vulnerabilities..

[Jorge Díaz, modificado hace 6 años.]

In my opinion, that doesn't make sense.

If referer domain must match with your own domain, nobody is going to be able to link your page.

All incoming visitors from outside are going to get an error in your custom filter because the referer doesn't match with host

[Pankaj Kumar, modificado hace 6 años.]

But owasp treats its as secuity vulnerability under CSRF attack.Below is the link for same

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Verifying_Same_Origin_with_Standard_Headers

[Jason Roscoe, modificado hace 6 años.]

Is there any update on this post? Is there something already in Liferay to handle this? The default implementation doesn't seem to be a complete block of CSRF. This fix isn’t the best approach and while it somewhat mitigates the vulnerability it introduces a new “Sensitive Value Passed in URL” vulnerability. The CSRF token should be placed in a hidden field within the Post Request.

[Christoph Rabel, modificado hace 6 años.]

Liferay adds a p_auth parameter to urls and forms to mitigate CSRF attacks. (Note: There is also a p_p_auth parameter, but that's not the same!)

What do you mean with:
"The default implementation doesn't seem to be a complete block of CSRF. "

Can you give an example?

[Jason Roscoe, modificado hace 6 años.]

As I stated, while it somewhat mitigates the vulnerability it introduces a new “Sensitive Value Passed in URL” vulnerability. The CSRF token should be placed in a hidden field within the Post Request.

What is recommended is to first determine the origin the request is coming from (CORS Policy) and then implement the CSRF token within a hidden field of the form. More information and a good resource with examples can be found at https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

[Christoph Rabel, modificado hace 6 años.]

I'm sorry, my last comment was wrong/inaccurate. I meant something different and just wanted to say that there is already a CSRF token implementation in Liferay. And this p_auth parameter (the CSRF token) is not added to the url. It is added as a hidden field to forms and checked by Liferay. So, there is no "Sensitive Value Passed in URL” vulnerability introduced.

[Jason Roscoe, modificado hace 6 años.]

Is this different in DXP than in 5.2? We can see in Liferay 5.2 that the p_auth token is in the URL like this:

/login?p_auth=Aja9FfJn

Thanks!

[Christoph Rabel, modificado hace 6 años.]

Hmm. I just checked and found that Liferay still adds the parameter to post urls in forms. I don't think I saw it on get urls, they are pretty clean. I am not that much of an expert in CSRF to say if that's a problem. I always assumed that Liferay is big enough to have an expert on the topic and that I simply can trust them.

Maybe you could open a ticket at issues.liferay.com and state your case? I think that issue can only answered by somebody from Liferay itself.

[Ali Raza, modificado hace 6 años.]

Hi,

I am also have similar kind of issue. Our secuirty team scaned the application and found CSRF attack can be possible. They made a page containing the hidden request of deactive uesr and send the link of tha page to a user who is admin and when he opened the link a request was submitted and a user deactivated. Can somebody help to prevent this type of attacks?

[Olaf Kock, modificado hace 6 años.]

Ali Raza:

I am also have similar kind of issue. Our secuirty team scaned the application and found CSRF attack can be possible. They made a page containing the hidden request of deactive uesr and send the link of tha page to a user who is admin and when he opened the link a request was submitted and a user deactivated. Can somebody help to prevent this type of attacks?

I'm still not sure I understand the problem completely/correctly. However, you might want to report this as security issue. The team will ask for detailed steps to reproduce, but that's your best option.

[Jason Roscoe, modificado hace 6 años.]

Ali Raza:

Hi,

I am also have similar kind of issue. Our secuirty team scaned the application and found CSRF attack can be possible. They made a page containing the hidden request of deactive uesr and send the link of tha page to a user who is admin and when he opened the link a request was submitted and a user deactivated. Can somebody help to prevent this type of attacks?

Ali,

What version of Liferay are you on?