Re: Security considerations for GWT applications

[Ed]

Use SSL for Security, never send a clear text user id password over the wire.
If a user navigates away from app then they should log in again.

ed

On Wed, Oct 24, 2012 at 5:41 AM, Flying-w <simonj...@googlemail.com> wrote:
> I am investigating security considerations around the user login for a GWT
> application in respect of the following strategy:
>
> User enters their id and password in a dialogue;
> Client transmits the login request with the above details to the server
> using RPC;
> Server returns a token unique to the client. The client stores this in a
> cookie such that if they press F5 to reload the application, or navigate
> away and come back, they do not need to login again (within a timeout
> period);
> On every request the client sends to the server, the token is included in
> the payload of the request to authenticate the request;
>
> There are some obvious flaws in this approach:
>
> The "Eve" type hacker listening on the network can intercept the plain text
> userid and password and reuse them directly in their client;
> If someone gains physical access to the original users computer, can they
> lift the server token from the cookie and use the token on the their
> computer to impersonate the original user?
>
> What are the solutions to these security exposures:
>
> Use SSL. Any good guides about doing this with GWT? Does SSL also defeat
> the "Mallory" attacker that can also modify network data?
> Any non-SSL solutions?
>
> Perhaps there's a guide about this out there somewhere, but all I can find
> so far is information relating to javascript security.
>
> Thanks
> Simon.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/4MgiVSsFI3UJ.
> 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.

[Manuel Carrasco Moñino]

- Use Http-Only cookies so as any eventually injected js does not have access to the session cookie.

- You could compute and send the MD5 hash of the password instead of the clear one if the server is storing the password in MD5

[Abraham Lin]

On Wednesday, October 24, 2012 5:41:06 AM UTC-4, Flying-w wrote:

I am investigating security considerations around the user login for a GWT application in respect of the following strategy:

• User enters their id and password in a dialogue;
• Client transmits the login request with the above details to the server using RPC;
• Server returns a token unique to the client.  The client stores this in a cookie such that if they press F5 to reload the application, or navigate away and come back, they do not need to login again (within a timeout period);
• On every request the client sends to the server, the token is included in the payload of the request to authenticate the request;

This sounds awfully similar to a session cookie - any reason why you can't just use that? If you want to persist identity across browser sessions, then you'd need a separate cookie, but that would generate additional security concerns.

• Use SSL.  Any good guides about doing this with GWT?  Does SSL also defeat the "Mallory" attacker that can also modify network data?

Yes, use SSL/TLS. Configuration of SSL is primarily a hosting concern and doesn't really affect GWT per se, though there are some settings that you may want to specify in the server-side configuration (e.g. only transmit cookies over SSL).

If you're using SSL, the "Mallory"-style attacks require user intervention (i.e. accepting an untrusted SSL certificate), so you are somewhat "safe" in that regard.

• Any non-SSL solutions?

You could always write your own application-level encryption scheme, but this is likely to be much slower. Since you're already using HTTP, you might as well take advantage of the existing SSL facilities.

On Wednesday, October 24, 2012 2:38:51 PM UTC-4, Manuel Carrasco wrote:

- You could compute and send the MD5 hash of the password instead of the clear one if the server is storing the password in MD5

 

This doesn't really work against MITM attacks. As written, the proposal substitutes a password equivalent in place of the original password, which doesn't really provide any protection against unauthorized access to the system because intercepting the password equivalent would still be sufficient for access. It does protect the original password, though that's typically a lesser concern.

-Abraham

[Manuel Carrasco Moñino]

On Wednesday, October 24, 2012 2:38:51 PM UTC-4, Manuel Carrasco wrote:

- You could compute and send the MD5 hash of the password instead of the clear one if the server is storing the password in MD5

 

This doesn't really work against MITM attacks. As written, the proposal substitutes a password equivalent in place of the original password, which doesn't really provide any protection against unauthorized access to the system because intercepting the password equivalent would still be sufficient for access. It does protect the original password, though that's typically a lesser concern.

Exact this is not a protection for the target system, but a guarantee for the user so as her clear password is not seen in the wire. It is very usual for users to use the same password for different systems.

[Jens]

 For a secure GWT application:

- use SSL for the entire app

- check for SSL vulnerabilities and update your server accordingly 

- use your app servers session id and send it as payload from server to client during login and then from client to server on each request. On the server check the payload session id if its valid. This protects you against Cross-Site-Request-Forgery attacks. 

- if you need a "remember me for 2 weeks" feature then you have to use your own security token instead of the session id and store it in a database. That way you dont need a 2 week session timeout on your app server which costs server resources. 

- Protect yourself from Cross Site Scripting by using SafeHtml, SafeUri, SafeCss in GWT

- Keep SQL injection in mind on your server. Don't trust user input on the server! Use prepared statements.

- use a strong password policy

- use secure, HttpOnly cookies if the server needs to store some infos on the client via cookies. 

- Check for duplicate cookies (cookie overwrite attack)

