"secure" widgets

[Alberto Sarubbi]

hi there, i'm developing an application that came into a common use
case when HTML is generated from server side, which is whether to
include or not an element in the output based on security constraints
applicable for the current user only.

some security frameworks, like the one we're using (apache shiro),
provides special jsp / gsp tags to achieve this, like
<g:hasPermission("somekey">.... then render component.

can you point me some patterns or information to achieve the same
thing with GWT?

my first approach was to use the constructor of a composite with a
security constraint container, so i can do the typical question:

if (securityContainer.hasPermission()) {
add or show o enable the button.....
} else {
//no button to push
}

being the security constraint container a simple JSObject obtained
from the server with an rpc service.
and only when it is available, the widgets are creted.

but this is not only a bad solution, in terms of coding standards but
also brings a question: wouldn't the security constraint container be
available to a DOM inspector for analysis? some kind of a BIG HOLE in
security?

i know i can create a secure version of every widget i need to
protect, but, the security constraints problem is the same.

any ideas would be appreciated.

thanks in advance.

[Robert Hanson]

> wouldn't the security constraint container be available to a
> DOM inspector for analysis? some kind of a BIG HOLE in security?

Yes.  And it is also trivial to take your obfuscated code and de-obfuscate it.  So assume that anyone that can download your JavaScript code can read it and change it as they like.

The only real security you can have is on the server.  On the client the best you can do is obfuscate it and hope the user isn't a coder.

So, perhaps you need to rethink your strategy.  Perhaps one solution is to have multiple modules, and secure the JS code on the server.  This will though increase the total size of the app.  You could potentially do the same thing with split points (instead of multiple apps), but the file names of split points change each time you compile, so it would be difficult to lock the JS code down that way.

Rob

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Alberto Sarubbi]

looks to me like a dead end for developing security sensitive UI with
GWT.

thank you Robert.

[David Chandler]

In order to write a secure rich Web app, you need to think in terms of
protecting the data, not the UI itself. This is true for any JS
application, not just GWT.

/dmc

> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

[Williame]

Agreed.  What the client sends to the server can be the wild west.  Never trust it.

My recipe, YMMV, but my apps hide display of access limited objects on the client side(all are there in the js) but more to avoid confusion to users than as a security measure.  The real security is on the server side that they cannot alter with js live editing tools or faked GET/POST/RPC requests.  When they first login I get access privs from the datastore and put them into the server session attribs as well as pass them back to the client to control widget display per access.

Client side:

if (hasAccess(clientSession, const.SUPER))

  showWidget();

Server side:

public boolean doSomething() throws AccessException

  {

  HttpSession sess = getThreadLocalRequest().getSession();

  if (hasAccess(sess,const.SUPER))

    return(doSuperThing());

  else

    throw new AccessException("Access denied!");

  }

Comments welcome.  Always looking for a better mousetrap.  :-)

-William

[will0]

In protecting the data as David rightly suggests, you can protect the UI by returning SC_UNAUTHORIZED if an unauthenticated user attempts to access any remote service. I've overridden the RequestFactory onResponseReceived function which redirects to a login page if the response is SC_UNAUTHORIZED.

See my answer on StackOverflow:

http://stackoverflow.com/questions/6508238/gwt-authentication-for-some-part-of-application-using-gwt-login-page/6511218#6511218

[Alberto Sarubbi]

we actually protect EVERY call to our server validating the user
rights before proceeding to the service execution.

it just doesn't seem right to show a user a button that he can't click
because he don't have the permission to do.
it sounds more logical not showing the button at all.
of course, validations on server side will catch any click on a
forbidden button, then comes the question: why would i show
the button then?..


thanks for the advice people. may be i just don't get right the js gui
development yet :)

[David Chandler]

Agreed! Don't show the button if the user doesn't have permissions. But also check perms on the server to protect against hackers.

/dmc

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Rob Coops]

The idea behind security is simple, trust no one and trust nothing... only when who ever tries to access and authenticates them self and is authorized to access what ever it is the are attempting to access allow this action.

So try and hide anything that a user should not have access to. This will prevent them form attempting to access this and limits the number of errors or warnings you will have to show.

Always check the credentials on every single call don't assume that due to the user having access to a button they must have the rights check these rights instead.

If at all possible do not provide access at all the more access you have to give the more likely it is this will be abused. If you think you are being paranoid you need to look for another job you can never be paranoid enough ;-)

In all honesty I think that GWT is not a very good platform for secure applications for the simple reason that a lot of the hiding of functionality happens on the wrong system (the client side). Now there is a lot to say against security trough obscurity but look at it this way if you had never seen or heard a bout an iPhone or iPad would you want one? Exactly 99% of the people would say no to that and that means a big reduction in the number of people that might try and get one...

If you are working on a system that should be as secure as possible I would advocate against GWT simply because as originally said most of the hiding of functionality happens on the wrong system which means that attackers gain a lot of knowledge that would otherwise be just that bit harder to come by. Of course there is nothing stopping them from gaining this knowledge anyway, but every hurdle is one more reason to leave your site for what it is and try to mess with your neighbors site instead.

No matter how many people advocate against the obscurity argument less information is the reason wars have been lost and in this day and age where information makes Google... restricting access to information means slightly more security for your site no matter which way you look at it.