Search Engine Abuse in Popular Social Networks

Mazin Ahmed
3 min readMay 17, 2019

--

- This is a blog post by Mazin Ahmed and Khaled Farah.

Introduction

Popular social networks are affected by a “by-design” security vulnerability that allows unauthorized parties to control their search history. Unauthorized parties are capable of inserting their own chosen keywords in the search history of Google, Facebook, LinkedIn, and Youtube.

Technical Details

The bug is relatively simple in term of explanation and exploitation. It has been reported by us, and possibly by others to the social networks, and it was marked as an “acceptable risk” by the affected companies. We agree it’s a low risk issue, but due to the trivial exploitation of this attack, it may be a good idea to implement a fix. We’re releasing a blog article to open a public discussion regarding the vulnerability.

The Vulnerability

Search engines by Google, Facebook, LinkedIn, and Youtube stores keyword history by default in order to enhance the user experience of their apps. The implementation of the search engines does not verify the search origin of the user. Since there is no CSRF (Cross-Site Forgery) checks, it’s possible for attackers and spammers to control the search engine history of the affected apps by having users visiting a crafted page.

Proof of Concept

Click here for a live demo

The malicious website loads normally, as the following:

Loading the PoC in the browser

Google

The PoC is poisoning Google Search history

Facebook

The PoC is poisoning Facebook Search history

Youtube

The PoC is poisoning Youtube Search history

LinkedIn

The PoC is poisoning LinkedIn Search history

Conclusion

It’s an interesting case where security vs. usability are faced. It’s a clear security issue with a direct impact to users, but it would affect the usability of the apps to implement CSRF checks correctly in the affected endpoint. However, a custom fix by validating the “Referer” header on the Search API endpoint should mitigate the issue. It should be also possible to mitigate the attack by same-site cookie flag.

--

--

Mazin Ahmed