All Collections
Running HawkScan
Configuring app.host in stackhawk.yml
Configuring app.host in stackhawk.yml

How to configure the host configuration for a target application

Anthony Stinn avatar
Written by Anthony Stinn
Updated over a week ago

Overview

HawkScan is highly configurable, accommodating multiple application types and their associated aspects such as authentication, path discovery (e.g., spidering), and API architecture.

If an application has an HTTP(S) endpoint, HawkScan can scan it, regardless of the underlying tech stack.

To that end, HawkScan requires that the app.host field be configured in stackhawk.yml -- this represents the root URL of the application being scanned.

What do we mean by root URL?

HawkScan allows the following options for URL's in app.host:

  1. an FQDN in a URL (https://app.company.com)

  2. an IP:PORT in a URL (https://192.168.1.1:443)

  3. localhost as URL

    1. https://localhost:5000

    2. https://127.0.0.1:8000

  4. a domain as a URL (https://domain.com)

    1. this approach is uncommon -- scans should be granular, localized, and non-production in nature (for instance, in a GitHub Actions pipeline).

Notes:

  • While the above examples use https, http (e.g., http://localhost:5000) is also an option within the URL

  • If not port is specified in the URL, the default http port (80) or https port (443) are assumed

But what about paths?

Specific paths (e.g., API paths such as https://myapp.com/api/v2) can be scanned, but can't serve as the root of the application to be scanned.

If you have applications for which communication with the root application url is not allowed (i.e., only specific paths respond to http messages, but the root does not), reach out to StackHawk Support for assistance.


Scanning Procedure

  1. Set app.host according to the rules above

  2. Configure HawkScan to populate the paths beneath the application root, via:

    1. hawk.spider configuration

      1. standard spider (on by default)

      2. ajax spider (off by default)

      3. seedPaths

        1. manually enter app.spider.seedPaths entries to add additional starting points (relative to app.host) for crawling

          1. not for use for populating API Paths...see below

    2. API configuration (to seed API paths to be scanned):

      1. OpenAPI (including Postman collections)

    3. set up Authenticated scanning as applicable

  3. Run a scan

  4. Repeat after me: "KaaKaww!"

Did this answer your question?