From SSRF to Local File Disclosure

2 min readNov 8, 2017

This blog is written about a bug (I believe), that was found on my last weekend. It located on a website from a private program X on Hackerone.

That website has an API, allows users input their URL and email. In the backend, there is a simulated browser, which tries to open that URL and send the screenshot to user’s email. Actually, I don’t have any idea about that simulated browser, not sure if it is a real one or not. First thing, I inject a requestb.in URL, and the received User-Agent is

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Personally, I am interested in SSRF bug, and this case I have the response, so, I thought that I might have some funs.

After the requestb.in URL, I tried my luck with:

http://localhost
http://0
http://127.0.0.1
https://localhost
http://localhost:8080
http://192.168.0.1

The server accepts these URL, open it and send the result to my inbox. But the received responses areErr: timeout for almost times.

The hard thing is the limited number of URLs to be inputted. So, I couldn’t do the brute-force to test Boolean-based.

OK. Now is the time for the local file:

file:///
file:///etc/passwd
file:///c/
chrome://about
about:addons

These above payloads had been used to injected as URLs. However, this time, the server stopped me and said that they are invalid URLs.

I paused when there are not any ideas in my head.

That night, after a cup of Asahi beer, I decided to brainstorm again.

Is there anything else that I forgot?

Oh, http ? Yes. file ? Yes. chrome ? Yes…. How about other services? ftp ?

Promptly, ftp://example.com has been inserted. It worked. Then, I was confused about which keyword had been filtered on the server. I replaced ftp by file , and it worked also. How so?

Yes. The problem is /// , we only need a couple of / , if there are more than, the server would think it is an invalid URL. Then, I tried with file:// .