You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alex O'Ree <al...@apache.org> on 2018/03/28 23:20:38 UTC
User session validation
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.
Re: User session validation
Posted by Alex O'Ree <al...@apache.org>.
Thanks for the info
On Thu, Mar 29, 2018, 12:30 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: User session validation
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: User session validation
Posted by "George S." <ge...@mhsoftware.com>.
On 3/28/2018 5: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.
If you're using SSL, I don't think intercepting the session ID would be
possible.
--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com