- encourage users to use most modern, secure browser.

With all the above the only thing that could happen is that an attacker has physical access to the client host (directly or via trojan, key logger, etc.). In that case you can't really do anything against it. 

Technically there are also SSL men in the middle attacks but to make them work you either need a bug in SSL itself (so update it!) or the attacker needs to modify the browsers trusted CA certificates, issue a certificate for your server domain using the attackers CA and use DNS attacks to modify DNS entries so that your domain points to his server. You cant do anything against it as you are not part of the attack.

Have I forget anything?

-- J.

[Joseph Lust]

FYI, I just setup a GWT webapp running on Spring Security. Spring Security covers much of the above and more:

• Session Fixation prevention
• Easy to enforce HTTPS channel filters to force parts of site to run on SSL
• Facilities to persist (totally random) remember me tokens to database so they cannot be hacked/spoofed
• Easy to implement custom hashing/salting classes
• Request caching to auto-relogin and execute original request
• Easy clearing of all session/cookie information on logout/expiration
• Invalid session detection/handlers

It's fun to role all of your own security, and I've done it, but just implementing a few interfaces and changing some XML is far easier and I trust Spring more than I do myself to reinvent the wheel.

P.S. If you want autocomplete on login fields, you'll need to hide input fields in the html page and then pull those values to complete your GWT login form. It's been my experience that the browser only autocompletes saved passwords at page load, but does not complete form elements later inserted into the page.

Sincerely,

Joseph

[dhoffer]

Hi Joseph,

Did you post that GWT webapp running on Spring Security somewhere?  I have the Spring Security books its major shortcoming is that it doesn't cover GWT at all.  It would be great to have some good comprehensive examples of GWT using Spring Security.

Thanks,

-Dave

[Joseph Lust]

Hoffer,

I won't be posting that since it is a closed source site and sanitizing it for release is more than I have time for at the moment. However, while there are a lot of configuration files in such a setup, it is just vanilla Spring/GWT/Hibernate for which you can find example projects out on the net.

I just set the failure/success handlers for the <form-login/> tag in Spring Security and then made my login widget POST to the standard login form handler and the custom failure/success handlers return a Login POJO in JSON that is deserialized via AutoBean. I used these, rather than RPC, so that the stock Spring Security setup could be utilized without extending/overriding all of it to login over GWT-RPC.

The only other bit was having a GWT-RPC with methods to get the current user, and a method to determine if we're logged in. These allow the UI to switch to the proper private/public view when the page is loaded. Finally, I made a custom AsyncCallback implementation to gracefully handle session expirations.

Sincerely,

Joseph

[Juan Pablo Gardella]

Hi,

See this  sample: https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/fkbowz5-5do

Is integrate with spring security.

Juan

2012/10/30 Joseph Lust <lifeo...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/BxRXQChmcVUJ.

[Sebastian Rothbucher]

Hi, no offense - but I'd NEVER NEVER EVER send the MD5-ed PW or store an MD5 hash in the directory. Rather, I regard it paramount to send the password as-is (through an encrypted channel) and have the directory store it WITH A SALT value. Furthermore, you should bind against the directory instead of comparing the hashes. This way, you're free of bothering about the PW and can have the directory folks do it (in fact, Active Directory - for instance - does not show the pw(hash) at all... Good luck!   Sebastian

[Sebastian Rothbucher]

Hi, 

there is actually one more aspect: avoid correctly logged-in users (as others pointed out before: login on the server with a server session is required) can manipulate more data than you want them to. Using tamper data and consorts, you can see what goes back and forth via GWT-RPC. Consequently, your interfaces should be sufficiently slim to avoid users reverse-engineer and manipulate

So you end up with a bunch of things to make information sufficiently confidential (login, etc.), ensure sufficient integrity (slim interfaces) and infrastructure concerns to ensure availability 

Good luck

   Sebastian

On Wednesday, October 24, 2012 11:41:06 AM UTC+2, Flying-w wrote:

I am investigating security considerations around the user login for a GWT application in respect of the following strategy:

• User enters their id and password in a dialogue;
• Client transmits the login request with the above details to the server using RPC;
• Server returns a token unique to the client.  The client stores this in a cookie such that if they press F5 to reload the application, or navigate away and come back, they do not need to login again (within a timeout period);
• On every request the client sends to the server, the token is included in the payload of the request to authenticate the request;

There are some obvious flaws in this approach:

• The "Eve" type hacker listening on the network can intercept the plain text userid and password and reuse them directly in their client;
• If someone gains physical access to the original users computer, can they lift the server token from the cookie and use the token on the their computer to impersonate the original user?

What are the solutions to these security exposures:

• Use SSL.  Any good guides about doing this with GWT?  Does SSL also defeat the "Mallory" attacker that can also modify network data?

• Any non-SSL solutions?

Perhaps there's a guide about this out there somewhere, but all I can find so far is information relating to javascript security.

Thanks
Simon.