2

What is a good way to categorise the vulnerabilities in IT security reports. Assuming it's about a web-based environments like:

  1. Websites,
  2. Web applications,
  3. Web shops,
  4. Any interface using web-technology and is accessible using a browser.

I'm currently using the OWASP top 10 from 2013 and optionally adding an extra category "other". Any thoughts on good alternatives?

  • 3
    If you're specifically looking for web vulnerability rankings, you may also want to look at CWE/SANS Top 25 – Jedi Jun 18 '16 at 23:07
1

This is highly opinionated and controversial, but I wanted to provide food-for-thought for you to make your own decision.

There's OWASP, CWE, and WASC. I don't like any of them.

Why shouldn't I use any of these categorization methods?

OWASP Top 10 attempts to provide a most common list at a high-level view of what has happened in the last two years. But when you are creating technical reports, attempting to map vulnerabilities to these high-level categories leaves a lot open for interpretation and a lot of room is left for things that don't fit.

Take these examples:

"Mercurial remote code execution in Importer" - Missing Function-level Access Control? According to OWASP, that's not appropriate. https://bounty.github.com/classifications/missing-function-level-access-control.html even says it is for controlling access to sensitive data, not for preventing arbitrary code from running.

But there's more.

"Git LFS code execution" is put under "Other." "GitHub for Windows remote code execution" is under Injection.

What do these three have in common? They are code injection. But under these OWASP mappings, they are three different things. Does that make sense to a manager that has to review your report? Call it what it is - Remote Code Execution. How it came about, how to fix it, those are separate things from what the problem is, the problem is executing arbitrary code or commands.

Why should I use these categorization methods?

Mapping to some parent categorization can make reporting easier when providing how often the organization encounters XSS or other problems.

Final word of caution

The industry has some problems to fix, and I think this is a big one. 10 categories is not enough for mapping. 25 categories is getting better, but your organization may be more targeted for mobile applications with web API endpoints, for which categorizing as "Injection" doesn't work as well as categorizing as LDAP injection, or something else.

The choice is of course yours, but over the years, this is what I've learned.

  • There aren't just 25 CWE entries (those are just the top 25), but 1000+. I'm not sure if the level of detail is really needed though, or if it actually makes categorizing vulnerabilities such as your examples easier. – tim Jun 19 '16 at 10:55
0

There are hundreds of web-apps based vulnerabilities and can be categorized into these:

  • Input Validation (XSS, SQL Injection)
  • Authentication (weak password, user enumeration)
  • Authorization (privilege escalation, insecure direction object reference)
  • Session Management (session fixation, absent logout button)
  • Disclosure of Information (Detailed error message)
  • Operating System/Web Server (Cross frame scripting)
  • Manipulation of Application Logic (Invalidated Redirects, PRSSI)

This in not a rule and can be modified according to your needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.