Thursday, January 2, 2014

Path Encoding Vulnerability in https/www redirects.

Playing with 302-based header injection (majority of web servers is not vulnerable to it btw) i found one tricky neat bug which can be really useful to leak ?query data by putting them in the #fragment.

Remark about the difference: fragment might seem to be more secure than query - no, I don't think so. There are just thousands of open-redirects out there leaking access_token-s. I personally found an open redirect leaking user's token on 2 out of 3 huge websites i checked. I only stopped looking for open redirects because I don't exploit and there's no market for "facebook access_tokens" (let's create one?)... whatever

Yes, ?query can be leaked with Referrers but you can easily deny them - you never can't be sure you don't have open redirects.

Tip 1. do not send sensitive info in #fragment because 302 redirect will leak this data.

Problem: many web servers are configured in a way to redirect to - they kill initial encoding, putting query data in location.hash. And this is a vulnerability.

To demonstrate the bug in the wild I created this demo. Hard Mode solution by the way:

Any ?private_info can be turned into #private_info and be leaked easily with a 302 redirect.

Chain looks like this
Provider Issues a Token -> Client-WWW-redirector%23?Token -> Client-redirector#?Token -> Evil#?Token. 
There were basically only two ways servers could "screw" path encoding: https and www related redirects.

Tip 2. check https->http />site redirects to find Path Encoding Vulnerability. 

Let's check www-redirects against our Lazy list. Here is my lousy script.
For "/?x=%23x" payload almost nobody is vulnerable because encoding request.query seems obvious.

Let's check '/%23x'
....i killed the script , it's only first 500.

Check if your server turns %23 into # and patch it if you don't want your Single Sign On to be hacked.
Be careful with encodings. Many servers are configured in a wrong way + Microsoft IIS is vulnerable by default.


  1. Встречали такое, ога :)

  2. About "Microsoft IIS is vulnerable by default..." you are quite wrong, just IIS 6.5 is vulnerable, and only if the IT doesn't install the patch, but 99% IIS 6.5 are fixed.

    Just a remark apache and nginx are also vulnerable by default, if you don't know how to configure them.


    1. really? do you have 6.5+ demo online i could check?

      I assumed last version is vulnerable because all MS sites like and were left vulnerable.

      on top of that IIS security team doesn't understand the issue

    2. hi there egor, im reading all your post since early 2013. can i ask something? can you give me your email? im gonna tell / ask something, i recently found a bug on facebook and i need your help in confirming it, thanks in advance.

      Here is my email if you want to email me: