Description of problem: Since new session id is not generated every time users login, authentication can be bypassed through session fixation attacks in the situation where attackers are able to fixate another user's session id. Once user logs in with the session id, attackers could also access the whole site as that user. Version-Release number of selected component (if applicable): oVirt 3.4.0-5 beta3 How reproducible: 100% Steps to Reproduce: 1. At host A, get a new session ID by accessing /ovirt-engine/webadmin/#login with any existing cookie removed 2. At host B, access /ovirt-engine/webadmin/#login, set JSESSIONID with the one got in host A 3. At host B, log in with admin(or any user) account 4. At Host A, verify if the session is considered as authenticated Actual results: User at host A can access the application bypassing authentication. Expected results: At any point at which a user interacting with the application transactions from being anonymous to being defined, the application should issue a fresh session token. Additional info:
This would normally be protected by wrapping the session in HTTPS, correct?
Also is the session ID properly terminated if the user hits the log out button? Or can they still login using the old session ID?
Answer to comment #1: I don't believe session fixation is prevented by using https. Answer to comment #2: When the user hits the logout button their session is removed from the backend session map. In order to do anything your session must exist in that map. I don't see a session.invalidate() in the logout method. In short yes, I believe the session is terminated, but we should probably do a invalidate on the http session just to be sure. In case we ever store anything important in the http session instead of relying on the existence of the http session in the backend map.
All referenced pathches have been merged, shouldn't this be in modified state?
This is an automated message oVirt 3.4.1 has been released: * should fix your issue * should be available at your local mirror within two days. If problems still persist, please make note of it in this bug report.