- Find and prioritize all websites
- Find and fix website vulnerabilities
- Implement a secure software development process
- Utilize a defense-in-depth website security strategy
Today’s webinar went extremely well, slides are available for those interested. And some quick numbers:
Total Websites: 687
Identified vulnerabilities: 11,234
Unresolved vulnerabilities: 3,541 (66% resolved)
Websites HAVING HAD at least one serious issue: 82%
Websites CURRENTLY WITH at least one serious issue: 61%
Average vulnerabilities per website: 5
The shiny new WhiteHat Top Ten
Yes! CSRF finally make the list!
Also covered is:
- Collection methodology
- Time-to-fix and remediation metrics
- Industry vertical comparisons
- Best practices & lessons learned
Feedback on what other numbers people would like us to report on in the future is very welcome.
10 comments:
Why is "HTTP Response Splitting" listed twice.
See
* Figure 6, Figure 8
* Table 2
They are two different severities, one is listed "Urgent" and the other "High".
What solution are you/WhiteHaT providing/recommending to large enterprise high availability apps to combat CSRF?
@matt, the answer to that question is unfortunately not black & white. The recommendation would be largely be dependent upon the type of website, the development framework in use, and the number of CSRF issues.
If you only have a handle full of issues, its possible to create a reasonably secure token system from scratch and implement it as an API. Or, depending on the language, there are likely open source libraries around as well.
If its a site wide problem, frameworks like .Net or Drupal have apis you can call in well that as reasonable unintrusive.
Its really too bad that WAFs can't yet be of much use towards CSRF mitigation, yet.
With more details, I could be more specific in my response. Hope this helps some.
I'm really surprised by your CSRF figures.
Almost every site I've ever tested has had no CSRF protections at all (beyond what the framework gives them, e.g. .NET sites are mostly protected from vertical (but not horizontal) priv-esc CSRF by default due t the need to a ViewState, though some do use GET and are vulnerable to that too).
You say you have two separate categories for response splitting; what makes you decide which to put a vulnerability in?
P.S. Wtf is with your severity system, high/critical/urgent? Seems like a whole lot of FUD to me.
P.P.S Maybe it's just me going through slides without context, but your dates seem fudged considering SQL Injection was known in 98: http://www.phrack.org/issues.html?issue=54&id=8#article and xss was definitely known before 2005
> I'm really surprised by your CSRF figures.
Don't be. From the text in the report:
"As predicted, Cross-Site Request Forgery (CSRF) has managed to crack into the Top Ten by replacing Directory Indexing. All statistics surrounding CSRF can be deceptive though, including all reports issued worldwide, because identifying this issue reliably by purely automated means remains elusive - this despite vendor claims to the contrary. WhiteHat has been making steady gains in automatically detecting CSRF, but most are found though manual custom
testing by WhiteHat’s Security Operations Team (the same for all researchers and pen-testers globally). WhiteHat posits that a better estimate of CSRF’s prevalence is similar to that of Cross-Site Scripting (XSS), appearing in approximately 75% of the world’s websites."
Technically speaking, CSRF is not supposed to be in our methodology anyway because it's not part of the WASC TC. That'll change soon enough though and its an important issue. So we're getting our processes honed just the same.
> You say you have two separate categories for response splitting; what makes you decide which to put a vulnerability in?
When we can't get the HRS split to poison the cache on the server. The particular instance of HRS remains an issue, as other things can still be done like poisoning browser cache, but only lessens of an overall impact.
> P.S. Wtf is with your severity system, high/critical/urgent? Seems like a whole lot of FUD to me.
You really need to read the entire report.
"Using the Payment Card Industry Data Security
Standard17 (PCI-DSS) severity system (Urgent, Critical, High, Medium, Low) as a baseline, WhiteHat Security rates vulnerability severity by the potential business impact if the issue were to be exploited and does not rely solely on default settings."
We don't like the naming convention either, but its what our customers wanted.
> P.P.S Maybe it's just me going through slides without context, but your dates seem fudged considering SQL Injection was known in 98:
Not fudge, I agree discovery dates are much earlier, but in that slide we're making a judgment call as to when the class of attack was widely understood/appreciated. Just because an attack has been published, doesn't mean anyone read the material.
i think the 5th website security statistics is great. i will try to download it
It seems that the slides are broken on slide share.
Weird, something must have glitched. No idea what happened, but thanks for the tip. Link fixed.
http://www.slideshare.net/jeremiahgrossman/website-security-statistics-august-2008-presentation/
okay. i'll download this one. thanks!
Post a Comment