This issue was first brought to my attention in Web Hacking 101, a book by Peter Yaworski that I would strongly recommend to anyone that wants to get started with web security, and especially if you want to do bug bounties.
What it is
Let imagine that we have a blog post at:
We also have a sharing button and clicking on it opens up a new tab to actually share the blog post on Facebook. The bug I have played around with, and this article is about, would make the sharing button at:
actually share detectify.com instead of the intended blog post.
An example bug bounty report can be found here.
Why it works
In the case of the example linked above, the server-side code worked in a similar fashion:
<?php $url = "https://" . $_SERVER[HTTP_HOST] . $_SERVER[REQUEST_URI]; $url = str_replace($url, "\"", "%22"); echo "<a href=\”https://www.facebook.com/sharer.php?u=\"" . $url . "\">Share</a>"; ?>
The developers made sure to escape the quote, as an attacker could otherwise have escaped the href-parameter and executed their own HTML. However, they did not take care of the ampersand (&). As such, the link on the button becomes:
Due to the ampersand not being encoded this will correctly be treated as two u-parameters by Facebook. How different servers and programming languages handle this varies, but PHP will just use the last parameter.
(This can sometimes be used in other bypasses. The parameters can change on the way to the server, CloudFlare, for example, can sort them alphabetically by value, which means it can be interpreted as one thing in one system and something else in another.)
What we send:
How Facebook interprets it:
You can try it out here, observe the URL of the buttons. The first one will share this blog post, the other one our front page.
This is far from being the most serious vulnerability, but it is still something with potential impact. It could aid in phishing and if your blog post all of a sudden encouraged sharing controversial websites, that would be pretty bad.
We are not limited to the u-parameter, but can add whatever we want. If we continue using Facebook as an example, we have the redirect_uri parameter that means that we can control what pages the victim is redirected to after sharing the blog post. That would make the vulnerability and its impact similar to an Open Redirect.
As the impact varies depending on which social media platform is used on the website, a correct estimate of the potential impact would require reading through the documentation for the API that is being used.
If you find something affecting many different websites, such as a vulnerability in a popular plugin, consider reporting it to Detectify Crowdsource and earn some cash for it! All you need to do is briefly describe the vulnerability in your join request.