Roel, On 11/24/15 10:43 AM, Roel Storms wrote: > 2015-11-24 16:11 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >> : > >> Roel, >> >> On 11/24/15 9:44 AM, Roel Storms wrote: >>> I am trying to protect the client from: >>> >>> Session fixation >> >> Tomcat already provides session-fixation protection when using URL-based >> or cookie-based session-tracking. When authentication occurs, Tomcat >> will change the session identifier, effectively mitigating session >> fixation. >> >> I'm not saying that Tomcat is vulnerable if used correctly. I am saying > that > naive implementations using cookie based session management can be > vulnerable. Tomcat and other middleware will indeed try to cover up > these security issues. We want to change the basic shortcoming that an SID > acts as a bearer token.
But you are saying that you want to replace bearer tokens (defined by you as intractable) with a new kind of bearer token. I don't see you having much luck without a lot of infrastructure. Since one of your initial requirements was "minimal infrastructure", your proposal is current indistinguishable from magic. >>> Session hijacking >> >> I'm interested in your plan for this that (a) is transparent to the >> application, (b) is easy to implement on the server and (c) does not >> require any changes to the client. >> > I have changed the client. I have a working implementation in Chrome > that does everything except for body integrity checking. TLS also > need both client and server side implementations. Cookies also have > to be supported at the client side. So, this is something that the application doesn't have to know about, but every other component in the works DOES need to have it? The list of conflicting requirements here is really amusing to me. >>> Maybe I also want to check integrity of the response since otherwise an >>> active MitM attack can still modify this. >> >> If you have solved the client -> server integrity, then server -> client >> integrity ought to be trivial. >> > > True, but I'm not sure I want to cover active MitM. If you want to protect > against that you should use TLS. I'm simply trying to replace the > fundamental insecurity of SID. If you can change both client and server, then simply negotiate a secret (during your "safe" session-establishment step, which you have asserted but not described) and sign everything in both directions. Problem solved. >>> An attack could consists of an attacker modifying the action >>> attribute of a form to send login data to the attacker instead of the >>> web application. >> >> A reasonable attack scenario, especially with the attacker has a MitM >> position. >> >>> But this again looks a lot like TLS with DH_anon. >> >> It does? Or do you mean even if TLS is used with anon-auth (i.e. ZERO >> auth), the client isn't protected from MitM? > > > Doing integrity checking on both request and response and doing this > integrity check for almost the entire HTTP request/response looks > a lot like TLS. It sure does. If you only protect a part of the payload, what's stopping the rest of the payload from attacking the "safe" part? E.g. fingerprint the first 1k of the HTML document, but the attacker injects javascript at the end which goes-in and re-writes the DOM. Partial protection is zero protection. >>> Al we want is to replace the current session mechanism >>> where the ID is a bearer token by a mechanism based on a shared secret >>> (shared via DH). >> >> How is this different from "standard" TLS-sessions (formal TLS sessions, >> not Tomcat's session ids in cookies transmitted via TLS)? > > > The difference is that TLS assures integrity of the entire packet. Which is > not compatible with web infrastructure. Also TLS is often not deployed. > Or even if it is deployed there is still mixed content being server. > Our sessions would be applicable to both types of content. > > "To our knowledge, SecSess is the only session management > mechanism explicitly designed to be compatible with currently > deployed Web infrastructure, such as web caches." > https://lirias.kuleuven.be/bitstream/123456789/503824/1/p2171-de_ryck.pdf > > I haven't validated this claim but my thesis builds upon this paper. Now I know why this was all sounding *really* familiar. I've ready this paper and -- maybe I'm just not smart enough but -- it seems like a lot of fanciful thinking without solving a real problem. It uses real problems to invent straw men that it then solves with a dubious solution. This idea is a SELL, not a BUY. >>> This will inhibit script based attacks that steal the SID >>> and also eavesdropping attacks. It's not perfect but we also believe that >>> if you have an active MitM, you have bigger problems than securing your >>> session management. >> >> Of course. That doesn't make it an interesting scenario, though. >> >>> The perfect solution is still something including SSL/TLS (it's not >>> cookie based since even over SSL cookies can be leaked if not set >>> properly and we don't want a configuration mistake to become a >>> security issue). >> >> Configuration mistakes can always result in vulnerabilities. The only >> way to fail-safe would be to disallow all "unsafe" configurations, which >> would make the software *quite* unusable. >> > Some configurations which are possible for cookies or tricks which are > possible with url-rewriting aren't possible with a session management > mechanism that was explicitly designed as a session management > mechanism. Now the middleware is trying to shield this underlying complexity > from application developers but it doesn't make the complexity disappear. > Someone still takes care of it. In this case Tomcat does. We want a > session mechanism that shield every middleware developper from these > security issues. Cookies weren't designed with security in mind. Neither > is the workaround we call url-rewriting. It's as if people kept patching t > he existing solutions without realizing that the fundamental bearer token > property model should be replaced. Obligatory: https://xkcd.com/927/ > I know it sounds like an attack on Tomcat but I am just trying to prove > that replacing the session management by something inherently secure > is possible and would not affect application developers much. I'm not taking this as an attack on Tomcat at all. I just think you are cherry-picking a bunch of issues that have already been solved and merely claiming that they aren't solved (or not solved satisfactorily... which is always impossible to argue against) just to justify the creation of another mechanism. And it's not even a very interesting mechanism. In an environment where no party can be trusted, how do you establish trust? The answer is that you don't: you exercise good judgment and do your best. I don't see the proposed solution as adding anything meaningful to web technologies. (Prove me wrong, kids!) >>> I am not trying to protect from: >>> >>> An active MitM attack during session establishment >>> Malware at either client or server-side >> >> -chris >> > I don't know if our discussion remains relevant on this mailing list. > If you believe it isn't you can contact me personally. I don't want to > spam the mailing list when it's not relevant. I'm not interested in having a drawn-out academic discussion about this. If you have questions about implementation within the Tomcat framework (or even outside of it), feel free to continue this thread. As for the original question of this thread, I believe it has been answered. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
