Thanks for the info
On Thu, Mar 29, 2018, 12:30 PM Christopher Schultz <
ch...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
