The only way cookie based session management is secure, is when you apply a number of countermeasures:
Correct flags, path and domain attributes, no un-trusted applications on subdomains (solved by origin cookies), ... You run it over TLS to withstand sniffers. There is no clean mechanism to share a session between domains. Again people have invented solutions. OWASP had quite some information on the subject: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet Session management in Tomcat is secure because the developpers of tomcat have applied (almost) all of these countermeasures but not everyone is using middleware like Tomcat. If as you say there is no problem with session management, then why was 'Broken Authentication and Session Management' second on the list of the 10 Most Critical Web Application Security Risks according to OWASP? This is what SecSess is doing for you: http://randomoverload.org/wp-content/uploads/2015/09/2e36hF7158F31.jpg When I am in a hurry to get a website up and running and I have no resources to do so, security is going to be my last concern. If we can create a session management mechanism which outperforms current session management out of the box and allow an application developer to pick this option without any modification to his source code I think we could reduce the problem big time. I'm not claiming they aren't solved. I am claiming there is not A SOLUTION, but merely patches on an insecure mechanism. In theory everything should just run over TLS but for some reason that is not the case and for some reason there are still major problems with authentication and session management. I think we should look at the number of available solutions and try to improve it. I am not going to argue about something which clearly doesn't belong on this mailing list anymore. But I disagree with you on the fact that session management is fine the way it is. Thanks for the advice and I clearly have some technical stuff to work out. Roel 2015-11-24 19:15 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > 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 > >
