On 22 oct, 16:15, Falcon <msu.fal...@gmail.com> wrote:
> The web, in general, is stateless, and http is a stateless protocol.
> The upshot of this is that every time you send a request to a web
> server it has no idea who you are without some identifying piece of
> information.
>
> So, once a session has been set on a server, that session has an ID.
> The user has a cookie on their computer that contains the ID of that
> session. Without that ID, the server has no idea what session to look
> up, so if you call session.getAttribute("userId") without the client
> sending a session ID, you wouldn't get back anything. Every request
> the user makes to your server, they're sending across the cookie with
> that session ID so that your server knows what session information to
> look at. Keep in mind that there could be any number of users on an IP
> address, so IPs can't be used for that sort of thing (not to mention
> IPs can be spoofed, so if servers used IP addresses for that sort of
> thing sessions could be hijacked extremely easily!)
>
> As far as rebooting their PC: that entirely depends on both your
> server session and cookie settings and the user's cookie settings. The
> cookie can be temporary so that as soon as they close their browser it
> disappears, it can be effectively permanent (set to expire 1000+ years
> into the future, for example) or anything between. You can set your
> sessions on the server to expire as quickly as you like as well. If
> the client's cookie goes away, they won't have the session ID to use
> to call up that session. Similarly, if the session expires on the
> server and thus is deleted, the user would be logged out even if they
> still have the cookie.
>
> So that's why when you're sending RPC requests to your server, unless
> those requests should be able to be made by the public in general, you
> need some form of user identification/authentication on them.
> Otherwise I can just produce my own RPC request to your server outside
> of your app and perform any RPC request I want.
>
> There's quite a bit of reading on this topic, but hopefully that's a
> decent overview to give you a bit better understanding of what's going
> on. Feel free to ask more questions and I'll try to help.
The other thing to look at is Cross-site Request Forgery (CSRF), and
this is why your session Id SHOULD be sent within the request (payload
or request header, but *explicitly*, contrary to cookies which the
browser will decide whether to send, and with which value). It doesn't
mean you shouldn't use servlet sessions (with the cookie to relate the
user to the HttpSession object), but that if you do you should at
least *also* send the session ID explicitly in the request, and check
on the server-side that it's the same as the session ID the servlet
container will use (getThreadLocalRequest().getSession().getId()).
You should also check if the session comes from the URL rather than a
cookie to avoid session fixation attacks
(isRequestedSessionIdFromURL): setting the session ID explicitly in
both the URL and the request payload or headers so someone will start
using *your* session (as the attacker), and then hope it'll stick (the
server sending back a cookie for the session ID), the user doesn't
notice, *and* it starts entering sensitive information (so you, as the
attacker, can read it back).
With GWT-RPC, CSRF is fortunately harder to achieve, but not
impossible.
--
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-web-tool...@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.
