The /gosa/password.php endpoint fails to sanitize the uid POST parameter, leading to a Server-Side Reflected XSS vulnerability as this parameter is later assigned to a Smarty variable of the same name and then rendered in the context of an HTML attribute in password.tpl. As a result, arbitrary JavaScript can be executed in the GOSA origin.
This vulnerability is very similar to the one reported as CVE-2014-9760, but uses a different endpoint.
Suggested fix (untested): Use set_post() to escape the value of uid before assigning it to the Smarty variable here.
The text was updated successfully, but these errors were encountered:
I checked some gosa installations to see if there is any user ID containing some "exotic" characters
that may be escaped as html entity by the function set_post().
Thanks for checking! Note though that this has already been used as a fix elsewhere in gosa: CVE-2014-9760, so it should not break any user IDs that are not already broken.
(Published here as requested by Gonicus)
The /gosa/password.php endpoint fails to sanitize the
uidPOST parameter, leading to a Server-Side Reflected XSS vulnerability as this parameter is later assigned to a Smarty variable of the same name and then rendered in the context of an HTML attribute inpassword.tpl. As a result, arbitrary JavaScript can be executed in the GOSA origin.This vulnerability is very similar to the one reported as CVE-2014-9760, but uses a different endpoint.
Suggested fix (untested): Use
set_post()to escape the value ofuidbefore assigning it to the Smarty variable here.The text was updated successfully, but these errors were encountered: