Protecting session IDs brings up a few interesting security questions.
First and foremost is that if cookies are used for state management, servlet
engines *should* set the cookie's Secure attribute if a cookie is sent over
HTTPS. This is not mandated by any spec but follows from RFC2109 (cookie
spec) as the only meaningful way of using the Secure attribute in servlets.
This will instruct the user agent (browser) to use only secure means to
contact the servlet engine whenever it sends back this cookie. The "secure
means" are not specified in RFC 2109 but cookies are only used by HTTP, so
HTTPS is the first logical and certainly the most feasible choice. Afaik,
very few servlet engines do this today. (There are several practical
considerations here which may render the entire scheme useless).
The other side of the coin is the user agent. What should the browser do
with a cookie that has its Secure attribute set? Never persist it? (What
happens if the cookie lifetime is set to 'infinity'?) Send it to the origin
server only if the protocol is HTTPS? Currently this behavior varies across
browsers (what else is new) and as such cannot be relied on.
...but cookies are only one way to manage state, URL rewriting being another
one. A rewritten URL doesnt 'know' about being secure. (Yes, you can use
hidden fields and javascript to achieve some results but boy is this a lot
of trouble).
Having said this, I concur that access control on the application side is
the best way to go. Filtering by IP works in many cases. If your application
has well-designed workflow, you can try a state machine that would raise an
alarm if an illegal state transition occurs.
As an aside, I dont see how encrypting the contents of the cookie would
prevent a spoofing attack, at least not without resorting to additional
infrastructure tricks on both the client and the server side. Craig, can you
elaborate? (Btw, you should at least indicate in your signature that you're
one of the JServ developers lest the readers be led to trust your
"independent" opinion).
Alex.
"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>When using cookies, the session ID is just as easy to grab, because it is
>sent
>in every request. Being "invisible" doesn't make it any more secure.
>
>In either case, all you can do with a session ID is to impersonate an
>existing
>user (by sending requests to your existing servlets with the stolen session
>ID), and this only works for the duration of the existing session (servlet
>engines will generally use an algorithm that does not create duplicate
>session
>IDs). Some fairly simple "traps" in your servlets, such as making sure all
>the requests for the same session come from the same client IP address, can
>cut down lots of potential problems. But, the more secure protection would
>be
>encryption -- then, snooping the session ID in the first place becomes much
>more difficult.
>
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
