One funny point about the new OWASP Top 10 Application Security Risks is that 30% of them aren’t even common. The “Weakness Prevalence” for Insecure Cryptographic Storage (A7), Failure to Restrict URL Access (A8), and Unvalidated Redirects and Forwards (A10) is rated uncommon. Other than the apparent disconnect of putting effort into rare risks, these three points highlight the challenge of producing an unbiased list. (Yes, risk is complex and difficult to quantify. Ignore the document’s What’s My Risk? section at your peril.) The list is influenced by the experience of people who perform penetration tests, code reviews, or conduct research on web security. It’s not put together by the actual attackers who compromise web sites for fun and profit; they’re busy stealing your stuff.
Insecure Cryptographic Storage is rated with an uncommon prevalence and difficult to detect. One of the reasons it’s hard to detect is that back-end storage schemes can’t be reviewed by blackbox scanners (i.e. web scanners) nor can source code scanners point out these problems other than by indicating misuse of a language’s crypto functions. So, one interpretation is that insecure crypto is uncommon only because more people haven’t discovered or revealed such problems. Yet not salting a password hash is one of the most egregious mistakes a web app developer can make and one of the easier problems to fix. (The practice of salting password hashes has been around since epoch time was single digits.)
It’s also interesting that insecure crypto is the only one on the list that’s rated difficult to detect. XSS (A2) is “very widespread” and “easy” to detect, but maybe it’s only very widespread because it is so trivial to find. People might simply be lazy. Or maybe it is very widespread because it’s actually not easy to find — at least assuming web developers are looking for it in the first place. If more developers, or more tools, found XSS proactively then it wouldn’t be so widespread. (Although I still insist that XSS vulns are the cockroaches of the web.)
Want one item that probably carries the most risk as evidenced by real-world attacks? Password guessing. The Apache Foundation recently suffered an attack that relied on brute forcing a password. (Apache’s network had a similar password-driven intrusion in 2001. They’re mentioned because of the clarity of the event write-ups, not that they’re inherently insecure.) In 2009 Twitter provided happiness to another password guesser. There are plenty more examples. Knowing the password to an account is the best way to pilfer a user’s data and gain unauthorized access to a site. The only markers for an attacker using valid credentials are behavioral patterns – time of day the account was accessed, duration of activity, geographic source of the connection, etc. The attacker doesn’t have to use any malicious characters or techniques that could trigger XSS or SQL injection countermeasures. Broken Authentication and Session Management (A3) cover many more items than brute force attacks.
Incidentally, the impact of a compromised password is similar to the affect CSRF (A5) can have on a site. CRSF changes the nature of the attack so that the victim’s browser, which still has a valid session cookie regardless of whether the site is currently open in a window, makes an authenticated request on the attacker’s behalf. The target web site neither sees the attacker’s traffic nor even gets a whiff of the attacker’s activity because all of the interaction occurs between the victim’s browser and the target site.
CSRF serves as a good example of the changing nature of the web security industry. CSRF vulnerabilities have existed as long as the web. The attack takes advantage of the fundamental nature of HTML and HTTP whereby browsers automatically make requests to servers defined in img, iframe, or a handful of other tags. The servers in different tags need not be related and, since the attack doesn’t need to parse the response from the server, the browser’s Same Origin Rule doesn’t protect the user. CSRF hopped on the Top 10 list’s revision in 2007, three years after the list’s first appearance. It’s doubtful that CSRF vulnerabilities were any more or less prevalent over that three year period (or even the before 2000). Its inclusion was a nod to having a better understanding and appreciation of the vulnerability.
On the other hand, it’s not clear how useful a CSRF exploit was (or is) to attackers. If the attack is predicated on leading a victim to a site with a booby-trapped iframe or img, then why not just pepper the browser with malware rather than count on the confluence of a logged in victim hitting the page? Set aside the infamous web-app-worm-that-will-not-be-named and Jermiah Grossman’s cool Gmail hack. How many high impact web attacks have used CSRF?
Actually, that’s a bit of an unfair question. CSRF is really useful against sites that millions of people visit (Amazon, Ebay, Facebook, MySpace, Twitter, Yahoo!, this web site) because the number of users and the length of time they spend logged in their accounts raises the chance of finding a victim enormously. For other sites, CSRF might just not be useful enough to a hacker that finds something else like SQL injection. There’s a big difference between finding a victim from a pool of a few hundred million and a few hundred thousand.
The question also points out the confirmation bias of security researchers. Now that CSRF is in vogue people start to look for it everywhere. Security conferences get more presentations about advanced ways to exploit the vulnerability, even though real-world attackers seem fine with the returns on guessing passwords and seeding web pages with malware. Take a look at HTML injection (what everyone else calls XSS). Injecting script tags into a web page via an unchecked parameter dates back to the beginning of the web. Yet the early exploits didn’t do nearly as many cool things like tunneling HTTP traffic through XSS.
Before you shrug off this discussion of CSRF as hand waving with comments like, “But I could hack site Foo by doing Bar and then make lots of money,” consider what you’re arguing: A knowledgeable or dedicated attacker will find a useful exploit. Risk can be based on many things, including Threat Agents (to use the Top 10 list’s term). Risk increases under a targeted attack – someone actively looking to compromise a specific site or the users’ information the site contains. If you want to add an “Exploitability” metric to your risk calculation, keep in mind that ease of exploitability is often related to the threat agent and tends to be a step function: it might be hard to figure out the exploit in the first place, but anyone can run a 42-line Perl script that automates the attack.
This is why the Top 10 list should be a starting point to defining security practices for your web site, but it shouldn’t be the end of the road. Even the OWASP site admonishes readers to use the list for awareness rather than policy. So, if you’ve been worried about information leakage and improper error handling since 2007 don’t think the problem has gone away because it’s not on the list in 2010. And if you don’t think anyone cares about the logic problems within your site…well, just hope they haven’t been reading about it somewhere else.
(UFO label = Update For OWASP)