Monthly Archives: May 2013

VulnDB API update + new VulnDB Help site

Leave a reply

We have improved VulnDB API and have a new (and better) Help site. Read on to find out more about these changes.

VulnDB HQ is a tool to manage your vulnerability descriptions so you can reuse them across reports. It also lets you create and share testing methodologies so every project is delivered to the same high quality standard.

The VulnDB logo

We have recently migrated the VulnDB Help site to a new location at:

http://vulndbhq.com/help/

Apart from the new look & feel (which we hope you like) we’ve made a few significant improvements in the API itself:

Strict SSL requirement

The API was accessible over plain-text HTTP due to a misconfiguration, we have completely disabled this.

Token-based authentication

Say your goodbyes to HTTP Basic authentication and welcome the new token-based authentication overlords.

Visit your Profile page to get your own API token which can be used to authenticate API request by means of a custom HTTP header.

A screenshot of the section of the Profile page showing the token

Lost your token or you suspect it was compromised? Want to deny access to your account to all 3rd party applications? Regenerate your token and you are good to go.

Better examples

We’ve improved the examples for each of the API methods with a proof-of-concept `curl` request along with the sample of any data that has to be submitted to the request. We also show response codes and content returned by the server so you know what to expect.

tl; dr;

Find answers to your VulnDB API questions at http://vulndbhq.com/help/

Note that we have not bumped the version number to introduce these changes. This is because the main interfaces, media formats, end points and data types have not changed.

Upcoming in Dradis Pro v1.7: Issues and Evidence

1 Reply

A new release of Dradis Pro is in the making: Dradis Pro v1.7. We continue to evolve our solution based of the feedback we receive from our users.

Starting in Dradis Pro v1.7 we have introduced two new concepts:

  • Issues: these are findings or vulnerabilities. An example would be: “Cross-site scripting“.
  • Evidence: this is where you provide the concrete information / proof-of-concept data for a given instance of the Issue.

For example:

  • The ‘Hackme bank’ application is vulnerable to Cross-site scripting (Issue). There are 7 instances of this issue and here is the information about them (Evidence).
  • The HTTP service in tcp/443 of the 10.0.0.1 host is affected by the Out-of-date Apache Tomcat issue and so is the tcp/8080 service in 10.0.0.2

As you can see, the main benefit of this approach is that you get to describe the Issue once and reuse that description.

To continue with our example, we’d have to create the following project structure:

Here we would add the Out-of-date Apache Tomcat Issue to the all issues node of the project, and then the Evidence for each host will be added in the corresponding node.

By segregating core vulnerability information from the evidence associated with each instance of the issue, we can start doing some powerful things.

Reporting by host, reporting by issue

On the one hand, some penetration testing firms like to structure their reports by finding. They go through the list of issues identified, providing description, mitigation advice, references, etc. and including all the hosts affected by the issue in each instance.

byhost-20

On the other hand, some prefer to structure their report by host. They list all the hosts in-scope for the engagement and describe each issue that affects them.

Of course there are others that provide these two options in the same report. A section where all the issues are described in detail followed by a host summary where you can quickly see a list of issues affecting a given host.

In order to provide this level of flexibility there needs to be a segregation between the issue details and the instance information.

With the introduction of Issues/Evidence in v1.7, we have just opened the door to all this flexibility.

More information

If you are an existing Dradis Pro user, you can already take advantage of all this features without having to wait until the release of v1.7. We have also prepared a step-by-step reporting guide for you:

Reporting by host, reporting by issue

If you are not a user yet, you can read more about cutting your reporting time, putting external tools to work for you (and not against you) and delivering consistent results with our tool. Get a license and start saving yourself some time today.