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. > 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. > Assure that requests that are received in an established session can't be > modified in transit (integrity of requests). Without TLS or trusted code running on the client, I don't see a viable solution. > 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. > 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? > 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)? > 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. > I am not trying to protect from: > > An active MitM attack during session establishment > Malware at either client or server-side -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
