From a security reporter:
To trigger the vulnerability, an attacker would send a malicious
"/auth" URL to the victim.
The victim would access said URL, and login successfully.
The server would then respond with any HTTP headers the attacker
supplied in the malicious URL.
Please note that the URL points to the real Allura server, and
contains control characters (%0d%0a) in the return_to URL parameter.
The first URL will set the attacker-supplied cookie
(my-cookie-field=foobar) to the victim's session.
The second URL will make the server respond with a content length of
777, which will force the victim's browser to abort the rendering of
the page, since 777 will not match with the real content length.
return_to is used in many places, any of which could sanitize it. Seems like
do_multifactor have the
redirect() calls that are the critical spots though.
_verify_return_to usage could be expanded.
Log in to post a comment.