The New York Times 2008 CSRF

The New York Times 2008 CSRF Attack

In 2008, The New York Times website was found to be vulnerable to a CSRF (Cross-Site Request Forgery) attack, allowing attackers to unsubscribe users from the email newsletter without their consent.

{FF1492D6-0E0D-40F0-B245-01B325BE3527}.png

Below one is another attack. Both attacks were CSRF-based vulnerabilities, but the Email This attack leaked user data, whereas the Unsubscribe attack only altered preferences. The "Email This" attack had a higher security impact because it exposed personal information. 🚨

What Was the Vulnerability?


How Did the Attack Work?

  1. User Was Logged into The New York Times

    • The victim had an active session with The New York Times and was subscribed to newsletters.
  2. User Visited a Malicious Website

    • The attacker hosted a malicious webpage containing an image tag (<img>) or an invisible iframe (<iframe>).
    • The webpage automatically sent a forged request to The New York Times.
  3. Malicious Unsubscribe Request Sent

    • The malicious site silently executed:

      <img src="https://www.nytimes.com/unsubscribe?email=victim@example.com">
      
    • Since the victim’s browser automatically included their authentication cookies, The New York Times processed the request as if the user had manually unsubscribed.

  4. The User Was Unsubscribed Without Consent

    • The victim had no idea that they were removed from the newsletter.

Why Was The New York Times Vulnerable?

  1. No CSRF Tokens Used

    • The unsubscribe request did not require a CSRF token, making it easy to forge.
  2. GET Requests Modified State

    • Actions that change user data should never use GET requests.
    • The website should have used POST requests with CSRF protection.
  3. Cookies Were Automatically Sent

    • Since the request was same-origin, browsers automatically included session cookies, making the forged request valid.

Impact of the Attack


How The New York Times Fixed It

βœ” Implemented CSRF Tokens:

βœ” Switched from GET to POST Requests:

βœ” Added Confirmation Steps:

βœ” Implemented SameSite=Lax Cookies:


Lessons from The New York Times CSRF Attack

πŸ”Ή Always require CSRF tokens for state-changing requests.
πŸ”Ή Use POST, not GET, for sensitive actions (e.g., modifying user settings).
πŸ”Ή Confirm user actions before executing irreversible changes.
πŸ”Ή Monitor unusual traffic patterns to detect CSRF attempts early.

The 2008 New York Times CSRF attack showed how even simple features like an unsubscribe button can become a security risk if not properly secured. πŸš€