search

enthec / webappanalyzer

This project aims to maintain Wappalyzer technologies
GNU General Public License v3.0
238 stars 53 forks source link

Include information on vulnerable tech #20

Open double16 opened 1 year ago

double16 commented 1 year ago

Describe the solution you'd like Included with each tech found, indicate if it's vulnerable and a link to the vulnerability such as a CVE. Expose this data in such a way that another tool, such as ZAP, can leverage it.

Describe alternatives you've considered Searching using other tools.

psiinon commented 1 year ago

Or just if the relevant version is no longer supported?

kingthorin commented 1 year ago

You said CWE but I think you meant CVE?

double16 commented 1 year ago

You said CWE but I think you meant CVE?

lol, yeah. Not enough coffee yet. ☕

enthec-opensource commented 1 year ago

I've thought about this, it would require to constantly check all registered technologies, validate latest versions and search in the NIST API for new vulnerabilities to append to the json, because I guess the idea is to only have vulnerabilities related to the latest tech version, whenever a version gets released, CVEs will need to reset. Not easy to automate since you need to scrape every tech website.

We could report all CVEs found for a single technology name(ignoring the version)?, for example jquery by using the NIST API https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=jquery, this way we would be reporting every single CVE the tech has ever had, which i don't think is a good idea since we would be reporting CVEs your tech version might not have and make the json files be even bigger.

I think this would make way more sense in the python, go, js, etc implementation when they report findings, since you can use the version aswell. Lets say you find jquery version 1.1 on whatever website you are checking with your js implementation, you could parse the tech + version, get https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=jquery+1.1 and give the user way more specific information about the target.

Other thing i can think of is store the vendor information, so webappanalyzer implementations can query the NIST API based on cpe?, or even use versionStart & versionEnd query parameters.

I've worked with the NIST api before, the version 2 seems better than version 1, it is less chaotic. This is how it would look like with the v1.0 https://services.nvd.nist.gov/rest/json/cves/1.0?keyword=jquery+1.1, not sure if it's deprecated.

NIST api documentation: https://nvd.nist.gov/developers/vulnerabilities

Best practices to avoid request limits: https://nvd.nist.gov/general/news/API-Key-Announcement

antoniojtorres commented 5 months ago

I agree that it would make more sense as an integration alongside (and not in) this package. It is otherwise too different in the nature of how the data is collected and the cadence at which it needs to be collected.

enthec-opensource commented 5 months ago

Been thinking about this and the best solution I can think of is adding as many cpes as possible.

Reading about the cpe 2.3 specification: https://cpe.mitre.org/specification/ all that matters is vendor and product name (so we could just save those tbh) and then with whatever version webappanalyzer has detected create the string cpe:2.3:a:{vendor}:{product}:{version}:*:*:*:*:*:*:* (or even just without the version cpe:2.3:a:{vendor}:{product}:*:*:*:*:*:*:*:*) to find all the cves linked.

For example, lets say we have detected drupal version 5.10, the final string would be cpe:2.3:a:drupal:drupal:5.10:*:*:*:*:*:*:* which we can search on the nist api and find all linked CVEs: https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:drupal:drupal:5.10:*:*:*:*:*:*:* and leave that task to whatever implementation is working with this repo, because there is just no way to keep all the updated cves and cwes in real time.