As I've spent almost all of my research time this past year focusing on finding and disclosing (coordinated) CSRF vulnerabilities, it was with some amusement that I read CSRF Vulnerabilities Rise, Overall Vulnerability Disclosures Dip from Kelly Jackson Higgins last week.
Therein she states that "overall, the number of vulnerability disclosures for the year is gradually declining to around 4,500 from nearly 7,000 last year, with the exception of CSRF, which had 155 vulnerabilities as of the first half of the year." This article is ultimately referring to TippingPoint DV Lab's Top Risks report.
Wolfgang Kandek, CTO at Qualys, follows with "CSRF is difficult ... and complex."
I must respectfully disagree, it's really not, but I'll discuss that in a minute.
I was pleased to run into Jeremiah Grossman at the ISSA International Conference last week, and he stated that CSRF has moved up on the imminently pending 10th WhiteHat Security Statistics Report. He was careful to pointy out however that its not because sites are more vulnerable to CSRF; rather, WhiteHat Security customers are more interested in having the issue reported combined with better Sentinel detection.
The point about better detection on WhiteHat's part ties back to my disagreement over the claim that CSRF is difficult and complex.
Exploiting CSRF is really not complicated at all, but it has been historically difficult to discover via automated scanning (sorry, Kevin ;-). There are nuances that require fairly significant manual interaction with a potentially vulnerable application; enumeration and parameter reconnaissance is required, followed by building forms specific to various POST requests. Consider Tamper Data your bff for this effort. Most importantly, noting the lack of a token/formkey/canary is generally the first, best step to determining CSRF vulnerability with targeted manipulation thereafter.
Of the 155 CSRF disclosures mentioned in Kelly's article for the first half of 2010, 14 are advisories I submitted through Secunia and are widely varied in their scope.
You'll note the expected vulnerable CMS platforms, but you'll also find HP printers, server logging agents, system management interfaces, and web mail providers.
My point is this, CSRF is not hard to find, is easy to exploit, and often remains unrepaired in web applications long after the other OWASP Top 10 biggies have been fixed.
Token up, people!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Post Comments (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho...
No comments:
Post a Comment