File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes AJAX, JSF and security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "AJAX, JSF and security" Watch "AJAX, JSF and security" New topic
Author

AJAX, JSF and security

George Stoianov
Ranch Hand

Joined: Jan 15, 2006
Posts: 94
I would like to ask the authors of the book what is their take on security when using AJAX and how does AJAX fit into the security realm?

I don't know if everyone is familiar with the gmail JavaScript problem, where a user was able to get through JavaScript in someone else's mail box.

What I mean is JavaScript is a language that can run in the browser and can do a lot of things with the browser and some browsers can do a lot of things on particular operating systems with not very good checks on what is going on.

If web surfers are to enable JavaScript and start using this new technologies doesn't that in the long run make it that much easier for spamers etc. to get to users information asynchronously without the users getting any screen feedback or warning etc..

I know this argument can be made for any technology and I am not a JavaScript expert by any means but it seems to me that a language like JavaScript that does not have a lot of the build in security safeguards leaves the door open to exploitation.

Thanks
George
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
JavaScript can not read another domain unless you the user allows it to happen by setting your security settings wrong. JavaScript has a no cross domain policy. Hence Ajax is limited only to your domain.

Also Ajax is no different than a normal form. Same rules apply. Show me a form that I can not hack on your webpage.

If you do not protect yourself on the server with a form or XHR object you are basically screwed.

Eric
Sergey Smirnov
Ranch Hand

Joined: May 29, 2003
Posts: 167
I also suggest that the security problem with javascript is more rumor than the reality. However, I still what to ask authors about the approach introduced with Mabon project. Ability to have an access to the bean method directly using easy-to-reproduce URL string that works around the main jsf life-cycle sounds like a huge potential security hole. One method can return suggestion list, but another one cleans up all the record in the database. Does a protection against such violations exist in the project?
[ April 06, 2006: Message edited by: Sergey Smirnov ]
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by George Stoianov:
I don't know if everyone is familiar with the gmail JavaScript problem, where a user was able to get through JavaScript in someone else's mail box.


Can you show me a link or two discussing this issue?
George Stoianov
Ranch Hand

Joined: Jan 15, 2006
Posts: 94
Can you show me a link or two discussing this issue?


Here you go: http://ph3rny.blogspot.com/2006/03/vulnerability-in-gmail.html

Please note that I completely realize that any technology is vulnerable to exploits, all I am trying to find out is whether this new technology has had any consideration for that in its foundation, and so far I am not hearing anyone say that. Yes it is true that good user education is one of the key to good security and there are check points for that on the browser end, but I know that some people would not stop at any warning message ...

With the tools being offered by every major company and the cool effect I think the adoption is sure to follow and let's face it it is better than html, but what about my personal information or the companies??

Anyway I am just ventilating ....

Thanks,
George

[ April 06, 2006: Message edited by: George Stoianov ]
[ April 06, 2006: Message edited by: George Stoianov ]
John Fallows
Author
Greenhorn

Joined: Apr 04, 2006
Posts: 6
The ability for Mabon to expose various methods on a managed bean does sound like a huge security problem, doesn't it?

Mabon appends a secure hash to the URLs it generates during initial render of the page, so that subsequent AJAX callbacks can be verified as originating from the server rather than being spoofed during a malicious user attack.

Most importantly, the JSF component author does not need to take any special measures to ensure this Mabon AJAX callback has been secured.

Kind Regards.


<a href="http://apress.com/book/bookDisplay.html?bID=10044" target="_blank" rel="nofollow">http://apress.com/book/bookDisplay.html?bID=10044</a><br />Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Sergey Smirnov:
Ability to have an access to the bean method directly using easy-to-reproduce URL string that works around the main jsf life-cycle sounds like a huge potential security hole. One method can return suggestion list, but another one cleans up all the record in the database. Does a protection against such violations exist in the project?


Well that's like running as root. You don't do it. Your bean only has methods that do what needs to be done. If you don't want to delete records using AJAX don't expose those methods. Either by setting security in the AJAX framwork of choice or not having the methods in the bean at all.
Sergey Smirnov
Ranch Hand

Joined: May 29, 2003
Posts: 167
Originally posted by Gerardo Tasistro:

