4

I have a basic question about JSF ManagedBeans for which I can't find a answer.

Suppose I have a bean MyBean with two methods method1 and method2 and a JSF page with a command link 

<h:commandLink action="#{myBean.method1}">
</h:commandLink>

Is it possible for someone to analyse the source code of the page and call method2 instead of method1?

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
Neo
  • 1,337
  • 4
  • 21
  • 50
  • 2
    If the viewstate is correctly encrypted, this cannot happen. See https://stackoverflow.com/questions/7722159/csrf-xss-and-sql-injection-attack-prevention-in-jsf (there still might be bugs in components) and also read https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html – Kukeltje Feb 26 '18 at 20:42
  • 1
    And See https://stackoverflow.com/questions/29420182/implications-of-saving-session-on-the-client-with-javax-faces-state-saving-metho – Kukeltje Feb 26 '18 at 21:02
  • The encryption comment is only relevant in case of client side state saving which is not the default setting. – ChristopherS Jun 19 '18 at 13:44

2 Answers2

3

Answer

No, this is not possible by design.

Reasoning

Technically the client can only tell the server "The user clicked a html element with a certain id". This event is then processed by JSF on the server-side, the component with the corresponding id is looked up and in this case the method "#{myBean.method1}" is executed. As you can see, the client can not[!] tell the server what to do with this event.

Sources

JSF 2.2 Spec - 3.4 Event and Listener Model

Caveat
JSF is stateful and there are multiple ways to hold this state. The default is to hold state information server-side (e.g. in the users HttpSession).
Another option is to transfer (encrypted) state to and from the client. This is still conceptionally secure, but there *might* be bugs with client side state saving. Such a bug *could* be exploitable to do something like you described.
DaniEll
  • 1,022
  • 4
  • 22
  • 31
-2

Yes, it is always possible to modify code (or markup-language) on the client-side. Your "action" will be called through some forms and/or Javascript-Methods - everything visible to experienced users.

But that's not an issue of JSF-2 only - this applies for every language which allows insights from the client side.

You shouldn't apply "security through obscurity" (https://en.wikipedia.org/wiki/Security_through_obscurity) but rather make sure, that you can handle this on the server-side.

If a user, who has access to two urls modifies url1 to url2 - that's fine, why not? (Could be bookmarked) - But YOU should take care of the modified request, if he is not allowed to access url2.

dognose
  • 20,360
  • 9
  • 61
  • 107
  • if you 'answer' Yes to the question and then in the second paragraph 'negate' it, that is sort of confusing. I'd remove the 'Yes' as the first word – Kukeltje Feb 26 '18 at 20:24
  • Sorry, pressed enter by accident. You read my comment to quick ;-) I edited it – Kukeltje Feb 26 '18 at 20:26
  • Ah, I see... well, the question was basically `Is it possible for someone to analyse the source code of the page and call method2 instead of method1?` - So I started with "Yes, ..." - I modified the second paragraph to make clear its not an issue of jsf ONLY (but others as well) - so it doesn't seem to negate the first sentence. – dognose Feb 26 '18 at 20:26
  • 2
    No that is not possible with JSF if you manipulate the client IN the same view... The viewstate prevents all this... The (references to) methods are nowhere stored in in client. It's one of the reasons I prefer JSF over all the javascript frameworks where you need to add all sorts of OWASP things... Protecting access to different URL's (each with maybe their own beans/methods) IS up to the developer, just like with normal webapps. But if you think you are right, please correct me and point me to a 'reference' document where it is stated that such manipulation can be done – Kukeltje Feb 26 '18 at 20:34
  • @Kukeltje from the example I can't see that a `ViewScope` is used. Hence, before saying: "No, you are safe" - i'll consider a request scope. Also, you are wrong (when talking generalised): If the server is using `javax.faces.STATE_SAVING_METHOD=client`, you'll get no security cause you could receive modified View-States. – dognose Feb 26 '18 at 20:52
  • I nowhere mentioned viewscoped and that is irrelevant. The viewState is about **this** view. And yes there **were** risks with the view state, I referred to a good clear article in my comment. And THAT should be (part of) the answer...Also when using client-side state saving, you only have a problem when using older versions and NOT taking precautions. In 2.2 and up there is NO probloem. https://stackoverflow.com/questions/29420182/implications-of-saving-session-on-the-client-with-javax-faces-state-saving-metho – Kukeltje Feb 26 '18 at 21:02
  • @Kukeltje I disagree: The CLIENT invokes the action. So any (skilled) client can modify the request to INVOKE something else. The most blatant way would be to use something like CURL.... After all, even JSF has no other Options (for transfering request-information) than: `put`, `get` or `post`... NOTHING could avoid modified requests, but the server side. (But maybe we are talking about different things: I say: "Modified requests are possible" - You are already talking about JSF-Mechanics on the server-side) – dognose Feb 26 '18 at 21:08
  • 2
    Modifying request where it results in calling a different method on the server than initially in the page. **That** is the question (you even copied that in your second comment on my edited first comment). And that is up-to-date JSF libraries or correctly configured older ones not possible. Yes you can manipulate the client-side view-state and send that to the server but the server will detect the tampering and refuse to process the request... It's in JSF (combination of client AND server) by default and other javascript UI frameworks need OWASP and more... – Kukeltje Feb 26 '18 at 21:16
  • 3
    The answer to *"Is it possible for someone to analyse the source code of the page and call method2 instead of method1?"* is very definitely not "Yes", hence the downvote. Otherwise JSF has been broken for 16+ years. – BalusC Jun 12 '18 at 16:02