Which properties in a JSF backing bean can be set by a user?

Question

I have a backing bean (somebean) with three boolean properties a, b, and c, each has a getter and setter.

I have a form which looks like this:

<h:outputText rendered="#{somebean.b}">
    B is true
</h:outputText>
<h:form id="blah">
  <h:inputHidden value="#{somebean.a}" id="a"/>
  <h:commandLink id="zzzz" value="do it" action="#{somebean.doIt}"/>
</h:form>

Which of the three properties a, b, and c can be set by the client? I tried adding b=true and c=true to the POST request, but SomeBean.setB(boolean) and SomeBean.setC(boolean) never get called. So perhaps only a can be set - the logic being that if there is a field in the JSF that sets it, the client is allowed to set it. But perhaps I'm wrong and it just has some default name that I don't know about that can be used to set it...

Should I just assume that any property on my bean can be set by the client? If not, which ones should I assume the client can set (and thus have to worry about during validation)?

Also what happens if I have my form conditionally rendered? e.g:

<h:outputText rendered="#{somebean.b}">
    <h:form id="blah">
      <h:inputHidden value="#{somebean.a}" id="a"/>
      <h:commandLink id="zzzz" value="do it" action="#{somebean.doIt}"/>
    </h:form>
</h:outputText>

In this case, can a still be set if b is false?

---

By "client", I mean anything sending HTTP traffic to my site. Which could be for example, malicious code.

Answer 1

Which properties in a JSF backing bean can be set by a user?

Those bound to an EditableValueHolder component, such as UIInput and friends (including <f:viewParam>!), with the precondition that they are rendered="true", disabled="false" and readonly="false" during apply request values phase.

Another possible way is through a @ManagedProperty("#{param.xxx}") on the property of a request scoped bean or a hardcoded ExternalContext#getRequestParameterMap() access in some bean method which is invoked during the HTTP request.

So, only when you as being the developer explicitly bind the property to an editable value holder component which is rendered, non-disabled/readonly, or when you as being the developer explicitly set a request parameter as a property. There are in the current releases of JSF implementations absolutely no security holes with reagard to the possibility of setting undeclared/unbound properties by HTTP means. It's even not possible to send an arbitrary value to a UISelectOne or UISelectMany component by spoofing the HTTP request, it would only end up in "Validation Error: Value is not valid".

---

As to security holes in older JSF implementations, only and only when you're navigating to a different view using includeViewParams="true" in a Mojarra version older than 2.0.7 and 2.1.5, then all EL expressions in view params such as #{bean.setArbitraryProperty('foo')} will be evaluated. See also issue 2247. I'm not aware of any security holes in MyFaces; that's not because there are none per se, but simply because I don't use/track it closely.