Well that's like running as root. You don't do it. Your bean only has methods that do what needs to be done.
You did not get my point, sorry. The bean set is the same. So, if one of your page contains button that allows to clean up the records, (like <h:commandButton value="clean" action="#{bean.removeAll}"), the removeAll must be a public method independently of do you have and AJAX behavior or not.
Actually, John already answered my question. Mabon allows to call only the method that are in the secure hash.
[ April 07, 2006: Message edited by: Sergey Smirnov ]
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Oh I did get your point. I was just approaching it from the user role side not the method side. If I don't want the user to be able to directly delete the values I wouldn't expose the method as public, period.

First of all if I have a bean I want to share with AJAX I make it have only allowed methods (not delete). These methods in turn call the methods in your managed bean called "bean". After all "bean" can be accessed from the AJAX bean since it is in session. And in the case of mabon, apparently directly. Which is a blessing in some cases and curse in others.

Secondly if your <h:commandButton> with the delete command is in a jsf it is very tempting to do:

$> curl -d "_id0:_id36=clean" http://yoursite.com/yourapp/yourdelete.faces

Which posts the button click to the page thus activating the action from an html code something like this.



Which was generated by faces. Sure I would probably have to pass validation on all the other fields in the form, but you also have to trick the cross domain scripting security in JavaScript to get away with calling the method with AJAX.

For example if I create a localhost file that has JS and includes the JS AJAX method calls from the victim site. And then I try to call those from my localhost page by opening it in a a browser I will get an error not allowing that. At least it is so with DWR which is what I use. I believe the post using curl has no such limitations and I can call your delete all method. So here who is doing the calling is more important than what is being called and container security comes into place. Can mabon aside from hiding the methods also have different mappings for different roles? So some methods are exposed if your ADMIN and others if your USER. The only way to stop the curl attack is through permissions to the files. Which I believe should be applied to the mabon servlet too.

Personally I have been using beans for AJAX and beans for everything else. I see the AJAX bean as a communication bridge between the client and some bean that does actions in the server and not something that exposes my business logic to the world.

Never the less mabon looks like a great proposition. I think it is great in terms of changing your managed bean on things as selects and combos which are a pain in a pure AJAX implementation. Yet my concern with AJAX is not the "delete" button, but the "select" button so to speak. The possible information leeching from your site by using succesive AJAX calls.

The possibility of someone using the AJAX method used to fill the "client table" on the browser to steal my client list scares me more than a "delete". Once deleted I can fall back on my backups and recover. Once my critical information is stolen how do I get it back?

I also have way more applications which are end user than administrative. That means a whole lot more applications with beans serving data that applications with beans that have a "delete method". I'm more concerned with who is doing the calling than what is being called. I like DWR's access control which sets not only the exposed methods, but also who can call them. DWR

I'll read further into mabon, what it can do and see if it has user roles too.

Best regards
Sergey Smirnov
Ranch Hand

Joined: May 29, 2003
Posts: 167
Gerardo, your statements make me scared. However, before I start to recommend to everybody to set permissions to the pages with administrator-only controls, I would like to know is the jsf framework so unprotected or it is a result of using inappropriate third party library and attempts to fight with the side effects.

I agree that it is more harmful if somebody steals the content instead of removing some data. So, my example is about it. This is a short pure JSF application:
http://jsfbyexamples.com/secureHole
Could you say what the account number the secret person has?
The getAccountNumber of the secretPerson bean is public and everybody is welcome to the pageinfo where the account number might be shown. So, It breaks at least two rules you recommend to follow.
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Well actually my comments have little to do with JSF and more to do with AJAX which can be applied without JSF. JSF is pretty much like JSP you can set permissions to files through the container. My worries with AJAX is that calls are usually handled by one servlet. What permission do you give it? Do you restrict it to administrative role or everybody or somewhere in between? What if guest needs to use AJAX to display some info? He can't get to the administrative AJAX servlet. So you have to write a servlet for every user role. Which is what I had told you in the beginning: don't expose the methods. But this get tedious. A servlet for every role with its little set of role methods.

Now with these nifty AJAX frameworks implementing AJAX is easy, but permissions can get a little more complicated if role security isn't built into the framework.

That is why I like the DWR implementation. It allows one servlet (servlet-mapping) to have many roles. Exposing methods depending on who is logged in. That way I don't have to write N amount of AJAX servlets. One handles all through mappings to classes with the actual methods.

