-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,
On 3/28/18 7:20 PM, Alex O'Ree wrote:
> Does tomcat do any validation on session id's based on up
> addresses? I'm thinking that if some one intercepts the session
> token and tries to use it from another ip address, then it's
> feasible to detect this and invalidate the session.
This is basically a session-fixation attack[1]. Another flavor of the
attack is to simply guess a valid session id and take-over the session.
Tomcat does not include any capabilities to mitigate these attacks.
It's fairly easy to implement such a mitigation by using a Filter that
does something like this:
void doFilter() {
session = request.getSession(false);
if(null != session) {
if(!session.storedIP.equals(request.IP))
response.sendError(403);
}
// invoke the filer chain
}
There are several problems with this technique, not the least of which
is that any proxy between you and the client will change the IP
address of the "client" such that multiple clients can look like a
single IP address. AOL is famous for all users coming from a small
number of IP addresses.
Another reason this might be a problem is with mobile devices. IP
addresses can change for various reasons. Forcing the user to
re-authenticate may be inconvenient in that setting.
Finally, guessing a valid session identifier is infeasible. Tomcat's
default 16-byte session id provides
340282366920938463463374607431768211456 possible session identifiers.
Assuming that java.util.SecureRandom provides sufficient entropy to
make all possible session identifiers equally possible, and an
attacker can try an Internet-melting 1,000,000,000 (1B) session
identifiers per second, it would take 10812500537664228356827 years to
perform an exhaustive search. Most session identifiers are only valid
for a few minutes or hours, so random guessing is simply infeasible.
As for interception of a valid session identifier, the solution is to
use TLS so interception is infeasible under most circumstances.
As for mitigations session-fixation specifically (where the attacker
tricks you into using a known session identifier for authentication),
Tomcat changes the session identifier when authentication occurs.
Assuming the attacker cannot see the request/response where the
authentication occurs (in which case, they could intercept the
username and password, therefore session-fixation isn't necessary),
only the legitimate user will see the session-identifier change, and
the attacker is thwarted.
Hope that helps,
- -chris
[1] https://en.wikipedia.org/wiki/Session_fixation
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9FJIACgkQHPApP6U8
pFhIuRAAkaYp2FQ2KeE6wyFeEszMIwZbm1eNwdpYWpxv0sxAu+nDfFZd0+Lej+fK
5CrNzR6fimgAmIxH6PEK+rJ6gpELLF1zBfbX34e8/cRkdw6oZP1xajNCXt8DbiPl
upnCkRDNv6XklkkvNikrW6RPnknEXMNIEayKz3gpLZ7J02PVNjQk8hHC2Z+r8BKC
C+VGyNMeNQbYegUVs6tf1bR0kbDCn4xr1s5+Urui2KS5ru59EiPN8NIA6uYdE1aq
HeJAbFRrywsjcK3r6mPzQmXIshOW0SWzNqorBUfiByAcjXVtipvCz5G/zgtKhsqn
0wNsZuT7Xd1Af0/5b+FYVd0U12ZTjSX1S77cvGufFw6OIRY2VEkni8Om0cdGiBKz
Hy88VDhyLSwGclZnxuKaj1GAGKktptv/iPACTZxpZrVUWaHR1f1HvFzDUVV4DWQ7
s9aRbCNdbRuUkvsLduGtI1EsqD1vmhDWhO01e3kd6OAaa6rCOJ9uXRbFOruwkg9E
qeqbTxHQTgJ3jC/3h+sQCvVQt29GCjtKHoRwDCCiIeU/oDsygy5kxXTJai9OjoF2
IaAeTa1XfM+Y+fz9pZOP560k2VtBc4cWucFKuffmMvyi/or8ChKJ3lD/a7mn9Hq3
vmLstp0MLl0cDSduhYm5YD7VPGf900F9YtcMWCIM6bb1S9lp9ac=
=1fdw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
