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. There has been academic papers criticizing this bearer token pattern. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final162.pdf > > 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. > > 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. > See above. > > > 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. > > > 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. > > > 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. > > > 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. 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 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. Roel
