• Post Reply Bookmark Topic Watch Topic
  • New Topic

Vulnerability issues in JSF  RSS feed

 
sandhya mridul
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
Does the JSF framework provide any security against unauthenticated access? I mean is it possible for a hacker to gain control over the underlying resources (Web server, Database server etc.) through some vulneraibility (manipulating URLs, etc.) in JSF framework?
Thank you in advance for your suggestions...
 
Ron De Leon
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the same issue how to authenticate the users. I am thinking to put the authenticated object in the session, and let the jsp and servlets check if the authenticated object is null or not null. I am pretty much sure there are many alternative and better ways to do it.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by sandhya mridul:
Hello,
Does the JSF framework provide any security against unauthenticated access? I mean is it possible for a hacker to gain control over the underlying resources (Web server, Database server etc.) through some vulneraibility (manipulating URLs, etc.) in JSF framework?
Thank you in advance for your suggestions...


There is nothing special about JSF once it's on the browser. At that point it's all HTML and it still uses the HTTP protocal to handle requests and responses. If you are looking for vulnerabilities, look for them in HTTP, not the framework used.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ron De Leon:
I have the same issue how to authenticate the users. I am thinking to put the authenticated object in the session, and let the jsp and servlets check if the authenticated object is null or not null. I am pretty much sure there are many alternative and better ways to do it.


What you are asking is not on topic with what the original rancher was talking about. Sounds like you might want to start a new thread to ask your question.
 
Saskia de Jong
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:


There is nothing special about JSF once it's on the browser. At that point it's all HTML and it still uses the HTTP protocal to handle requests and responses. If you are looking for vulnerabilities, look for them in HTTP, not the framework used.


I don't agree with you.

There is a special vulnerability in the JSF and that's the fact that view state can (optionally) be saved to the client. JSF 1.1 does not define a method to encrypt this data, so theoretically you could decode this state (which appears as a long base64 encoded string in the HTML you receive from the server), manipulate it, and send it back.

If you take a look at the source code of MyFaces for example, you'll notive that the restore state in all components does not apply any checks at all. On the one hand, data that is restored into JSF components this way is the same data a user can enter through the (input) components directly, and in a good design this data is checked in business logic that comes after the view anyway.

On the other hand, converters and validators themselves can also be parameterized (e.g. in the faces-config file) and these ALSO use the view state/restore mechanism. Typically, you don't check whether the parameters a validator receives from the state restore are the same ones it initially received. (you might be able to do this with some static variables, but I've never seen anyone actually take this path)

I'm not really sure what the point is of saving/restoring converter/validator parameters that are defined in faces-config.xml. They are constants and never change. When doing a non-faces request, JSF configs your converter/validator with these values, but for a faces request JSF uses the values from the view state (which, as I mentioned earlier can be manipulated by the user).

The problem with the view state when saved on the client has been recognized by Sun, as JSF 1.2 contains an encryption for this state in the spec. (disclaimer: I haven't read the JSF 1.2 spec yet, but this is what I understood of JSF 1.2).
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Saskia de Jong:


I don't agree with you.

There is a special vulnerability in the JSF and that's the fact that view state can (optionally) be saved to the client. .....


But this isn't specific to JSF. So I'll add that on top of the HTTP protocal, how you handle state saving no matter what framework you use, or if you use no framework at all. It's not a JSF vulnerability but a web application vulnerability.

Still, it's good to be aware of how JSF handles this. MyFaces actually has an ecnryption process for saving the view state on the client side. It's good that Sun recognizes this and is fixing it in JSF 1.2 as well.

Thanks for the info.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!