The Web Hacking Incidents Database Blog

XSS have dominated the Web Hacking Incidents Database statistics page since its inception. The immediate conclusion it that XSS is the most dangerous of them all. This is supported by the fact that XSS is the vulnerability most commonly found by pen testers according to the Web Application Security Consortium’s Statistics Project and that new and advanced JavaScript payloads such as Anton Rager’s XSS proxy or SPI’s JS scanner are created daily to exploit XSS.

On the other hand, while it is easier to find XSS vulnerabilities (after all the vulnerability is reflected to the client), it is still harder to abuse XSS vulnerabilities.

An new feature of the Web Hacking Incidents Database statistics page published today shed some light on this question. In addition to the total count, two new numbers are presented for each classification: the number of actual security breaches reported and the number of vulnerability disclosed but not known to be abused. Actual security breaches are more significant as they indicate both that a vulnerability is exploitable and in many cases what the damage can be.

The numbers are interesting: while on the total count, XSS leads by a wide margin (53 incidents vs. 24 for SQL injection), when we look only at the number of security breaches the field levels, with XSS and SQL injection tying for first place (15 incidents each). But the really striking number is the number of breaches for which the vulnerability is unknown: 37, more than XSS and SQL injection together!

What can we learn from this? that XSS is certainly a killer vulnerability, even if not THE killer vulnerability. But probably the main lesson is that we know little. With so little information about the real world attacks, threat modeling requires collecting information from many sources, each providing a partial and somewhat biased view. In addition to WHID information can be drawn from sources such as the WASC’s Statistics Project, Jeremiah Grossman’s Web App Sec survey or WASC’s Open Proxy Honeypot Project and others. Saying that, with so much more hidden than on the surface, we always need to rely on own (hopefully) good sense.

The entry in the Web Hacking Incidents Database FAQ describing which incidents are included in the database and which are not seems simple, but hides a lot of complexities.While it might seem obvious what a web hack is, nothing is further from the truth. Is a hack only a real break-in or any vulnerability discovered in a live web site? We recently changed the criteria for inclusion in WHID. The reason was simple: to make the database more useful. We made two changes:

• Gone are most vulnerability disclosures. They can only marginally be called hacks anyway, and on top of that, the blur the difference between this database and your normal everyday vulnerability registries such as Bugtraq and CVE. A small number of vulnerability disclosers still make their way to WHID, if the relevant web site is of such an importance that justifies that, or alternatively, if the case can teach us something
• The requirement for a court proof for the hacking being web based was removed. The requirement made the database very objective, but severly limited our ability to include incidents in the database. We now include stories that we believe are a result of a web hack, even without hard evidence. We are ready to remove stories if we find out differently, which recently happened in the TJX incident.

The new criteria balance the need for objective selection of incidents with the need to bring good stories that people will find useful. Not having CardSystems in WHID for a long time was just not justifiable. Bottom line: now we have all the good stories and just good stories.