Container based authentication / authorization

[dave]

Hello,

New to Java web apps and trying to understand how container based
authentication / authorization.

When a user is authenticated, how does the server/container determine
that the same user is returning on subsequent requests, since HTTP is
stateless? Is this information tied into the users session (i.e. saved
with JSESSIONID key in tomcat)

If it is tied into the session, then could someone intercept this
sessionid and impresonate a user by faking their own HTTP request with
the same session id?

 

[froboz]

Hello,

New to Java web apps and trying to understand how container based
authentication / authorization.

When a user is authenticated, how does the server/container determine
that the same user is returning on subsequent requests, since HTTP is
stateless? Is this information tied into the users session (i.e. saved
with JSESSIONID key in tomcat)

If it is tied into the session, then could someone intercept this
sessionid and impresonate a user by faking their own HTTP request with
the same session id?

It's customary to track state informating using the JSESSIONID as you
suggest. While the JSESSIONID is is covered by J2EE specification the
algorithm used to create the JSESSIONID is not. Therefore the
posibility of stealing anothers session, called "session hijacking" in
the security world, is very real and depends largely on the
implementation of the application server. And I will say not all the
servers are as secure as they should be.

There are a number of ways to improve session security:
1) Don't depend upon the JSESSIONID of the application server as the
authoritative source.
2) Don't rely on measures in the browser to validate your data.
Special programs like paros proxy can be used to edit any get/post
parameters on the fly quite easily. Your servlet should also validate
all information inbound from the browser.
3) Use care when inlining content of others into your web pages.
Depending upon the scenario it's possible for JavaScript programs to
hijack a session.

One measure you can take that's quick is to keep track the IP address
of users computer used during authentication. Store the IP address in
the session. Then check to see if the IP address changes in
subsequent posts. This is not fool proof. For example, most ISPs use
DHCP and the lease may have expired. Or it's always possible some
spoof'ed the IP address. However, you start adding in these and other
measures and it does improve the strength of your system. Commerical
systems may also use solutions like SiteMinder and/or X.509 digitial
certificates on both client and server.

Milton Smith
(e-mail address removed)

 

[Arne Vajhøj]

New to Java web apps and trying to understand how container based
authentication / authorization.

When a user is authenticated, how does the server/container determine
that the same user is returning on subsequent requests, since HTTP is
stateless? Is this information tied into the users session (i.e. saved
with JSESSIONID key in tomcat)

Stadard is: session cookie with fallback to URL rewriting.

If it is tied into the session, then could someone intercept this
sessionid and impresonate a user by faking their own HTTP request with
the same session id?

Yes.

But guessing a 128 bit integer can be hard.

If it is intercepted, then it is a piece of cake.

So configure the web app to only accept HTTPS if
that is an issue.

Arne

 

[Roedy Green]

When a user is authenticated, how does the server/container determine
that the same user is returning on subsequent requests, since HTTP is
stateless?

Get a sniffer to see how it is done. It might be a cookie. It might
be the IP, it might be something in the header. See
http://mindprod.com/jgloss/sniffer.html