- **private**: Yes --> No
--- ** [tickets:#8190] HTTP response splitting vulnerability on return_to param CVE-2018-1319** **Status:** closed **Milestone:** v1.8.1 **Labels:** security **Created:** Tue Feb 27, 2018 04:12 PM UTC by Dave Brondsema **Last Updated:** Wed Mar 14, 2018 07:42 PM UTC **Owner:** Dave Brondsema >From a security reporter: ------ Summary: 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. PoC URLs: http://<allura-web-server>/auth/?return_to=/%0d%0aSet-Cookie:%20%3Bmy-cookie-field%3Dfoobar%3B http://<allura-web-server>/auth/?return_to=/%0d%0aContent-Length:%20777 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 `authenticate_request` and `LoginRedirectMiddleware` and `do_login` and `do_multifactor` have the `redirect()` calls that are the critical spots though. `_verify_return_to` usage could be expanded. --- Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
