Open secure redirect

left or right

Aren't those RFC docs amazing ? Reading up on standards ?

I needed plenty of time for them, as I encountered some interesting issues. As it turned out, some websites / loadbalancers are overly optimistic in encrypting all the things - actually, in redirecting all the things.


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 --http TARGET

See for the latest version of

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.


% curl -sI http://VICTIM/


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 …
more ...


As you probably read somewhere else, and on another place, and another... on March 3rd 2015, another attack on SSL/TLS was published. Following the tradition of BEAST, CRIME, Heartbleed, LUCKY13 and POODLE this one also has a catchy name: FREAK (Factoring RSA Export Keys).

It's a man-in-the-middle attack where a man in the middle can decrypt a SSL/TLS connection between a client and a server.


Vulnerable *servers* are servers that accept export-grade ciphers (RSA-EXPORT). Checking whether a server is vulnerable can be done in many ways.

analyze_hosts --ssl HOST

If you see any EXPort ciphers, the server is vulnerable.

cipherscan HOST:443

If you see any EXPort ciphers, the server is vulnerable.

  • Yet another way is by using nmap:
nmap --script ssl-enum-ciphers -p433 HOST

If you see any EXPort ciphers, the server is vulnerable.

You get the idea...

Mitigate this vulnerability server-side by making sure that your server doesn't allow export ciphers in the OpenSSL configuration: add the following expression


There are also vulnerable clients...

Clients using OpenSSL are not vulnerable if they were built after CVE-2015-0204 was published.

The …

more ...

unsafe HTTP methods

Vulnerability name: Unsafe HTTP methods

  • Web server HTTP Trace/Track method support
  • Cross-site tracing vulnerability
  • Dangerous HTTP methods
Although this is a server configuration issue, the client is at risk here
Disable TRACE and/or TRACK and/or DEBUG methods


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 [1].

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


When an OPTIONS method is issued, the webserver should return the supported methods. Some web servers have a habit of replying with methods that are in fact not supported - which does not combine nicely with inferior security scanners (and pentesters, I might add) that relying …

more ...