留言板
Prevent CSRF attack
Hi,
I want to use the authentication token to prevent Cross Site Request Forgery. It should be included in actions requests. I tried to put:
in portal-ext.properties, but unfortunately it didn't work. What is missing? (I'm using Liferay 6.1 GA2)
Regards,
Manish Banwari lal Yadav
I want to use the authentication token to prevent Cross Site Request Forgery. It should be included in actions requests. I tried to put:
auth.token.ignore.actions=
session.enable.url.with.session.id=false
auth.token.check.enabled=true
portlet.add.default.resource.check.enabled=true
auth.token.impl=com.liferay.portal.security.auth.SessionAuthToken
in portal-ext.properties, but unfortunately it didn't work. What is missing? (I'm using Liferay 6.1 GA2)
Regards,
Manish Banwari lal Yadav
Hi Manish,
in 6.1 GA2 the token should be present in action URLs OOTB.
There are 2 whitelists that can prevent adding the p_auth token into URL:
1, auth.token.ignore.actions
2, auth.token.ignore.portlets
What exactly doesn't work?
Best,
-- tom +
in 6.1 GA2 the token should be present in action URLs OOTB.
There are 2 whitelists that can prevent adding the p_auth token into URL:
1, auth.token.ignore.actions
2, auth.token.ignore.portlets
What exactly doesn't work?
Best,
-- tom +
Thanks Tomas for your quick response
Below both properties i'm not using in portal-ext.properties and also checked with empty values for below properties
I'm Using server resource(AJAX) method. for submitting form. Whether any to append that parameter in url for server resource method.
In addition of above i checked in myaccount portlet also.There is no p_auth value in url.
Thanks In Advance
Manish Yadav
Below both properties i'm not using in portal-ext.properties and also checked with empty values for below properties
auth.token.ignore.actions
auth.token.ignore.portlets
I'm Using server resource(AJAX) method. for submitting form. Whether any to append that parameter in url for server resource method.
In addition of above i checked in myaccount portlet also.There is no p_auth value in url.
Thanks In Advance
Manish Yadav
Ahh, got it
You are right, we don't check p_auth in resource serving.
To implement CSRF checking you need 2 things:
1, Include it into URL when submitting
2, Check it on server side and deny access to the resource when the token is invalid
For #1:
In 6.1 GA2 there is a global JS variable named Liferay.authToken. It contains CSRF token you can use from your JS and include it into the resource request call.
For #2:
it's up to you where you check it. Some thoughts:
* I don't think it's a good to check it on a global portal level, this could make portal unstable
* It's better to check it only for your portlet/functionality you want to guard.
To the implementation
- I'd create a portlet filter for the resource phase
- there I'd check the CSRF token - use AuthTokenUtil.getToken(PortalUtil.getHttpServletRequest(resourceRequest)) to obtain the token
You can then only map the filter to portlet(s) you want to guard using the CSRF token.
I hope it would to work, I didn't try it
-- tom +
You are right, we don't check p_auth in resource serving.
To implement CSRF checking you need 2 things:
1, Include it into URL when submitting
2, Check it on server side and deny access to the resource when the token is invalid
For #1:
In 6.1 GA2 there is a global JS variable named Liferay.authToken. It contains CSRF token you can use from your JS and include it into the resource request call.
For #2:
it's up to you where you check it. Some thoughts:
* I don't think it's a good to check it on a global portal level, this could make portal unstable
* It's better to check it only for your portlet/functionality you want to guard.
To the implementation
- I'd create a portlet filter for the resource phase
- there I'd check the CSRF token - use AuthTokenUtil.getToken(PortalUtil.getHttpServletRequest(resourceRequest)) to obtain the token
You can then only map the filter to portlet(s) you want to guard using the CSRF token.
I hope it would to work, I didn't try it
-- tom +
Tomáš,
How it can be implemented for GA1 ?
For #1:
In 6.1 GA2 there is a global JS variable named Liferay.authToken. It contains CSRF token you can use from your JS and include it into the resource request call.
How it can be implemented for GA1 ?
Mihail Zheludev:
Tomáš,
For #1:
In 6.1 GA2 there is a global JS variable named Liferay.authToken. It contains CSRF token you can use from your JS and include it into the resource request call.
How it can be implemented for GA1 ?
It's value of AuthTokenUtil.getToken(request) - https://github.com/liferay/liferay-portal/blob/6.1.1-ga2/portal-web/docroot/html/common/themes/top_js.jspf#L303
To have it the same as it is in 6.1 GA2, I'd create a JSP Hook which runs with each page (as it is with top_js.jspf) and initialize the JS variable there.
You can also put it into Theme that you use or your portlet.
Tomáš Polešovský,
Can you tell, does GA1 implement this protection by default for render and action requests?
Can you tell, does GA1 implement this protection by default for render and action requests?
Mihail Zheludev:
Tomáš Polešovský,
Can you tell, does GA1 implement this protection by default for render and action requests?
Yes, but only for action requests. Portlet render requests should not change portlet state.
We've had a security company run penetration tests on our site and their report indicates that the "Document and media" portlet is vunerable to CSRF attacks.
Does anybody know why "document_library/edit_file_entry" is put under auth.token.ignore.actions? Is it safe to remove this struts action from the ignore list?
Does anybody know why "document_library/edit_file_entry" is put under auth.token.ignore.actions? Is it safe to remove this struts action from the ignore list?
Hi Long,
True.
I don't believe it can be easily bypassed with nowadays browsers (without modifying victim's browser, sniffing traffic, using other vulnerability in browser / portal, etc.).
Can you share your idea on how would such CSRF attack look like?
The token isn't directly related to a server side scripting. It's just a protection against CSRF.
Admins are able to execute the scripting from Control panel Console or you can implement such functionality yourself inside your plugin. See https://www.liferay.com/documentation/liferay-portal/6.2/user-guide/-/ai/using-scripting-for-advanced-flexibilit-liferay-portal-6-2-user-guide-19-en
Long Nguyen Hai:
Tomáš Polešovský:
For #1:
In 6.1 GA2 there is a global JS variable named Liferay.authToken. It contains CSRF token you can use from your JS and include it into the resource request call.
Hi,
As my understand this token might have been implemented as a method of protecting against cross-site request forgeries.
True.
Long Nguyen Hai:
While this method does provide some protection, it is easily bypassed since the token is stored in an object in the JavaScript called Liferay.authToken.
I don't believe it can be easily bypassed with nowadays browsers (without modifying victim's browser, sniffing traffic, using other vulnerability in browser / portal, etc.).
Can you share your idea on how would such CSRF attack look like?
Long Nguyen Hai:
So with this token can users have the server execute Ruby,Python,Javascript,Groovy and Beanshell ?
The token isn't directly related to a server side scripting. It's just a protection against CSRF.
Admins are able to execute the scripting from Control panel Console or you can implement such functionality yourself inside your plugin. See https://www.liferay.com/documentation/liferay-portal/6.2/user-guide/-/ai/using-scripting-for-advanced-flexibilit-liferay-portal-6-2-user-guide-19-en