JSF2 redirect with includeViewParams allows users to enter EL expression which are resolved into text fields

Question

I have a JSF2 XHTML page that defines view parameters, this allows one to have bookmarkable URLs. The XHTML page includes the parameters:

<f:metadata>
  <f:viewParam name="searchName" value="#{nbsearchpage.searchName}" />
  <!-- More view parameters omitted here for brevity -->
  <f:event listener="#{nbsearchpage.searchPreRender}" type="javax.faces.event.PreRenderViewEvent" />
</f:metadata>

On the same page, I have a text field and a button that allows the user to change the searchName:

<h:form id="some-id">
  <h:inputText value="#{nbsearchpage.searchName}" />
  <h:commandButton value="search" action="#{nbsearchpage.search}" />
</h:form>

and finally, the action method search() in the nbsearchpage bean returns to the same page, but including the parameters:

?faces-redirect=true&includeViewParams=true

which provides the user with a nice URL. When the user enters "IBM" in the search field, the URL is redirected to

?searchName=IBM 

It works perfectly good. But now the user can enter an EL expression in the searchName textfield, and the EL expression is evaluated. E.g. when the user enters "#{2+2}" in the textfield, the URL is redirected to

?searchName=4

and this is what I think we should not be doing, allowing the user to enter EL expression due to security reasons. I am using Glassfish 3.1.1.

Any ideas how to prevent this automatic EL resolving? I think there is a fundamental flaw with the view parameter concept in JSF2 and with redirecting? I had the same problem with the view scope that does not survive redirects, and for this I had to create an own scope. (I could have used the flash scope).

Chuppah

I can reproduce this with Mojarra 2.1.2, this is a serious security flaw since it also allows to access to session attributes and to call arbitrary methods. – Udela

Answer 1

I can reproduce this on Mojarra 2.1.4. This is definitely undesireable. I have reported it to the Mojarra guys as issue 2247 (vote for it if you can). MyFaces 2.1.3 by the way also exposes the same problem.

No simple workaround for this particular issue comes to mind so far as the root cause is in an JSF implementation specific utility class. You could easily have a modified copy in your /WEB-INF/classes, but to be implementation independent you'd have to completely reimplement ViewHandlerImpl or maybe ExternalContextImpl and supply it as a custom one, but that's a lot of work.

However, as you're already using <f:viewParam>, you can also just use <form> instead of <h:form> and <input type="submit"> instead of <h:commandButton>:

<form>
  <h:inputText id="searchName" value="#{nbsearchpage.searchName}" />
  <input type="submit" value="search" />
</form>

and do the action method in pre render view event listener instead. That's also a more proper way of using GET forms in JSF as <h:form> is intended for POST only.

---

Unrelated to the concrete problem:

I had the same problem with the view scope that does not survive redirects, and for this I had to create an own scope.

Surviving redirects has never been the intent of the view scope. The view scope is intented to live as long as you're interacting with the same view (especially by Ajax and conditionally re-rendering of content). You're basically looking for the conversation scope instead. You'd have looked at CDI's @ConversationScoped or MyFaces CODI.

Potted

Answer 2

This issue has been solved in MYFACES-3405 for MyFaces Core versions 2.0.11, 2.1.5 and in JAVASERVERFACES-2247 for Mojarra versions 2.0.7, 2.1.5, 2.1.6.

Just use an updated version.

Muzz