Skip to content

Version 4.1 - January 2024

Venari 4.1 brings high impact improvements for end-to-end DevSecOps automation. Multi-Factor Authentication (MFA) automation is now supported via the Venari Watcher and Postman scripts can be executed during API or page-based scans without the need for Postman or Newman to be installed. Full IDOR test automation is enabled using multiple user credential configuration where the scanner recognizes user-scoped resources. DevOps integrations have been expanded via new APIs and WebHooks. New traffic import/export formats, JWT auto-detection, performance improvements and various scan diagnostics exports round out the list of new features.

The full list of features and enhancements is shown below.

Highlights

Postman Script Execution

Venari 4.1 can import Postman collections and environment files. Any scripts and/or tests in the collection will execute during the Venari scan and in the Playground view where ordered workflows are composed. These scripts run natively inside Venari's script execution engine and do not require Postman or Newman to be installed or used as proxies. The execution is 100% 'in the box' in Venari. The Postman object model and scripts can also be used by workflows and traffic definitions that are created in the Venari playground UI.

The animation below shows an imported Postman collection's 'Login' method being run and the result of the script execution.

The screenshots below show the sequence of testing an imported Postman operation to validate correct script execution and the successful harvesting of a login token.

Select Application

Select the Traffic View

Select the Traffic Definition

Select the Operation and the Script Tab

Click the SEND Button and Observe the Result

View the Test Results Tab

MFA Login Support

Venari now supports email-based multi-factor authentication (MFA). This functionality is provided by the Venari Watcher cloud component expecting an email address in a specific format: {guid}@venari-watcher.assertsecurity.io

To use the MFA feature, the security tester must register an account with the application being tested. This email address must conform to the format specified above.

The high level steps to set up MFA login are:

  1. Register the account with the application under test using the required format.
  2. Start recording a workflow from the Venari workflow recorder.
  3. When the OTP token is prompted for, use the workflow recorder to manually add a 'Read Email' step (see example images below).
  4. When the complete set of steps is recorded, test the workflow using the 'Test' tab
  5. In the test tab, type the email address into the email box. Also type the variable expression {code} into the bottom input box. In the example below, the label is "Input_*".
  6. The workflow playback will fill in this variable value with the token value scraped from the validation email received by the Venari Watcher.

The screenshots below show examples of the UI states to expect when recording the MFA workflow.

Add 'Read Email step' at the point in the workflow where a code challenge pops up

Type {code} into the Input_* field and it will be filled out by 'Read Email' step

The complete set of steps will be similar to the image below

IDOR Testing with Multiple User Credentials

Venari 4.1 adds a powerful new capability to detect Insecure Direct Object Reference (IDOR) vulnerabilities. The detection algorithm combines knowledge of 'user-scoped resources' with the ability to use multiple sets of credentials to test resource access for PRIMARY, SECONDARY and anonymous users. The high-level description of the IDOR algorithm and the various techniques used to tag user-scoped resources and input user credentials are shown below.

IDOR Detection Algorithm

IDOR detection is applied to specially tagged URL targets (resources) that SHOULD be accessible only to a single user. The HTTP traffic associated with attempted access to these resources is analyzed using Venari's next-generation login/state capabilities and flexible rule engine.

At a very high level, it works like this:

  • Using the Venari UI, a security tester specifies user-scoped resources (see the next section for 4 ways to specify these resources).
  • Credentials are created for a PRIMARY user and - optionally - a SECONDARY user. (see the credential section for details on creating these users).
  • User-scoped resources are detected in discovery traffic and accessed by the logged in PRIMARY user.
  • The same user-scoped resource is then accessed in a logged out state as an anonymous user.
  • The contents of the responses are compared to see if the anonymous user was able to retrieve the resource that SHOULD have only been accessible to the PRIMARY user. If the resource is retrieved, a vulnerability is flagged since the application did not properly enforce authentication or authorization.
  • If a SECONDARY user is configured, the same resource is accessed in a logged in state as a SECONDARY user.
  • The contents of the responses are compared to see if the SECONDARY user was able to retrieve the resource that SHOULD have only been accessible to the PRIMARY user. If the resource is retrieved, a vulnerability is flagged since the application did not enforce authorization.
  • If the user-scoped resource was specified using the IDOR resource auto-detection logic (see next section) then the finding is flagged as 'IDOR Possible' and rated as INFO. This low severity is set because auto-detected resource names are not as reliable as the other techniques for tagging user-scoped resources.

