TL;DR

Never trust HTTP(s) clients, and be careful when setting up redirection rules. A non-RFC compliant client can trigger a (difficult to exploit) open redirect vulnerability, due to a non-RFC compliant server.

This vulnerability can be tested using

analyze_hosts.py --http TARGET

See https://github.com/PeterMosmans/security-scripts/ for the latest version of analyze_hosts.py

Be warned, long post ahead: A while ago I came across some servers that, when being sent insecure requests, responded with a redirect to the secure version.

Request:

% curl -sI http://VICTIM/

Response:

HTTP/1.1 301 Moved Permanently
Connection: close
Location: https://VICTIM/

So far so good, nothing fancy going on here. In fact, this is excellent behaviour. Insecure requests are immediately upgraded to secure requests.

However, the server seemed to be overly happy in redirecting, as it listened to the client-supplied Host parameter:

% curl -s -I -H "Host: MALICIOUS" http://VICTIM/

And the server responded by

HTTP/1 …

Vulnerability name: Unsafe HTTP methods

Aliases

• Web server HTTP Trace/Track method support
• Cross-site tracing vulnerability
• Dangerous HTTP methods

Scope

Although this is a server configuration issue, the client is at risk here

Remediation

Disable TRACE and/or TRACK and/or DEBUG methods

Verification

Using curl , one can employ one of the methods by hand:

curl -sIX TRACE $TARGET | awk 'NR==1 {print $2}'

Vulnerable when: the result is 200

One should expect (not vulnerable) 405 (Method Not Allowed) or 501 (Not Implemented) results.

This executes the TRACE method against $TARGET , and prints out the HTTP status code using awk . The -I parameter fetches the head only, -s stands for silent mode, and -X specifies the method.

The easiest way to test whether a server is vulnerable is by using the script analyze_hosts.py [1].

This script uses curl as well as nmap to perform multiple tests.

analyze_hosts.py --trace http://www.target.com