S
Sylvan von Stuppe
Is there a way according to the J2EE standard for a user to be given a
new session ID when they switch from unauthenticated space to
authenticated space, while still using container-managed AAA?
The problem is that if an attacker can fixate a user on an
unauthenticated cookie, the attacker could make requests to an
authenticated page with the unauthenticated session id until the victim
logs in. Once the victim is logged in, the attacker has the token.
There are lots of ways for the attacker to fix the victim on the
cookie, so that's not hard. It's also not hard for the attacker to
keep the session alive indefinitely (J2EE also doesn't give an option
for a hard session length, even with activity).
For a simple (but not necessarily as effective) scenario, assume a
computer in a shared environment like a hotel business center. The
attacker goes in and just goes to the login page of your app. They
receive a session token, but then they don't log in. They record the
session token, then on their own machine, write a script to hit some
private page in the app, using the same session token. They just try
it every 5 minutes or so. For awhile, they keep getting sent to the
login screen. But if a victim uses the same browser session the
attacker set up, once they log in, the attacker will actually be able
to get to that private page.
Is setting a new session token on auth be something that should be in
the J2EE standard, or would that be an implementation-dependent detail?
new session ID when they switch from unauthenticated space to
authenticated space, while still using container-managed AAA?
The problem is that if an attacker can fixate a user on an
unauthenticated cookie, the attacker could make requests to an
authenticated page with the unauthenticated session id until the victim
logs in. Once the victim is logged in, the attacker has the token.
There are lots of ways for the attacker to fix the victim on the
cookie, so that's not hard. It's also not hard for the attacker to
keep the session alive indefinitely (J2EE also doesn't give an option
for a hard session length, even with activity).
For a simple (but not necessarily as effective) scenario, assume a
computer in a shared environment like a hotel business center. The
attacker goes in and just goes to the login page of your app. They
receive a session token, but then they don't log in. They record the
session token, then on their own machine, write a script to hit some
private page in the app, using the same session token. They just try
it every 5 minutes or so. For awhile, they keep getting sent to the
login screen. But if a victim uses the same browser session the
attacker set up, once they log in, the attacker will actually be able
to get to that private page.
Is setting a new session token on auth be something that should be in
the J2EE standard, or would that be an implementation-dependent detail?