Specifying User-Scoped Resources

There are 4 ways to specify user-scoped resources. These techniques are described below:

1. Fingerprint Settings

Strict rules can be specified to unambiguously detect user-scoped resources in HTTP traffic.

2. Playground Operation Tagging

The Traffic Playground can be used to select individual HTTP request 'operations' as user-scoped resources via tagging.

3. Scan Traffic Filtered Result

This is an advanced technique. Traffic can be filtered using search criteria and then scanned. By selecting ONLY the IDOR rule, you can indicate to the scanner that ALL selected URL targets are to be treated as tagged, user-scoped resources for purposes of this scan.

4. Auto-Detect Heuristic

User-scoped resources are auto-detected by default using a list of patterns that match common names (or parts of names). Examples: 'user' or 'profile' or 'account'. This auto-detection can cause the IDOR detector to flag a vulnerability, but the severity is set to INFO because this list-based methodology is not strict and can be prone to false-positives. If you want to disable this behavior entirely, disable the list via a checkbox. (see below).

Specifying Multiple Credentials

1. Application Wizard

The application wizard allows you to enter primary and secondary credentials when the application is created.

2. Scan Traffic Wizard

The scan traffic wizard has an authentication tab which allows you to specify multiple user credentials.

3. Job Template Variable Tagging

Scan job variables can be tagged for specific user types that are used by the IDOR rule.

OWASP Scan Templates

Two new scan templates have been added to encapsulate inspection and fuzzing operations that are specific to the OWASP Top 10 lists.

Venari WebHooks

Venari DevOps can now push notifications via WebHooks. Once a customer sets up a WebHook server using the provided GitHub sample and configures the endpoint in the Venari UI, Venari can push scan events to the server.

The GitHub sample server and build instructions can be found at: https://github.com/assert-security/venari-webhook

The currently available events are:

  • Server Started
  • Job Running
  • Job Paused
  • Job Failed
  • Job Completed
  • Job Alert
  • Job Finding

The screenshot below shows where to configure the WebHook server endpoint

The GitHub sample server can be found at: https://github.com/assert-security/venari-webhook

Diagnostics Export/Import

Detailed scan job data can now be exported to a zip file for troubleshooting. This information is useful for diagnosing scan discovery issues and for tuning template settings.

The animation below shows the steps to export diagnostics data to a zip file.

The image below shows the available export options

Traffic Export to WARC Format

Scan traffic can now be exported to the WARC traffic format. The WARC format is a standard way of storing content that has been harvested from the web. It is used by web archiving organizations to preserve and access web resources over time. A WARC file is a container file that contains multiple files, such as HTML, PDF, images, etc., along with metadata and information about how they were collected and arranged.

Improved Ignore Report

Venari scans can be configured to control the scope of a scan (what targets are allowed and disallowed) and also to control various limits (white lists, black lists, max counts etc). When a traffic request, browser action, inspection, fuzz operation or any other Venari action is prevented by these settings, an 'ignore item' is recorded. This ignore information is useful in tuning scan settings for optimal scan performance and coverage. Venari 4.1 has improved settings for exporting these ignored items for review.

The animation below shows how to export the 'Ignored Items' report.

Tracker Detection and Fingerprint Info

Application fingerprinting has been enhanced with tracker detection. XHR targets, external reference URLs, redirects and query-embedded URLs are analyzed to detect known tracker domains.

