[Media] XSS Attacks Across SNS: A Historical Analysis

An illustrative representation of social media platforms as towering structures being injected by syringes. Logos of Twitter, Facebook, and other platforms are prominently displayed on the structures, with two silhouetted figures at the base.

By Ryan Miller

To understand what an 'XSS attack' is, refer to the post below:

https://mailinspector2.blogspot.com/2023/10/xss-attacks-across-social-media.html

Summary

This blog post delves into the intricate world of Cross-Site Scripting (XSS) attacks that have plagued popular social media platforms over the past several years. Through detailed case studies on MySpace (2005), Facebook (2011), and TweetDeck (2014), it explains the causes, objectives, and solutions employed to counteract these cybersecurity threats. By tracing the evolution of these attacks, it underscores the importance of vulnerabilities in even the most renowned digital platforms and the need for robust cybersecurity measures. This narrative serves as a cautionary tale for web application developers and users alike, emphasizing the need to remain vigilance in the digital age.

1. The MySpace (2005)

Overview

In 2005, a unique worm known as "Samy" or "JS.Spacehero" made its presence felt on the MySpace platform. Created by Samy Kamkar, this worm rapidly spread across the entire social media site using cross-site scripting (XSS). Astonishingly, this worm reached over a million users within a mere 20 hours after its appearance on October 4th, earning the title of the quickest spreading virus in history.

Causes and Mechanisms

● Circumventing Tag Restrictions

While MySpace took measures to block numerous HTML tags to safeguard against script injections, certain browsers had a loophole. They permitted the use of JavaScript within CSS tags. This oversight was exploited, paving the way for JavaScript to run on user profile pages.

● Enabling JavaScript Execution

Innovative methods were devised to facilitate the execution of JavaScript, despite MySpace's stringent restrictions on specific characters and sequences. A notable trick involved splitting the term "javascript" across a newline, effectively evading the platform's text filters.

● Altering User Profiles

For the worm to spread, it had to embed its code into the profile of any user who viewed compromised profiles. By using the eval() function, the worm could create strings resembling "inner HTML." This allowed it to access and modify the page's source code, despite MySpace’s attempts to eliminate such strings.

● Web Interactions

The worm employed AJAX (XML-HTTP) to initiate HTTP GET and POST requests to various pages. This capability enabled the worm to engage with other MySpace pages, obtaining and transmitting essential data for its propagation.

● Proliferation Mechanism

Once activated, the worm would add "Samy Kamkar" to the user's "hero" list on their profile. Concurrently, it would duplicate its code onto the observer's profile. This ensured that the worm's influence expanded every time a compromised profile was accessed.

Attackers and Objectives

The MySpace XSS attack, also known as the Samy worm or JS.Spacehero, was orchestrated by an individual named Samy Kamkar. The primary objective behind this attack wasn't malicious; instead, it was more of a prank. The worm carried a payload that would alter the victim's MySpace profile page to display the string "but most of all, Samy is my hero" and send a friend request to Samy Kamkar. Subsequently, the term "MySpace worm" became synonymous with this notable event in internet history, highlighting the potential vulnerabilities in web applications, particularly on social networking sites.

Addressing and Resolving the Issue

Once the worm was identified, MySpace swiftly responded by temporarily disabling the platform to prevent further propagation of the worm. Although exact measures taken by MySpace to tackle the situation are not abundantly clear, it's acknowledged that the platform bolstered its security to patch the vulnerability which had enabled the worm to spread. Concurrently, it was observed that "embed" elements were removed from user profiles, ceasing the autoplay of music and movies, suggesting this as a step toward thwarting similar threats in the future.

Following the Samy worm incident, the digital security industry delveed deeper and strategized for coping with the threats of XSS attacks. Notably, the Open Web Application Security Project (OWASP) launched the Anti-Samy initiative aimed at ensuring that user-generated HTML/CSS adheres to the application’s predefined guidelines, aiming to prevent similar attacks proactively. Though not directly tied to MySpace's resolution of the Samy worm debacle, this initiative is not directly related to how MySpace addressed the Samy worm incident, it serves as an example of the extensive efforts within the technology community to address vulnerabilities exposed by such incidents.

2. Facebook (2011)

Overview