In the case of DWR you call a .js file in a path mapped to a servlet that returns the proper js code (in turn from a mapping to a class). I speculate that if you set permissions anybody not allowed into that url-pattern will not have AJAX support (for example /dwr/*). Or if you protect /dwr/myAdminAjaxTools.js then non admin users couldn't get access to the class with the delete method. They'd be blocked from the delete.


In the case of mabon and as per the example that pattern would be /mabon/*. I would also like to speculate that if you protect an url pattern like "/context-root/mabon-servlet-mapping/managedBean.methodName" you could disable the delete command through AJAX. I'm not sure how you could block the administrative managed bean from a non administrative role without blocking all mabon AJAX support. Something like adminBean.*. Which doesn't look like a valid url-pattern. Any ideas? Have you worked with these security issues and mabon or any other AJAX implementation?
Linda Walters
Ranch Hand

Joined: Apr 30, 2005
Posts: 100
So far in our projects we have not made extensive use of Ajax whether with or without JSF, but the little that we have done has not seen any significant security issues that would not exist with each of the pieces of technology that make up Ajax.

There really is no magical thing called Ajax, it is mearly a way of working with existing technologies. If forms and POST and GET requests are a security risk, then so is Ajax and not to any significantly greater extent, if any.

The same is true for the XML, JSF and HTML parts of the technology. In fact, we may see that Ajax is in some small way more secure, since we are not resending our entier page and all its data multiple times.

For my own situation, I deal with a web-based enterprise IT software product rather than a web site for the general public, so many of our security considerations are taken care of by the user login that gets passed back from the web server/servlet container to an application server and database layer. The security concerns that we have had in the product have been addressed long ago and I think that Ajax will only strengthen, not weaken them.

We are just begining to look more closely at the various offerings of frameworks, libraries and IDEs that starting to grow up around Ajax. So, I can't say much about something like Mabon, but I can say that since it is JSON-based, I will not be using it. While I don't expect that we will be making any great use of any of them due to our rather unique requirments, I expect that we will come away with some interesting information for our next generation of product.


<a href="http://labryssystems.net/pblog/index.php" target="_blank" rel="nofollow">Javaville Gazette</a><br />Non-cooperation with evil is a duty. -- Mahatma Gandhi
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
Linda is right,

I always tell people Ajax is a form submission. Act like it has form fields (parameters in the send) and a submit button (the send method executing)

The server does not see it as the XMLHttpRequest Object it sees a form. I can submit a form off of my desktop to your server. I can submit a form from my server to yours. There is no difference.

You need to implement a user session and validate the source of the data. BUt we can spoof the header so all data can be wrong! Why do no people freak out when they use a normal HTML form? Same things can happen.

Now Cross Domain JavaScript is very scary in my eyes. If a user has the setting in IE to allow it, they are opening up a bad bad bad bad hole. Stuff like that gmail problem could lead to issues. I just wish there was details on the problem so I can say what the issue exactly was. All I found was saying code could execute. (Any links that talks about the code?)

Eric
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Erik my main concern with AJAX is that all the framworks seem to funnel it down one servlet that could be recycled over and over through the whole application. I agree completely that is like a form post, but it is a form whos URL looks the same from all your pages. So your standard "form in a page and I secure my page" security doesn't work the same.

In Sergey's example he has a method that deletes info. It is easy to secure if it is used in a deletemyinfo.jsp. Just secure that page. But if you publish that same method in the AJAX framework you have to make sure that framework is secure and not exposing that method or exposing it to authorized users only. Standard container security doesn't work that well anymore, if at all. So I believe that if you can't secure that code enough you shouldn't publish that method. Since a simple <script> tag, misplaced in one file, could become a killer.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15292
    
    6

In Sergey's example he has a method that deletes info. It is easy to secure if it is used in a deletemyinfo.jsp. Just secure that page. But if you publish that same method in the AJAX framework you have to make sure that framework is secure and not exposing that method or exposing it to authorized users only

The method for deleting info doesn't exist in the Ajax framework. You, Sergey, or whoever, wrote that method for the framework to use. So it's your job to secure that method. If that means that method must validate the request, then so be it. It's not that different than securing a page.


GenRocket - Experts at Building Test Data
Sergey Smirnov
Ranch Hand

Joined: May 29, 2003
Posts: 167

Well actually my comments have little to do with JSF and more to do with AJAX which can be applied without JSF. JSF is pretty much like JSP you can set permissions to files through the container My worries with AJAX is that calls are usually handled by one servlet...

This is a significant point why I am not on the same page with you guys, because I know for sure that JSF is not a pretty much like JSP. It has its own advanced components-based infrastructure with the component tree and life-cycle when the validators, converters, value change and action listeners associated with the components are invoked during the particular life-cycle phases. Just a few AJAX frameworks take care about it. Most of them act like a hijacker who needs just an access to the bean facility. The usual approach is simple and straight-forward - own servlet, access the session and request scope beans, invoke the methods or access to the properties. Of course, one of the side effect is a security issue. It hard to ask hijacker to be nice and easy.
In JSF (sorry, I am speaking about JSF, not just about AJAX again. we are on the JSF forum right now) you cannot simulate the pressing the "delete" button with any kind of javascript if it does not come to your browser as a result of rendering the corresponded component.
If you re-read John's answer to my original question, he spoke about "a secure hash to the URLs it generates during initial render of the page". It (most likely) means that only the rendered by the server URL has a chance to be answered during the AJAX request. I.e. you can have a public 'delete' method and even contruct the URL to call it, but the request will be rejected by the server, because it does not generated and stored in the secure hash previously.
[ April 11, 2006: Message edited by: Sergey Smirnov ]
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
I did re-read John's post and the line you quote ended like this "so that subsequent AJAX callbacks can be verified as originating from the server rather than being spoofed during a malicious user attack." Which makes me doubt there is role security involved. I just know the callbacks are secure for the server, but am I sure there can't be any privilege escalation?

Namely, of all the thing I can do with AJAX through mabon, is mabon checking that I'm actually allowed to do them given my credentials? Going back to the DWR case I want to check and see the following:

-In DWR you create some classes and then publish them through the interface URL. In the following example I have four js files. The AddressFormSources which gets select info and the sort to generate a form and corresponds to AddressFormSources.java. The DataValidator which has access to important information and corresponds to DataValidator.java. The engine and util js files which are the core DWR engine.



Now I want to have two types of users the admin and capture. Admin is well admin and the capture role just types info using some forms and the methods in the AddressFormSource, but should have no access to the DataValidator methods.

Although the AJAX calls are all posts (as Erik comments). They are all posts to the dwr servlet mapped at dwr/. So how do I allow both admin and capture roles to have AJAX support while not allowing capture roles to use DataValidator methods? If dwr/* is limited to admin roles then capture role users can't get util and engine js files. I might block the access to the DataValidator.js file to non admin users. Thus the non admin pages wouldn't have the js code needed to call those methods. But that is just a partial fix. I could probably inject that code into the AddressFormSource.js through means of a proxy. Once that code is injected I can call the DataValidator methods. Unless of course the DWR framework checks for user roles on that post.

See what I'm getting to? Although AJAX is just a post it is a post to a "polymorphic" page or a page with as many "forms" on it as there are methods. Once again clasic url-pattern security doesn't work the same.

I'm looking forward to have some free time tonight or tomorrow and do some real testing in regards to this. I'll fill you guys in when I'm done.

Regards
[ April 11, 2006: Message edited by: Gerardo Tasistro ]
Linda Walters
Ranch Hand

Joined: Apr 30, 2005
Posts: 100
Eric wrote:
Now Cross Domain JavaScript is very scary in my eyes.
---------------------------------------------------------------------

I'm in total agreement and if IE or another browser might allow it, all I can say is DON'T!

The same effect can be had by making the request to your servlet and then allow it to access the information on the other domain in a more secure manner. This allows the servlet or another back-end server, to pick and choose what other domains, if any, the end users may access. It can choose to white-list or black-list domains or some combination of the two. It can also utilize the user's login account to filter what data they have privileges to access on what domains on a user-by-user basis.

This approach is not only much safer, it is a better separation of concerns in the overall architecture of the system.

Just my $0.02 worth of input.
[ April 11, 2006: Message edited by: Linda Walters ]
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
I know this post is two topics in one, but need to point out something with this response.

Originally posted by Gerardo Tasistro:
Eric my main concern with AJAX is that all the framworks seem to funnel it down one servlet that could be recycled over and over through the whole application. I agree completely that is like a form post, but it is a form whos URL looks the same from all your pages. So your standard "form in a page and I secure my page" security doesn't work the same.



How would the URL look the same with an Ajax request? You are still going to have a referer and such. When I look at the header of one of my requests I see this:

Headers: Cache-Control=no-cache&Connection=Keep-Alive&Content-Length=7&Content-Type=application/x-www-form-urlencoded&Accept=*/*&Accept-Encoding=gzip,+deflate&Accept-Language=en-us&Cookie=ASP.NET_SessionId=f3orhbmmpilqrw451ghl3b45&Host=localhost&Referer=http://localhost/TestSender/test_1.aspx&User-Agent=Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322)

and I request that same server page from another page I see:

Headers: Cache-Control=no-cache&Connection=Keep-Alive&Content-Length=7&Content-Type=application/x-www-form-urlencoded&Accept=*/*&Accept-Encoding=gzip,+deflate&Accept-Language=en-us&Cookie=ASP.NET_SessionId=f3orhbmmpilqrw451ghl3b45&Host=localhost&Referer=http://localhost/TestSender/test_2.aspx&User-Agent=Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322)

So this can tell where the request is coming from. Now if you were to have differnet roles on a page, that is where your session would determine what they could do. (AKA edit, delete, etc.)

Eric
George Stoianov
Ranch Hand

Joined: Jan 15, 2006
Posts: 94
Hello everyone,

With the risk of taking this out of topic, reading the previous posts, I thought to throw this out and see what you think.

In my mind security when talking about an application is preventing a user from executing a specific action for which that user does not have the right privileges.

There are different ways of enforcing this but at its very basic is the ability to distinguish the user by some sort of computer readable form of parameter from other users with privileges, the more flexible that is the better security you can provide, and there are many ways to do that, even when only one servlet is processing the output.

The notion of security in a network communication is that you secure both ends of the communication and the actual physical medium for transfer. Let us say that the network is secure so we don't have to deal with that , then we are left with both ends the user interface and the backend on the server.

In my mind the server can be made secure more easily then the user interface in a "common" web application by the simple notion that the user interface on the web is always provided with the source code so someone looking to get illegal access has that to investigate and poke around with. They could completely alter the provided interface and any other information provided in a header or any part of html request even mac address etc.

Now with AJAX there are more and new methods being exposed to poking around and yes if there is a good "framework", used very loosely here I mean component of one, or set rules and some sort of a layer that has the main purpose of instigating those security constraints I would think this is securable.

Pardon my ignorance on AJAX and JavaScript if I am mistaken but I am not seeing that.

If you expose methods through your servlets than you would need a way to verify and secure each method through role based type of security most probably or have one servlet that does all preprocessing and hands it off for final result sounds like a candidate for a Filter.

Thank you.
George
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Hello fellow ranchers. I seems the forum isn't letting me post all the sample code in this thread. Even with the [code] tag. So I'll invite y'all to see them tests here.

AJAX test
[ April 12, 2006: Message edited by: Gerardo Tasistro ]
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
Originally posted by Gerardo Tasistro:
Hello fellow ranchers. I seems the forum isn't letting me post all the sample code in this thread. Even with the [code] tag. So I'll invite y'all to see them tests here.

AJAX test

[ April 12, 2006: Message edited by: Gerardo Tasistro ]


For the future:

To post code you need to escape tags (&lt; &gt; and replace the letter o with &#111; for things such as
&#111;nclick.

Eric
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
Also I can not get your domain to resolve.

Eric
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Indeed. It seems www.tasistro.com isn't getting an answer. The url you need to access is without the www

http://tasistro.com/javaranch/AJAXhacks.html

as is. Let me know if you still have problems and I'll post it on another server.

Regards and thanks for the heads up.
 
Don't get me started about those stupid light bulbs.
 
subject: AJAX, JSF and security
 
Similar Threads
Securuty with javascript ?
Future of JavaScript?
How Much Is Java Really Being Used On The Web?
Very General GWT Question for authors
Swing client Vs Applet Vs RIA (AJAX, etc)