CVE-2021-41553

In ARCHIBUS Web Central 21.3.3.815 (a version from 2014), the Web Application in /archibus/login.axvw assign a session token that could be already in use by another user. It was therefore possible to access the application through a user whose credentials were not known, without any attempt by the testers to modify the application logic. It is also possible to set the value of the session token, client-side, simply by making an unauthenticated GET Request to the Home Page and adding an arbitrary value to the JSESSIONID field. The application, following the login, does not assign a new token, continuing to keep the inserted one, as the identifier of the entire session. This is fixed in all recent versions, such as version 26. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Version 21.3 was officially de-supported by the end of 2020

In ARCHIBUS Web Central 21.3.3.815 (a version from 2014), the Web Application in /archibus/login.axvw assign a session token that could be already in use by another user. It was therefore possible to access the application through a user whose credentials were not known, without any attempt by the testers to modify the application logic. It is also possible to set the value of the session token, client-side, simply by making an unauthenticated GET Request to the Home Page and adding an arbitrary value to the JSESSIONID field. The application, following the login, does not assign a new token, continuing to keep the inserted one, as the identifier of the entire session. This is fixed in all recent versions, such as version 26. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Version 21.3 was officially de-supported by the end of 2020

** NO SOPORTADO CUANDO SE ASIGNÓ ** En ARCHIBUS Web Central 21.3.3.815 (una versión de 2014), la aplicación web en /archibus/login.axvw asigna un token de sesión que podría estar ya en uso por otro usuario. Por lo tanto, era posible acceder a la aplicación a través de un usuario cuyas credenciales no se conocían, sin que los probadores intentaran modificar la lógica de la aplicación. También es posible establecer el valor del token de sesión, del lado del cliente, simplemente haciendo una solicitud GET no autenticada a la página de inicio y añadiendo un valor arbitrario al campo JSESSIONID. La aplicación, tras el inicio de sesión, no asigna un nuevo token, continuando con el insertado, como identificador de toda la sesión. Esto está solucionado en todas las versiones recientes, como la versión 26. NOTA: Esta vulnerabilidad sólo afecta a los productos que ya no son soportados por el mantenedor. La versión 21.3 dejó de recibir soporte oficialmente a finales de 2020