Back in 2011, Facebook found itself in the crosshairs of an XSS (Cross-Site Scripting) attack, a scenario brought to light by cybersecurity experts prior to the launch of Facebook's bug bounty initiative. The crux of the issue lay within the Facebook Mail feature, but was promptly addressed by the tech giant in July 2011. This incident underscored the susceptibility of platforms to XSS attacks, where malicious scripts could potentially pave the way for further malware incursions.

Causes

The roots of this cyberattack can be traced to the innate risks tied to Cross-Site Scripting (XSS), a malicious technique enabling attackers to embed harmful scripts within web applications, unbeknownst to other users. Facebook’s predicament arose from inadequate input validation coupled with ineffective output encoding. Such lapses provided a window of opportunity for malicious actors to interject harmful scripts, especially within the confines of the Facebook Mail functionality.

Attackers and Objectives

The details about the attackers and objectives of the 2011 XSS (Cross-Site Scripting) attack on Facebook are not widely documented or readily available based on the sources accessed. However, it’s improtant to note that the primary goal of XSS attacks typically revovles around introducing malicious code into vulnerable web applications, with the attackers targeting the users of a web application rather than the application itself.

Solution

In 2011, Facebook experienced an XSS attack due to a flaw in the search function of their Translations tool. This tool enabled users to search for phrases within translations. When a search yielded no results, a message was displayed, incorporating unsanitized user input from the search query. This flaw opened the door for a straightforward reflected XSS attack.

To counter such threats, it's vital to cleanse user inputs before displaying them on a webpage. This involves converting specific characters integral to HTML syntax (e.g., <, >, &) into their corresponding HTML entities. This action prevents browsers from misinterpreting them as part of the HTML content, effectively thwarting XSS attacks. Implementing security measures like the Content Security Policy (CSP) can provide additional protection against XSS attacks by defining where and what type of resources can be loaded and executed. Regular updates and consistent testing of all website components are also essential, especially since less frequently accessed sections might be more vulnerable to threats.

In conclusion, Facebook’s siwft response and remediation of this vulnerability upon discovery are commendable¹. This incident emphasizes the significance of transparent communication and collaboration between security experts and businesses.

3. TweetDeck (2014)

Overview

TweetDeck, a social media dashboard application for managing Twitter accounts, experienced a significant security breach due to an XSS (Cross-Site Scripting) worm in 2014. This worm radiply propagated, impacting thousands of users through self-retweets from infected accounts. Due to severity of the issue, Twitter had to temporarily suspend TweetDeck to address the security vulnerability.

Causes

The XSS (Cross-Site Scripting) attack on TweetDeck occurred due to a vulnerability that allowed an attacker to remotely hijack a user's account and tweet a malicious script. This vulnerability represents a common security hole in web applications that could allow attackers to bypass access controls, like passwords or security questions, by making the application run an external script.

Attackers and objectives

The primary purpose of this script was to self-propagate by sending out further tweets and to push message pop-ups on the screens of affected users. It was reported that the attack redirected users to a porn site based in Japan, but the flaw could have also been exploited to lead users to phishing or malware-infected sites. A 19-year-old tech enthusiast from Austrian named Florian was attributed with initiating this hack.However Florian claimed to have encountered the TweetDeck security vulnerability by accident while experimenting with a heart symbol loaded with a string of code.

Solution

Twitter responded by temporarily shutting down TweetDeck to fix the XSS security vulnerability, which was mainly affecting users who ran TweetDeck in web browsers like Google Chrome. After successfully resolving the issue, the service was restored, and TweetDeck became accessible again for all users, both on desktop and web clients.

4. Email Security and XSS Attacks

Consequences of Email-based XSS Attacks

●Session Hijacking

When an attacker obtains a user's session cookie through an XSS attack, they can impersonate the user, gaining unauthorized access to their email account.

●Data Theft

Emails frequently contain sensitive information. Attackers can use XSS vulnerabilities to read emails or even download attachments without the user's knowledge.

●Spreading Malware

XSS attacks in emails can be exploited to download and install malware on a user's device, leading to further exploitation.

Protecting Against Email-based XSS Attacks

●Sanitize Input

Email clients should sanitize all incoming emails, stripping out or neutralizing any potentially malicious scripts.

●Content Security Policy (CSP)

Implementing a strict CSP can prevent the execution of unauthorized scripts, even if they mange to infiltrate an email.

●User Education

Users should be educated about the risks of opening emails from unknown senders and clicking on suspicious links.

● Regular Updates

Just like web applications, email clients (especially web-based clients) should be updated regularly to patch any known vulnerabilities.

References