tags:

views:

277

answers:

4

I read somewhere the view ids used by JSF framework have a happy side effect of acting as request tokens and thus foiling CSRF. Can someone please tell me if this means I dont have to do anything from a programming point of view (ie). As a programmer, if I use JSF I dont have to worry about CSRF?

+2  A: 

JSF has indeed "builtin" protection against CSRF by the javax.faces.ViewState. On JSF 1.x it's is only maybe "too easy" to guess. This has been fixed for JSF 2.1. See also JSF impl issue 812 and JSF spec issue 869.

Your major concerns should be XSS and SQL injections. An succesful XSS attack would be a source for a guaranteed-to-be-succesful CSRF attack. To avoid XSS, ensure that you're (re)displaying all user-controlled input using h:outputText rather than as "plain vanilla" template text. A SQL injection doesn't necessarily lead to potential CSRF holes, but it would leak or malform sensitive data. To avoid this, ensure that you're using a solid ORM framework which makes use of named queries (JPA, Hibernate, etc) or when you're on "plain vanilla" JDBC, ensure that you're using PreparedStatement instead of Statement all the way.

BalusC
Are you saying just outputting text via facelets (ie #{text}) doesn't implicitly wrap it in an h:outputText so that it is encoded and thus not vulnerable to XSS?
GreenieMeanie
@Greenie: Facelets indeed implicitly escapes template text. I was more talking in JSP context, sorry for the confusion.
BalusC
"ensure that you're using PreparedStatement instead of Statement all the way." - is this for added security, pure performance or both?
JamesC
@JamesC: Primarily security. Assuming that you're using it properly. I.e. don't concat user-controlled values in SQL before creating the preparedstatement.
BalusC
A: 

Is this guaranteed? Some implementations of JSF uses a sequential id that can be guessed by an attacker.

Here's an article describing the Sun JSF-RI doing sequential view id generation instead of the more accepted Java SecureRandom:

http://seamframework.org/Documentation/CrossSiteRequestForgery

Patrick
A: 

Sorry for asking a question in the old thread. I have tested a JSF application with the CSRFtester tool, and the tool didnt report any CSRF problems. But I had read in the "OWASP_Top_10_2007_for_JEE.pdf", that all Java EE web application frameworks are vulnerable to CSRF and also some says we need to create a secret key for each session and append it to the url. By doing this way we can secure our JSF application from the CSRF attack.This makes me confused. I cannot find any clear documentation. IS JSF is vulnerable to CSRF attack? What was the right way? Please help me out!!

Thanks in Advance!!

giftsam
A: 

Hi Baluc,

Sorry on the other day, I was wrong "I told that My JSF application didnt report any CSRF problem". But now I would like to tell you that JSF doesnt have "builtin" protection against CSRF. I have tested with the CSRFTester tool, it shows My JSF application is vulnerable to CSRF attacks. And also I would like to tell you that all Java EE applications are vulnerable to CSRF attacks. I found one possible way to protect the application from the CSRF attack is to generate random tokens and append it to the URL. Thanks!!

giftsam
That OWASP document was from 2007 and is not representative for current conditions. JSF has certainly builtin prevention (`javax.faces.ViewState`). On JSF 1.x it's only maybe "too easy" to guess. This has been fixed for JSF 2.1. See also my updated answer for the links.
BalusC