Skip to content

Version 1.1 - May 2019

Welcome to the 1.1 update of Venari. There are a number of updates in this version and some significant bug fixes from the 1.0 beta feedback. Some of the highlights include:

UI Layout Changes

Version 1.1 introduces icons to the left side panel as well as local and remote server choice in the menu bar.

The left panel is now split into operations for the current scan (top group) and operations that apply to the local server (bottom group).

Fast Retest of Vulnerability Findings

Clicking the results view from the left side panel takes the user to an aggregated view of all of the vulnerabilities that are currently known for the application. This view is an aggregate of all scans to date. The highlighted button launches a single step retest operation. Note that this retest is only for the selected vulnerability and does not require a full re-scan. The meta data from the vulnerability finding is stored in the workspace DB for the application and this data is the bare minimum needed to drive the exploiter module to replay the navigation and attack actions (including login if applicable). One important feature is the ability to specify an alternate host to run the retest against. In situations where the vulnerability was found in a different test environment the metadata is modified to update the urls from the original scan to the new target. This new target can be specified by the user.

The screenshot below shows a retest in progress. Retests typically take only a few seconds.

Remote Connect Settings

The local server scenario is the default for Venari and this means that the electron UI tool is consuming the REST API directly from a scan server running on the same machine. The Venari CE installer includes the UI client and a LocalServer executable that runs the scans.

The settings option pops a dialog that allows the user to enter the remote URL of the master controller node. This configuration allows users to connect to the automation trial pack and manage the master node and job nodes. The trial pack is available by request from Here. Note that the local server configuration is a single job node paired with the UI as the REST client. The UI can also connect to a remote master and this will unlock new functionality - such as elastic scanning. The UI is an optional component for DevOps deployments but is a useful way to onboard applications and customize settings if needed. The trial pack is intended to be a proof of concept enabler to allow DevOps engineers to integrate headless scanning into their CI/CD operations.

Traffic Tree Reorganized

The sample screen shot below shows an expanded origins node. These are the external servers that were connected to the application being scanned. Note that this is not a list of domains built from hyperlinks but is the collection of live XHR targets, browser navigations, CDNs, web socket URLs etc. The origins node tracks the browser's interconnections to other servers. More detailed information about each origin can be seen in the fingerprint origins collection.

Improved Throughput for Spider Crawl

Discovery (crawling) can work in a few different ways. The exploiter template and the browser discovery template configure the scanner for phased crawling where the browser discovery runs first and spidering is delayed until browsing is complete. Alternately, the spider crawl template configures the scan to behave more like a traditional web spider. As hyperlinks are discovered in initial HTTP responses, the links are analyzed and queued for immediate requesting. This approach is useful when a large site needs to be mapped and a faster scan is desirable. Note that you can configure browser and spider discovery to happen concurrently, but the default generated configuration separates these approaches into two separate templates.

Additional Host Whitelist Controls

The highlighted control in the screen shot below allows additional hosts to be whitelisted into a scan. For example, if scanning www.foo.com and a link to blog.foo.com were encountered, by default that new host would not be in scope. Adding it to the whiteliast would allow the discovery and exploit actions to treat blog.foo.com as in scope if the link was iscovered.

Fingerprint Collections

The screen shot below shows the sub-panel in the fingerprint view where the new collection categories can be seen. The scanner collects queryable metadata about various technologies and behaviors related to the application. The following categories are being released in version 1.1.

  • Connected external Origins and web socket URLs
  • Connected affiliate domains
  • Accumulated local storage and session storage
  • Query and Post parameters
  • Cookies
  • JS Frameworks
  • Accurate WordPress version detection (and corresponding plugin/versions)
  • Request and response headers

Sample of External Origins

Sample of Affiliates

Sample of DOM Storage