views:

35

answers:

2

In my project, I do duplicate validation at the presentation layer as well as the persistence layer with the hope to increase security. So my question is: can standard JSF validation prevent code injections.

<h:inputText id="name" value="#{bean.customer.name}" required="true" requiredMessage="Validation Error: Value is required." title="Name" >
      <f:validateLength maximum="40"/>
</h:inputText>

Here I validate if the field is empty, and validate field length. I know validate field length will make it harder to do code injection, but sometimes you need a long field length, such as textArea. And if this is vulnerable, how will I fix it? Thank you so much in advance.

+3  A: 

JSF by default already prevents XSS attacks by escaping user-controlled input in UIInput and UIOutput components. This is controllable in h:outputText by setting escape="false" attribute. You don't need to worry about this.

Prevention against SQL injection attacks, on the other hand, is not the responsibility of JSF. You need to handle this in the persistence layer. For example JPA and/or Hibernate, when well used (i.e. do not concatenate user-controlled input in SQL/named query strings), also by default already prevents it. In plain vanilla JDBC, you need to ensure that you're using PreparedStatement instead of Statement to include user-controlled input in a SQL string. When well used, you also don't need to worry about this in JSF side.

Related questions:

BalusC
This make me feel much better. :D Thank you +1
Harry Pham
Oh nice, I was keying in my answer and there comes your answer. My day is doomed!!
Vineet Reynolds
Is this considered a `concatenate user-controlled input in SQL/named query strings`: `@NamedQuery(name="Customer.delete", query="delete from Customer c where c.id = :id")`, then I would pass a string `customerId` as a parameter to method in session bean, then do this `query.setParameter("id", new Long(customerId));`
Harry Pham
No, those are named/parameterized queries. That's absolutely fine. They will be escaped. With concatenating I mean more like: `"delete from Customer c where c.id = " + customerId`.
BalusC
@Harry, the named query will be internally converted into a prepared statement that uses parameterized queries. That is the responsibility of the JPA provider. You'll need to worry about native SQL queries that you construct before handing off to the provider. Basically the strings passed to EntityManager.createQuery() and EntityManager.createNativeQuery() should not have concatenated user input.
Vineet Reynolds
Thank you guys :D. +1 for both comments
Harry Pham
+1  A: 
Vineet Reynolds
awesome post. I am using JPA 2.0 btw. Most of my query involve `"@NamedQuery(name="...", query="... :id"`, then in session bean I would do `query.setParameter("id", new Long(Id));` where `Id` is a string I pass down from my managed bean. That should be ok, correct? Sorry but I can only up vote you, since BalusC definitely post first. I hope this post attract more traffic so you post can get more up vote.
Harry Pham
I saw your comment up there. Thank you :D
Harry Pham
@Harry, I'm a bit sluggish today. BalusC's answer deserves to be marked as correct. Glad to be of help :-)
Vineet Reynolds