The screenshot below shows the results of a 2 minute scan of a large news site. In that brief time, 80 trackers have been detected and stored as fingerprint data. This type of URL information reveals a lot of useful detail about the composition of a site. Frequently, web site operators are not fully aware of all the inbound and outbound URLs that affect their site's performance, functionality and security. The tracker view and other XHR-oriented fingerprint views help security teams to understand the dependencies of a site/app. Even the undocumented ones.

Encoder/Decoder Tool

The Encode/Decode context menu actions from Venari traffic views have been exposed as a stand-alone tool that can be launched from the main UI page.

The screenshots below shows an iterative decoding of a base64 string. This type of nested structure is revealed by Venari's recursive X-RAY detection.

Launch the Encode/Decode Tool

Enter the payload to decode

Select X-RAY

Select Layer 1 Decode Result

Select Layer 2 Decode Result

Select Layer 3 Decode Result

JWT recognized in X-RAY views

JWT token payloads can be detected and decoded in the Venari X-RAY views and during scans.

Add New Template Across Applications

Venari 4.1 adds the ability to create a new job template and apply it to many selected (or all) applications. The template patching feature has been enhanced to allow a modified template to be added into multiple applications with a custom name.

The screenshots below show a patch file transforming the 'Exploit' template and applying it to multiple applications under the new name 'Exploit_PlusPlus'

Select the 'Apply Patch' action from the main UI screen

Select the patch file and the template to transform, then type in the new template name and select the applications to apply it to

Individual Traffic Item Export from Traffic View

Venari's traffic views have a new context menu action to export the individual request/response items to a file.

Audit Log

Venari DevOps has a new audit log that keeps track of the following events:

  • Users add/update/delete
  • Application Groups add/update/delete
  • Jobs start/delete
  • Job Templates add/update/delete
  • DevOps API keys add/delete
  • Application add/delete

There will be a folder named AuditLogs located wherever Master Node app data is stored.

New DevOps APIs

The following DevOps APIs were added and/or enhanced:

  • GetFindingByID: New
  • GetAllJobTemplates: New
  • GetWebHookPublicKey: New
  • ExportWarcTraffic: New
  • GetApplications: Filter criteria added
  • GetJobs: Filter criteria added
  • ExportIgnoredItems: New items selectable

Resource Headers Setting

Headers can now optionally be specified as 'resource headers', which means the header becomes a part of the unique signature of the requests and/or responses it appears in. As an example of where this is useful, imagine an API endpoint where all operations are targeted to the same URL and the action is specified in the a header called X-Operation-Name. Various algorithms that compute unique hashes to limit redundant traffic need to know that this header is a critical part of the signature, so the user would add X-Operation-Name to the list of resource headers.

The image below shows how to configure the example X-Operation-Name header.

Fuzz Performance Auto-Detect

There is a new flag for auto-detecting slow scan performance caused by fuzzing operations. This flag is off by default. When the setting is enabled, the request engine looks for anomalously slow traffic for non-time-based rules. If fuzzing is causing requests to take a very long time (as compared to their discovery baseline) then the rule will stop running once a certain threshold of performance impact is reached. This settings allows scan operators to automatically identify extremely long requests and optionally prune that behavior away to make scans complete faster.

Workflow Recorder Auto-Scale

The workflow recorder works well with the Chromium browser at horizontal resolutions below 2560 pixels. Above that number of pixels, operating systems offer scaling features to make text and images readable on different sized monitors. This scaling can throw off the workflow recorder's ability to locate clicked items specified during the recording phase.

To help with this situation, there is now an auto-scale checkbox in the recorder UI. If you encounter trouble recording workflows and see errors that indicate that the item could not be identified, then enable auto-scaling. The browser will restart and resize itself to a 100% scale factor (regardless of the OS scale setting). This should allow the workflow to be recorded.

This setting is only needed when OS scaling at high resolutions is causing problems. So the auto-scale behavior is unchecked by default.

Traffic Storage Hashing Improvements

Venari 4.1 has improved control over the volume of HTTP traffic stored during a scan by specifying the uniqueness criteria of saved traffic. This advanced feature allows DevSecOps operators to limit the volume of duplicate or 'near-duplicate' traffic stored.