Can JSF standard validation prevent code injection?

Question

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.

Answer 1

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:

• How does XSS attacks work?
• How does CSRF attacks work?

Answer 2

Injection attacks have one common theme: input data is transformed and interpreted as code, at some point in time due to various flaws in the application. The most commonly observed flaw is that of unsanitized data that is not encoded or escaped correctly. The presence or absence of encoding alone does not protect an application from attacks - the characters that allow for transformation of code into data must be encoded so that they're not distinguished as code.

Now, from the point of view of JSF, the designers have been thoughtful to include protection against certain kinds of attacks. Since it is a presentation tier framework, protection against XSS attacks (and CSRF attacks, although it is not related to injection) are present. The protection mechanisms and their safe usage is dealt in detail, in the Seam framework pages on Cross Site Scripting and Cross Site Request Forgery. Seam uses JSF, so there isn't a lot of difference in protecting a JSF application and Seam application from XSS and CSRF; most of the advice in those pages are bound to hold good in a JSF application.

However, if you need to protect yourself against other prominent injection attacks, especially SQL injection, you need to look at the features offered by your persistence framework (assuming that you will use one). If you're hand-coding SQL queries and executing them in your code directly, use PreparedStatement objects to protect yourself from the most common varieties of SQL injection. If you are using JPA, JDO etc. you'll need to look at using such frameworks securely - most of them create PreparedStatement objects by default, when queries are fed to them so there is often little need to worry.

Protection against SQL injection attacks in JPA

Named and native queries will be internally converted into a prepared statement that uses parameterized queries. That is the responsibility of the JPA provider. One will need to worry about SQL queries that are constructed before handing off to the provider. Basically the strings passed to EntityManager.createQuery() and EntityManager.createNativeQuery() should not have concatenated user input.

PS: The CSRF protection feature is present in JSF 2, and not in JSF 1.x. It is also present only in certain releases of Seam (2.1.2 onwards).