CSRF Vulnerability: A 'Sleeping Giant'CSRF Vulnerability: A 'Sleeping Giant'
A mostly unknown Web vulnerability called Cross-Site Request Forgery could be the next attack vector on your Website
October 17, 2006
If you think Cross-Site Scripting (XSS) is scary and prolific, just wait for the next big Website threat: Cross-Site Request Forgery (CSRF).
The CSRF vulnerability lies in most every Website, but it has remained mostly under the radar for nearly a decade -- it's not even included in the Web Security Threat Classification, OWASP Top 10 or Mitre Corp.'s Common Vulnerability and Exposures (CVE) list. (See Hackers Reveal Vulnerable Websites, Cross-Site Scripting: Attackers' New Favorite Flaw, and Two Vendors Deny XSS Flaws ).
But security researchers say it's only a matter of time before someone awakens the "sleeping giant" and does some major damage with it -- like wiping out a user's bank account or booking a flight on behalf of a user without his knowledge.
"There are simply too many [CSRF-vulnerable Websites] to count," says rsnake, founder of ha.ckers.org. "The sites that are more likely to be attacked are community websites or sites that have high dollar value accounts associated with them -- banks, bill pay services, etc."
Other experts agree. "It's not seen as a vulnerability because it works like the Web works. That's the problem," says Jeremiah Grossman, a researcher and CTO of WhiteHat Security , who calls CSRF "the sleeping giant" vulnerability.
"The security community will be forced to deal with this...it's serious," Grossman says.
CSRF isn't new -- it's been part and parcel of Websites for at least a decade. Perhaps the most famous CSRF attack was the Samy worm on MySpace, which blended a deadly cocktail of XSS and CSRF that eventually took down the site. But researchers worry that it will be the next approach vector for hackers looking for new ways to attack Web applications.
And there are signs that CSRF may already have been reawakened from its slumber. One researcher recently released proof-of-concept code for CSRF attacks against Netflix's Website that can add movies to a user's rental queue, change the name and address on their account, or cancel their account.
CSRF works like this: An attacker identifies a URL on a Website -- such as Netflix or a bank -- that initiates typical Web functions such as making a purchase, changing an email address or transferring funds. "The attacker takes that URL and loads it to a Web page they control," White Hat's Grossman says.
The actual attack occurs when the user visits the attacker-controlled Web page via a legit link, which forces the browser -- using legitimate, authenticated cookies -- to make malicious requests. The user has no clue as to what's happening.
And the catch is that neither the original Website nor the user's computer is necessarily compromised, Grossman says.
One way to stay safe is to keep clearing cookies or ensure you're properly logged off to all sites before you visit another, Grossman says. "The more sites you visit, the more your risk increases" with CSRF, he says.
CSRF is tougher to repair than XSS and SQL injection vulnerabilities. Cleaning it up would require recoding Web apps, including each form and feature on a site, security experts say. And when combined with XSS, it's especially deadly, so you should fix your XSS vulnerabilities first.
Once you've eliminated the XSS flaws, you can use either one-time tokens generated by your Web server or the CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) challenge-response tool to combat CSRF.
Tokens, also known as nonces, are susceptible to XSS, so that's one reason to eliminate XSS first, says rsnake.
Grossman says he expects attackers to perform these attacks using both XSS and CSRF vulnerabilities.
So will the sla.ckers.org group of hackers, which has exposed XSS vulnerabilities on many major Websites, take on CSRF next?
"It's possible," sla.ckers.org founder rsnake says. "However, as it requires account access with the companies in question, it is substantially more involved to test for in large scale [than] XSS, which rarely requires a username/password. Unfortunately, this is an attack that is reserved for the more determined attacker, rather than the casual researcher."
— Kelly Jackson Higgins, Senior Editor, Dark Reading
About the Author(s)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
Passwords Are Passe: Next Gen Authentication Addresses Today's Threats
How to Deploy Zero Trust for Remote Workforce Security
What Ransomware Groups Look for in Enterprise Victims
How to Use Threat Intelligence to Mitigate Third-Party Risk
Securing the Remote Worker: How to Mitigate Off-Site Cyberattacks