I been working in a project with JSF 2.2 and a requeriment is to pass the Acunetix vulnerabilities validation.
I active protected-views (https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/JSF-CSRF-Demo/JSF2.2CsrfDemo.html) but still the validator says that the site isnt protected for CSRF attacks.
In the documentation says that I need a input hidden for POST request, but in JSF 2.2 says that with protected-views activated its Ok.
Do you know how to solve this problem? Do you have an implementation to solve this?
Related
In our JSF application we can see the below cookies :-
oam.Flash.RENDERMAP.TOKEN
oam.Flash.REDIRECT
Can someone please tell how these cookies can be made secure and HttpOnly. I am using tomcat.
thanks
The answer to this question is that it 'just works' in recent MyFaces versions (2.2.4 and up). A very simple search in a search engine helped me finding it.
https://issues.apache.org/jira/browse/MYFACES-3639
I am using Liferay 6.2-ce-ga3, primefaces 6 and JSF2.1. I have enabled CSRF protection for my portlet adding the follow code in liferay portal-ext.properties and portlet portal-ext.properties:
auth.token.check.enabled=true
auth.token.impl=com.liferay.portal.security.auth.SessionAuthToken
futhermore, I've added in portlet.xml
<init-param>
<name>check-auth-token</name>
<value>true</value>
</init-param>
For test, I removed p_auth=<code> from my form url then I submitted the form and it's worked. That's not good, I't should not allow the request without the token.
did I forget add a filter in configuration?
how liferay check the p_auth?
should I check manually p_auth token in my bean like this tutorial?
Liferay's p_auth token protects against CSRF during the ACTION_PHASE of the portlet lifecycle. I believe that it is enabled by default in Liferay 6.2, so you shouldn't need to configure anything for it.
The p_auth token must be present for a form to submit without error during the ACTION_PHASE. However, the p_auth parameter has no effect during the RESOURCE_PHASE which is the phase where JSF Ajax form submissions are executed. So you may be dealing with a JSF Ajax request. Thankfully, JSF also has its own CSRF protection enabled by default in the view state. So you are safe from CSRF with both Ajax and non-Ajax form submissions when you use Liferay Faces.
If you confirm that p_auth has no effect during a non-Ajax form submission, there may be a security vulnerability (or an issue with your configuration). You should update to the latest version of Liferay Portal* and retest. If you are still having issues, report a secure issue: https://issues.liferay.com/secure/CreateIssue.jspa?pid=10952&issuetype=1.
*Liferay Portal 6.2 GA6 is the latest in the 6.2 line, and Liferay Portal 7.0 GA7 is the latest CE release overall. Of course there are EE releases that may have more bug fixes as well.
I am researching stuff I hear regularly that when doing a webapp in JSF 2.0 you are already protected from crossite - scripting and - request forgery. The following excerpt from a SO post confirms this:
In JSF 2.0 this has been improved by using a long and strong autogenerated value instead of a rather predictable sequence value and thus making it a robust CSRF prevention.
Can someone provide some more detail on this? How does this autogenerated value prevent CSRF? Thanks!
How does this autogenerated value prevent CSRF ?
Because it cannot be guessed. So the attacker cannot hardcode it in a hidden field in a form of the attack website (unless the target site has a XSS hole and thus the value can simply be obtained directly by XSS means). If the value is not valid for JSF, then the form submit from the attack website will simply not be processed but instead generate a ViewExpiredException. Please note that the attacker would still need to get the session ID so that it can be passed back through jsessionid URL attribute, so the originally "weak" CSRF protection would still require some XSS hole to obtain the session ID.
After all, I have the impression that you do not understand at all what CSRF is; the answer is rather self-explaining if you understand what CSRF is. In that case, please check the following question: Am I under risk of CSRF attacks in a POST form that doesn't require the user to be logged in?
One thing to remember is that the CSRF-protection in JSF 2.0 is implicit and is only valid for POST requests.
In JSF 2.2 there will be more explicit support for this. I briefly explained this here: http://arjan-tijms.omnifaces.org/p/jsf-22.html
I know that this question seems to be answered by a lot of other threads, but I can't find a solution with JSF 2.0 with Glassfish 3.0.1 for logout an user.
I tried either with a BASIC authentication and FORM authentication using j_security_check as action.
But for the logout method I can't find any of them that works.
I tried using a servlet with session.invalidate(), i used a managed bean tring to invalide the session, but nothing happened. I also tried with j_security_logout without success.
Does someone know what I can do for logout an user?
Calling session.invalidate() should work.
Your problem is probably that you used the browser back button to view a restricted page to test if logout really succeeded, but that page was actually served from the browser cache instead of straight from the webserver over a real HTTP connection.
In that case, you need to instruct the webbrowser to not cache the restricted pages. This way the browser will always request the page straight from the webserver. You can do this with help of a Filter. You can find an example in this question: Prevent user from seeing previously visited secured page after logout
CSRF protection for a JSF based web app and Tomcat6 backend without using any external packages.
Kindly help.
JSF has already builtin protection against CSRF by the javax.faces.ViewState hidden field which is to be linked with the state of the component tree in the server side. If this hidden field is missing or contains a wrong value, then JSF simply won't process the POST request. On JSF 1.x the key is only a bit too easy to guess, see also JSF impl issue 812 and JSF spec issue 869. This is fixed in JSF 2.1.
Your major concern should be XSS. A succesful XSS attack can form a source for a guaranteed-to-be-succesful CSRF attack. To avoid XSS, ensure that you don't redisplay user-controlled input with <h:outputText escape="false" />. Other than that, JSF will already by default escape HTML entities.