wpscanteam / wpscan

WPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contact@wpscan.com
https://wpscan.com/wordpress-cli-scanner
Other
8.49k stars 1.25k forks source link

Use CWE instead of own classification #437

Closed ethicalhack3r closed 9 years ago

ethicalhack3r commented 10 years ago

We currently classify each vuln as one of:

"AUTHBYPASS"
"BYPASS"
"CSRF"
"FPD"
"LFI"
"MULTI"
"RCE"
"REDIRECT"
"RFI"
"SQLI"
"SSRF"
"UNKNOWN"
"UPLOAD"
"XSS"
"XXE"

As @fgeek suggested on a commit comment, we could use CWE identifiers instead.

I think CWE will help us classify more accurately, however, it will also take more time to classify each new vulnerability. There looks to be thousands of different classifications?

Currently, our classifications are not used anywhere yet (as far as I'm aware), they are just "meta-data", which I think will become useful one day if we want to see "how many vulnerabilities were XSS?" kind of stats for example.

firefart commented 10 years ago

Haven't worked with CWE. Are there some basic CWE's too like CWE XXXX - SQL Injection? I think finding the right entry can be a pain in the **\ :) Maybe we can automatically parse the info on the CVE pages? I think they are linking CWE numbers

fgeek commented 10 years ago

Sometimes CWE is in mapped to CVE data. NVD for example does it. Sometimes it can be picked out of advisories. It makes reporting from wpscan much more official and more robust. There is "major" CWEs for well known issues. CWEs can be confusing when you look at those at the first time. We can also just use $editor to replace old "XSS" to correct CWE for example. This information is like CVEs. Sometimes you have CWE and sometimes the advisory/vulnerability is unspecified and you don't know what the real issue is.

pvdl commented 10 years ago

For the record: http://nvd.nist.gov/cwe.cfm

pvdl commented 10 years ago

Maybe an idea to make a link in the output which is a reference to the information page of the classified vulnerability.

ethicalhack3r commented 10 years ago

We can possibly implement CWEs programatically when the vuln db goes live, shouldn't be too hard to map our classifications to CWE's.

New DBs will be in JSON format, so should be easy to add an extra JSON node for CWEs when JSON output for WPScan is implemented.

ethicalhack3r commented 10 years ago
"AUTHBYPASS" => ["AUTH", "CWE-287"]
"BYPASS" => ["???", "???"]
"CSRF" => ["CSRF", "CWE-352"]
"FPD" => ["INFOLEAK","CWE-200"]
"LFI" => ["LFI","CWE-22"]
"MULTI" => ["MULTI", ""]
"RCE" => ["RCE","CWE-94"]
"REDIRECT" => ["REDIRECT", "CWE-601"]
"RFI" => ["RFI","CWE-98"]
"SQLI" => ["SQLI", "CWE-89"]
"SSRF" => ["???","???"]
"UNKNOWN" => ["UNKNOWN","???"]
"UPLOAD" => ["UPLOAD","CWE-434"]
"XSS" => ["XSS", "CWE-79"]
"XXE" => ["???","???"]
ethicalhack3r commented 9 years ago

Moved this to wpvulndb issue tracker

fgeek commented 9 years ago

Great. I can help you implement this if needed.