Flickr ATO Fix Bypass

On Apr 5, I had a look on Flickr login flow with Yahoo. Not after long I ran into a Flickr bug that is quite something, it is a one-click attack (no click is required if the payload is embedded in img src) that allow attacker to steal Flickr’s user access token. So I submitted the bug to Yahoo happily, and hopefully I can get a good response from the report.

The next day, Apr 6, Yahoo team replied and told me it was a duplicate, there was someone who submitted the bug before I do. Heart breaking, but that’s normal for a bug hunter, move on, Ron, move on.

On Apr 21, I come across a tweet and found out the duplicate details, you can read it here.

So I checked the fix by Yahoo, and turned out the fix could be bypassed!

To keep the story short, I assume you have read the blog post above. Remember how Yahoo restrict the redirect_uri directory could only be /signin/yahoo?

If you do something like

no access token returned, the directory is difficult to escaped, no more ../

However the payload behind %3f seems quite free to mess with, so I appended a hash behind the URL.

Guess what? The %23 is decoded to be # in the response.

And target .data is appended behind the hash.

This mean, if I can find any open redirect in Flickr, then I can smuggle .data to attacker site.

Open redirect in Flickr is not difficult to find as Yahoo! does not accept Open Redirect as valid report, lucky for me I found one after 5 minutes.

Open Redirect Payload (Fixed now)

The 302 response is

Now we chain them up.

Stage 1 ->

Stage 2 ->

Stage 3 ->[access_token]

Stage 4 ->[access_token]

This report alone worth 2.5k from Yahoo!, I could not be more thankful for the reward from Yahoo. Stay tuned for the rest of my 6k finding in Flickr, it is not fixed entirely at this moment, I will update the finding here once its fixed. Hope you like this story.


5 thoughts on “Flickr ATO Fix Bypass

  1. Hey Ron, Awesome found! I would love to see more posts like this, very detailed and smart. However I got one question left, I thought that %23 or # and what comes after does not show up in any server logs since it is client side. For example, when intercepting a request to, it shows up in burp suite as So I guess (without #secretcode !) shows up in server logs as well. Am I wrong? If I am right, what is the impact. Also, last but not least, what is the point of using the hashtag? Why not just use / or something similar? Thanks in advance, keep up the great work.


    1. / is blocked once we use it in the redirect_uri, # is not.
      Although anything after hash is not parsed/sent to server, after the hash arrives the attacker’s site, attacker site could use javascript to retreive it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s