-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
Wow. I wrote a book. Sorry for my uncharacteristically long exposition. On 8/18/2010 5:40 AM, André Warnier wrote: > Could/should not Tomcat at least verify, when it gets a JSESSIONID from > a client and retrieves the corresponding session information, that the > IP address of this current client matches the client IP address (which > would have been) previously stored in the session ? > > Or would this introduce other problems ? Sometimes a user's IP changes for one of several reasons: 1. Internet connection dies / re-establishes with a new BOOTP/DHCP IP 2. Came through a different proxy on different requests 3. You have AOL, who apparently loves to play games with IPs This is a good security feature to allow users to opt-into, though. There's a filter in securityfilter (have I committed it, yet?) to do just this, and it's user-selectable at login (or any time? I'll have to look at the code again). > I know that it is not really a "solution", because hapless users will > anyway continue (mostly innocently) to email links to their colleagues, > and they will wonder why they do not work. If security has been implemented correctly, Tomcat will ask the user for their credentials and ultimately give access to the requested resource once authentication has been completed successfully. That's part of the spec: one that works quite well for users IMO. > If I understand correctly how it works, then currently the following > scenario is possible, isn't it ? > > But because the link contains the jsessionid of the first user, the > colleague would gain access to the resource, without either one of them > even thinking about it. Yup. This is called session hijacking. It can be performed against any web server using non-SSL sessions (I mean an SSL-session, not just an HTTP session being used over HTTPS). Note that "disabling" the jsessionid parameter being added to URLs does not in the slightest way prevent a hacker from crafting a URL that contains a jsessionid and using it to hijack a session. Not only that, but there's no spec or Tomcat requirement that the session be accessed via SSL. That means that if you, André (the "good guy") log into your secure web application using HTTPS and establish a session, I (the "bad guy") can hit http://yourserver/secretStuff.jsp?jsessionid=12345 and, if I've guessed your session id correctly, I get to masquerade as you. In fact, I believe Tomcat will continue sending Set-Cookie headers, so once I've sent my specially-crafted URL to the server, I don't even have to go through the pain of re-writing every URL I see: I've got the same cookie you do, now, too (except mine probably doesn't have secure=true set). Note that guessing a session id is non-trivial, so it may take a long time to accomplish. The good news for hackers is that there is no built-in anti-hacking mechanism to prohibit remote users from simply attempting to hijack session id after session id, so they can try all day to break into a standard Tomcat server. No, I haven't yet written a filter that can capture these attacks and try to mitigate them. > This is inside a corporate LAN, where one would normally tend to > consider communications as "trusted", and thus to not really need SSL. Hah. Trust no one. > But by simply exchanging this link, the users unwittingly or not break > the access control mechanisms buried deep into an application. > Furthermore, now these two users can continue to interact with the > application, both within the same Tomcat session, although they are on > different workstations altogether ? > > To me, that sounds really bad. It's not terribly good. Note that the presence of the jsessionid in the URL is not really the attack vector: it just makes the attack vector slightly more convenient for hackers or idiots. Cookies have the same "danger" in that anyone can send any cookie to any web server. The real problem is allowing remote clients to self-authenticate -- that is, provide an otherwise non-corroborated credential (that's the session id) to the server. The only really good way to secure a session to a single user is to use SSL client certificates with the cert fingerprint stored in the session. Even then, the client cert can be shared with others so you're really just shrinking the pool of potential session hijackers to those who might be able to get their hands on an SSL cert. With credentials, it's always something you know or something you have (or something you /are/, but that's not practical for web-based security). Something you know can always be guessed if given enough time. Something you have is almost always better than something you know, especially if it's not duplicatable (is that a word?) like one of those dongles they used to use for software licenses. Coupling the two is pretty much as good as you can get (which is why they call it "two-factor authentication" and why it gets so much hype). By the way, anyone not using SSL certificates who says they use two-factor authentication for web-based security is lying to you: they are using dual-single-factor authentication which isn't the same thing. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxsrlMACgkQ9CaO5/Lv0PBOwwCglfn3vlTddtQ1Sgo74QavDdcP oMgAoL/D+NzPfpJDYEo4DWCj6/EeLBXh =3En+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
