The Twitter 2010 CSRF Worm Issue

The Twitter 2010 CSRF Worm Issue

The Twitter CSRF worm (aka "onMouseOver" worm) was a self-replicating, cross-site scripting (XSS) attack that exploited CSRF (Cross-Site Request Forgery) vulnerabilities in Twitter's web interface in September 2010.

How Did the Worm Work?

• The attack exploited a reflected XSS vulnerability in Twitter's web client.
• The attacker used a JavaScript onMouseOver event in tweets to execute malicious scripts.
• The worm auto-posted itself to users' Twitter feeds without their consent.

Step-by-Step Breakdown of the Attack

1. XSS Exploited via Tweets

   • The attacker injected JavaScript inside a tweet using a malicious payload.
   • The payload leveraged an onMouseOver event to trigger the attack.

2. CSRF Effect: Tweets Posted Without User Action

   • When another user hovered over the infected tweet, the JavaScript executed automatically.
   • The script posted another infected tweet from the victim's account without their consent.
   • This allowed the worm to spread exponentially.

3. Worm Variants and Effects

   • Some versions of the worm redirected users to malicious websites.
   • Others simply posted harmless color changes (e.g., turning tweets black).
   • Since tweets auto-executed code when hovered over, no user interaction was needed beyond hovering.

Why Was Twitter Vulnerable?

4. Twitter Did Not Escape User Input Properly

   • The tweet content was not sanitized to prevent JavaScript execution.
   • The web client rendered tweets as HTML, allowing JavaScript injection.

5. Lack of CSRF Protection

   • Twitter did not implement CSRF tokens to verify if requests were legitimate.
   • This allowed the script to send malicious POST requests on behalf of users.

6. Failure to Implement HttpOnly & SameSite Cookies

   • If Twitter had properly implemented SameSite=Strict or Lax, CSRF risks could have been minimized.

Impact of the Worm

• Millions of users were affected within hours.
• High-profile users (e.g., Sarah Brown, wife of former UK Prime Minister Gordon Brown) were infected.
• Twitter had to patch the vulnerability quickly, but the worm mutated multiple times before being fully contained.

How Was It Fixed?

✔ Escaping User Input:

• Twitter applied proper HTML entity encoding to tweets, preventing JavaScript execution.

✔ Content Security Policy (CSP):

• CSP rules were enforced to block inline JavaScript execution.

✔ CSRF Protection Added:

• CSRF tokens were introduced to prevent unauthorized actions.

✔ SameSite Cookies Implemented:

• Twitter improved session security using SameSite=Lax cookies to prevent CSRF attacks.

Lessons from the Twitter CSRF Worm

🔹 Always sanitize and escape user input before rendering on the frontend.
🔹 Never allow inline JavaScript execution inside user-generated content.
🔹 Use CSRF tokens to verify legitimate requests.
🔹 Enforce SameSite and HttpOnly cookie attributes to limit attack vectors.
🔹 Regular security audits can catch such vulnerabilities before attackers exploit them.

The Twitter 2010 CSRF worm was a prime example of how small security flaws (XSS + CSRF) can cause massive viral exploits within hours. 🚀