Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broad/Descriptive Tags On Entries #23

Closed
judges119 opened this issue Apr 2, 2015 · 6 comments
Closed

Broad/Descriptive Tags On Entries #23

judges119 opened this issue Apr 2, 2015 · 6 comments

Comments

@judges119
Copy link

With regards to the tags used by entries in the database, what level of detail should they include? For example the entry on Cross-Site Scripting (XSS) has "xss", "regexp", "injection", "script", which is quite specific. I was wondering if it would be advantageous to add tags related to the domain in which the vulnerability exist. So include "website", "http", "sessions", etc.

Examples of when this might be useful is end-user search engines for the database which are aimed at developers who aren't necessarily infosec pros but want to see what could affect their project. Something where one can type "http", "website", etc and get a list of what they might be up against, allowing them to proactively build with those in mind prior to a security audit.

@andresriancho
Copy link
Contributor

That's an interesting question, the answer, at least for me is: "I don't know".

Right now the only two ""sponsors"" for this project are the Arachni and w3af projects, which are web scanners, thus all the vulnerabilities in this database would have the "website" or "http" tags (at least implicit). In the future this might change and someone (not me, and most likely not @Zapotek but I can't talk for him) might add vulnerabilities which are not web related.

It might be a good idea to prevent this future add-on of other vulnerabilities and tag all current vulnerabilities as "web", just in case.

Leaving open so we do that.

@Zapotek
Copy link

Zapotek commented Apr 4, 2015

@andresriancho Which brings up the question, is vulndb just for web vulns or everything is fair game?

@andresriancho
Copy link
Contributor

  • The schema allows almost any type of vulns to be added.
  • I'm not going to add any non-web vulns
  • I'm not going to "block" any PRs for non-web vulns

Hope that clarifies my point of view

@andresriancho
Copy link
Contributor

Thank god for unittests. As you say it wasn't valid JSON, that made the test fail and after a couple of quick fixes: https://circleci.com/gh/vulndb/data/33

@m0sth8
Copy link
Contributor

m0sth8 commented Apr 4, 2015

@andresriancho It will be better if we merge develop to master with PR in the future. What do you think?

@andresriancho
Copy link
Contributor

Yeah, I should work on develop and then merge. The good thing is that I'm only breaking master for some seconds ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants