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.
Related
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?
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 developing a small frontend application project with JavaServer Faces, I have to implement client side and server side validation. I'm using also Prime Faces, this framework that has client side validation and Bean validation. My qu4estions is this:
Is bean validation considered server side, since user's data is validated in the backing bean (Managed bean) or due to JSF works as MVC model in the front end, this is not considered server side and other techniques should be used.
Supposing Bean validation is not properly server side validation, what are the best ways to implement server side validation.
Any advice and clarification is welcome.
Thanks!
'Bean validation' is a proper server-side validation which is one of a number of validations that you can use in JSF. JSF has long has its own validations in the view but since JSR-303, Bean validation, was introduced, that is supported as well and many validations could be removed from the 'view' to the model.
Bean-validation is not the same as and should not be confused with doing manual validation in managed beans when e.g. calling setters or action methods. The 'validation' phase of JSF has then already passed, so returning messages becomes more difficult.
Since not everyting can be (easily) done in JSF-303, there sometimes still needs to be additional validations in JSF specific ones.
PrimeFaces client-side validation should be seen as an addition to the server side validations, it does not replace them. It can use many of the existing JSF and JSR-303 validations and antomaticaly execute them client-side without any work from you. For more complex validations, custom client-side validations should be developed as you'd need to with client-side frameworks as well.
From the PrimeFaces documentation:
PrimeFaces Client Side Validation (CSV) Framework is the most complete
and advanced CSV solution for JavaServer Faces and Java EE. CSV
support for JSF is not an easy task, it is not simple as integrating a
3rd party javascript plugin as JSF has its own lifecycle, concepts
like conversion and then validation, partial processing, facesmessages
and many more. Real CSV for JSF should be compatible with server side
implementation, should do what JSF does, so that users do not
experience difference behaviors on client side and server side.
Compatible with Server Side Implementation.
Conversion and Validation happens at client side.
Partial Process&Update support for Ajax.
I18n support along with component specific messages.
Client side Renderers for message components.
Easy to write custom client converters and validators.
Global or Component based enable/disable.
Advanced Bean Validation Integration.
Little footprint using HTML5.
So it is not a question of client-side OR server-side but whether you want/can use client-side validations to enhance user-experience so some of the (very few) downsides of JSF (round-trips for validations) is reduced.
Validations done in the Java Code(Managed Bean) on the server are server side validations.
Another direct means of validation could be f:validate (Refer)
My understandings are that JSF originally has implicit CSRF countermeasures, which is javax.faces.ViewState, to POST request. If bad person infers or defaces javax.faces.ViewState value, JSF cannot restore the component tree and throws ViewExpiredException.
JSF 2.2 introduces stateless view.
And I noticed that if I modifies javax.faces.ViewState's hidden value in HTML to stateless, JSF silently accept that value and functions as stateless mode.
Does this means that implicit tolerance of CSRF, which stems from javax.faces.ViewState, is lost in JSF 2.2?
Or do I misunderstand something?
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