Search Engine Abuse in Popular Social Networks
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 #
The malicious website loads normally, as shown in the following examples:
Loading the PoC in the browser
Google #
The PoC demonstrates poisoning Google Search history by injecting malicious search terms through cross-site requests.
Facebook #
The PoC shows how Facebook’s search history can be manipulated by unauthorized parties through the same vulnerability.
Youtube #
Youtube’s search functionality is also vulnerable to this attack, allowing attackers to insert arbitrary search terms into users’ search history.
LinkedIn #
LinkedIn’s search engine suffers from the same vulnerability, enabling unauthorized manipulation of users’ 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.