The Openfire 4.1.3 web interface is vulnerable to session fixation attack.
The web interface doesn’t change the JSESSIONID cookie value on successful login.
Thus an attacker:
1) Able to connect and receive a login prompt from the web interface, and thus able to obtain a valid JSESSIONID.
2) Able to intercept traffic from the admin’s browser to a non-TLS protected port on the same domain (e.g. port 80 if no STS is in place), or otherwise force a cookie for the domain.
Is able to set the admin's JSESSIONID cookie to a the value retrieved in step 1.
When the admin authentication is completed, the attacker is then able to use the known JSESSIONID to jump into the admin's session.
I’ve demonstrated the compromise works with a JSESSIONID which has never been authenticated successfully, and the admin using Firefox 52.0.2, the attacker using Chrome 57, using Apache2 in Debian Jessie “Header set” for the attacker.
'Header set "Set-Cookie" “JSESSIONID=<COOKIE VALUE OBTAINED EARLIER>; path=/; HttpOnly"'
Corrective action:
The JSESSIONID must be changed on successful login, so the value is only exchanged over TLS (the secure flag, already present, will then ensure it is not leaked, but doesn’t yet protect it from being set over insecure channels)
See the section: Renew the Session ID after any privilege level change.
The Openfire 4.1.3 web interface is vulnerable to session fixation attack.
The web interface doesn’t change the JSESSIONID cookie value on successful login.
Thus an attacker:
1) Able to connect and receive a login prompt from the web interface, and thus able to obtain a valid JSESSIONID.
2) Able to intercept traffic from the admin’s browser to a non-TLS protected port on the same domain (e.g. port 80 if no STS is in place), or otherwise force a cookie for the domain.
Is able to set the admin's JSESSIONID cookie to a the value retrieved in step 1.
When the admin authentication is completed, the attacker is then able to use the known JSESSIONID to jump into the admin's session.
I’ve demonstrated the compromise works with a JSESSIONID which has never been authenticated successfully, and the admin using Firefox 52.0.2, the attacker using Chrome 57, using Apache2 in Debian Jessie “Header set” for the attacker.
I forced the cookie by making the admin’s browser visit [http://[www.example.com:8444]|http://www.example.com:8444/] and then the admin logged in over https://www.example.com:8443 and the Chrome user was able to jump into that session by loading https://www.example.com:8443/
'Header set "Set-Cookie" “JSESSIONID=<COOKIE VALUE OBTAINED EARLIER>; path=/; HttpOnly"'
Corrective action:
The JSESSIONID must be changed on successful login, so the value is only exchanged over TLS (the secure flag, already present, will then ensure it is not leaked, but doesn’t yet protect it from being set over insecure channels)
See the section: Renew the Session ID after any privilege level change.
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Management_Implementation