Tuesday, January 5, 2016

Referrer Leakage from HTTPS to HTTPS

From my recent bounty program participation, I failed to find any awesome bug for the whole bounty period. Requiring me to have an iOS9 to perform the full application test also one of the disadvantage as I don't own any Apple product :(

Then, I tried to look for any low hanging fruits on the application. Gotcha! HTTP Referrer Leakage!

When the password reset token provided to the user - after they reset - usually it'll come in a Hyperlink format where there are two ways for the user to use it. Either directly click on it or safely copy and pasted it in the browser.

I choose the second option in order to demonstrate the reset token is leaked to another external URL. And as can see in the figure below, the reset token actually being sent to the newrelic.com website.

Submitted this issue to the program's owner and the analyst responded that this is an issue that in 'Won't Fix' category. The first reason I obtained was it is because the referrer leaked from HTTPS to another HTTPS.
This is what actually hit something on my mind. I never thought about this before. Is the HTTP Referrer will not be logged by the external URL if both are using HTTPS?
With a help from my friend, we tried to simulate the situation. There are two cases. One from HTTPS to HTTP, the second one from HTTPS to HTTPS.

Doing some research  and found that, it is NOT!

Test Cases
HTTPS to HTTP will not leak the referrer

HTTPS to HTTPS will leak the referrer

By summary:

  • HTTP Referrer will not be leaked to another URL if it is transmitted from HTTPS to HTTP. 
  • HTTP Referrer will  be leaked to another URL if it is transmitted from HTTPS to HTTPS
So I get back to the bounty program to ask for review the submission again. Another staff replied with a better explanation why they consider this as a 'Won't Fix' issue. The reason are any of these:
(1) the impact is too low to qualify for a reward 
(2) a prerequisite to exploit the issue is heavy social engineering 
(3) a prerequisite to exploit the issue is being a man-in-the-middle or having theoretical access to a separate restricted resource
 So I believe the 1st reason is the suitable for this situation as the reset token in this case only one-time usable. The situation for an account to get reset via this issue is really rare by looking on the likelihood of it to happen. Furthermore, MiTM attack would not help in this case as the request is transmitted over SSL.

Nevertheless, no harm to submit the issue as they're are certain program that accepting this issue as a minor flaw and got rewarded.

  • https://hackerone.com/reports/738
  • https://hackerone.com/reports/13557
  • https://hackerone.com/reports/5691
  • https://hackerone.com/reports/47140

  1. https://isc.sans.edu/diary/When+does+your+browser+send+a+%22Referer%22+header+(or+not)%3F/16433
  2. http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
  3. http://stackoverflow.com/questions/323200/is-an-https-query-string-secure
  4. https://www.ietf.org/rfc/rfc2616.txt