unvalidated redirects and forwards

During an external pentest the following bug came to light. As BMG we consider this a minor issue (a situation with man-in-the-middle allows for a lot worst to happen). For your consideration. Credits to Verizon.

Summary

The HTTP "Referer" header is not being validated and could cause the web application to redirect the request to the specified URL. By modifying the Referer value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site (on some browsers), phishing attempts have a more trustworthy appearance.

A successful attack requires the perpetrator to identify an id for an existing system hook. That can be easily guessed as it is numeric and usually starts with "1" for configuring the first system hook or it can be obtained through social engineering efforts. If an attacker was able to conduct a Man-n-the-Middle attack, using an intercepting proxy that is owned by the attacker it’s possible to spoof the Referer header to perform a redirection.

RECOMMENDATION: Redirections should be either hardcoded server side or subject to input validation functions following a whitelist approach. To avoid the open redirect vulnerability, parameters of the application script/program must be validated before sending a 302 HTTP code (redirect) to the user-agent.

Steps to reproduce

Request:

GET /admin/hooks/17/test?trigger=repository_update_events
...
Referer: https://evil.website
...
Connection: close
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 302 Found
Server: ...
Date: ...
Content-Type: text/html; charset=utf-8
Location: https://evil.website
...