5

When you use JSF, you'll have the controller servlet javax.faces.webapp.FacesServlet that will be mapped to the following:

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

Putting a mypage.xhtml in /, we have a security risk because it will be accessed in two ways (starting from the application context): 1) /somefacesurl/mypage.xhtml 2) /mypages.xhtml

The first is processed by jsf, and is correct. The second is not processed by jsf and so is presented to the client exposing jsf tags and this is a security risk.

I've found only two solutions
1) mapping always to the root url:

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Good solution but permits only mappings by file extension.

2) Map to whatever url, and use security constraint to disallow access to those files as suggested in: How to avoid user access to .xhtml page in JSF?

Both solutions are presented in the JSF 2.0 spec as viable alternatives, BUT there is no word about the different security approach of the two solutions.

Since security is NOT considered, i wonder if the first is "secure" from the point of view of access to the xhtml files or perhaps there is an hack to get the .xhtml sources.

Community
  • 1
  • 1
AgostinoX
  • 7,477
  • 20
  • 77
  • 137
  • *Good solution but permits only file-type mappings and no more directory mappings.* didn't get this. what do you mean by directory mapping ? – jmj Jun 14 '11 at 09:10
  • **Moreover, some IDEs like NetBeans (6.9.0) go with the second solution, failing to document a security risk.** – AgostinoX Jun 14 '11 at 12:48

1 Answers1

3

It is not true that the JSF spec mandates the first mapping. It just gives examples of the both mappings in chapter 11.1.2 of the JSF 2.0 spec (which you should be reading) and chapter 10.1.2 of the JSF 1.2 spec. Here's an extract of relevance of the JSF 2.0 spec one (emphasis mine):

11.1.2 Servlet Mapping

All requests to a web application are mapped to a particular servlet based on matching a URL pattern (as defined in the Java Servlet Specification) against the portion of the request URL after the context path that selected this web application. JSF implementations must support web application that define a <servlet-mapping> that maps any valid url-pattern to the FacesServlet. Prefix or extension mapping may be used. When using prefix mapping, the following mapping is recommended, but not required:

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>

When using extension mapping the following mapping is recommended, but not required:

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>

In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request processing lifecycle, but applications that rely on these mechanisms will not be portable.

I really don't see why an extension (suffix) mapping is "tricky". Even more, this is my favourite JSF mapping. I recommend using *.xhtml as JSF mapping. This gives you also the advantage that you don't need to fiddle with security constraints to prevent direct access to source files.


Update: Please note that the source leak is not a security issue per se as long as the view is declarative and does not contain any single line of Java source code wherein variables like database username/password are stored and exposed. Since Facelets disallows for embedded raw Java code (like JSP scriptlets) I don't see how that's a security leak. What can a hacker do with the view source? Edit it, render it and submit back somehow? (I'd really wonder how). That's plain impossible since JSF by default relies on the view state in the server side as well.

I however agree with the point that the JSF specification should inform the reader more about this. I've created JSF spec issue 1015 for this.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • never said mandates, said suggested. More! i said "suggested but not required", to be clear. have you skip to read? – AgostinoX Jun 14 '11 at 12:04
  • Your question gives the impression that the extension mapping is not mentioned by the JSF spec. You said that it is "tricky" while this is not true. – BalusC Jun 14 '11 at 12:13
  • Ok, i accept the criticism and I've modified the question accordingly. The focus is on security and on security documentation. I started from Netbeans that goes with the 2 solution, then I realized (luckily, but it could have not been happened) the risk. I think that a complete documentation should at least mention the fact that a tecnology, without countermeasures, allows access to the source files. It puzzles me that it doesn't. – AgostinoX Jun 14 '11 at 12:59
  • Dude you have MUCH bigger problems than someone simply seeing the view source. – arg20 Mar 19 '12 at 02:43