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.
>

-- 
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/-/wgowLKX_zdoJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to