2

I am steeped in Struts, and I am starting to learn JSF 2.0. Can I keep using what worked in Struts to reduce attack vectors, or are there new attack vectors that I will need to code for?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
bakoyaro
  • 2,550
  • 3
  • 36
  • 63

1 Answers1

6

JSF/Facelets by default already escapes output in UIOutput and UIInput components. So as long as you redisplay user-controlled input by <h:outputText> and <h:inputWhatever>, then the XSS part is safe.

JSF has also builtin prevention against CSRF by the javax.faces.ViewState hidden input field. Prior to JSF 2.1 this is only "too easy" to guess, see also JSF impl issue 812 and JSF spec issue 869. This has recently (3 Oct 2010) been fixed for JSF 2.1.

Note that the prevention against SQL injection attacks is not the responsibility of a web MVC framework. You need to solve that part in the data layer. If you use JPA the right way (i.e. do not concatenate user-controlled input in a SQL string, but use parameterized queries), then that part is safe as well.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • @BalusC + 1Thanks for your input, we just covered UIOutput and UIInput and it looks promising. – bakoyaro Dec 14 '10 at 14:42
  • @BalusC How about Filters? Since `javax.faces.webapp.FacesServlet implements javax.servlet.Servlet`, I should be able to write an input and output filter for anything that comes through any Facelet that I write. – bakoyaro Dec 14 '10 at 21:12
  • 1
    JSF indeed runs on top of Servlet API. You can indeed use servlet filters on a JSF webapp, but I don't see how they are useful with regard to security concerns like XSS/CSRF/SQLI. Best they can do is doing authentication/authorization checks based on the logged-in user. Sanitizing input/output in a filter is by the way a bad idea -if that was what you've had in mind. Output escaping (to prevent XSS) should be done in the view side only. Input escaping (to prevent SQLI) should be done in the data layer only. – BalusC Dec 14 '10 at 21:14
  • @BalusC Can you explain why 'sanitizing input/output is a bad idea' a little more? I thought that 'sanitizing' at one layer would be a good strategy, that way I could trust input at the lower layers in my app and not have to write a data scrubber at each level. I recall recently hearing of Facebook and/or Twitter using input strategies to trust that an input variable was 'safe' or 'scrubbed' either on input or output. Is this not a sound strategy? – bakoyaro Dec 14 '10 at 21:42
  • 1
    I didn't said that. Just that doing that **in a filter** is a bad idea. Scrub it only at the point that it would possibly harm. XSS doesn't harm in Java code or DB. SQLI doesn't harm in Java code or HTML. With a filter you're sanitizing it at the wrong place which is only confusing for future maintenance and you only risk double-escapings which would result in malformed input/output. – BalusC Dec 14 '10 at 21:45
  • @BalusC Ah, good point. I have stumbled on that exact issue before. It always seems that once I come up with a really good regex to scrub input, some new threat arises. What are your ideas for creating input/output scrubbers at each layer? Are there any references that you can suggest? – bakoyaro Dec 15 '10 at 14:19
  • I've already answered that. To redisplay user-controlled input, just use JSF `` or `` instead of as plain text or ``. They already take escaping into account. To store user-controlled input in DB, just use JDBC/JPA with parameterized queries (i.e. do NOT concatenate them in SQL query like `"SELECT * FROM user WHERE username='"+username+"'"`). – BalusC Dec 15 '10 at 14:22