Wapiti Web Vulnerability Scanner on AWS User Guide

Overview

This image runs Wapiti, the open source web application vulnerability scanner. Wapiti is a dynamic application security testing (DAST) tool: given the URL of a web application you own or are authorised to test, it crawls the application and actively injects payloads to surface real, exploitable vulnerabilities, then writes a report you can act on. Wapiti works as a black box; it does not read your source code, it fuzzes the forms, URLs and parameters it discovers and reports the vulnerability classes it can prove, including cross site scripting (XSS), SQL and NoSQL injection, command injection, path traversal, XML external entity (XXE), server side request forgery (SSRF), open redirects and exposed backup or configuration files.

The image is delivered as a ready to use appliance. Wapiti is installed unmodified from PyPI into an isolated virtualenv, with a thin wapiti wrapper on the system path, so the moment an engineer connects over SSH the scanner is installed, self verified and ready to run. There is no web interface, no daemon, no listening port and no login or bootstrap password of any kind, which is the strongest possible security posture: there is nothing to leak and nothing to rotate. Administration is over SSH with your own key.

Wapiti binds no listening socket. It is a client side scanner that only makes outbound requests to the targets you choose, so the shipped security group opens the SSH port only.

Responsible and authorised use

Wapiti is an offensive security tool. Actively scanning a web application sends attack payloads to it, and doing so against a system you do not own or are not authorised to test is illegal in most jurisdictions.

Only scan systems you own or have explicit written authorisation to test. This appliance is designed to make that the default: it ships with no scan target, and it never scans anything on its own except a deliberately vulnerable page it stands up on the loopback interface to self verify its own detection engine. You are responsible for ensuring you have authorisation for every target you scan.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line
• A web application you own or are authorised to test, if you intend to run a scan

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Wapiti. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes a short time after the instance state becomes Running and the status checks pass: the image self verifies the scanner on the instance and writes a per instance welcome note.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg Wapiti Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=wapiti}]'

When the instance state is Running and both status checks pass, note its public or private IP address for the SSH step.

Step 3: Connect over SSH

Connect to the instance with your key pair. The login user depends on the operating system variant you launched.

Connecting to your instance

ssh -i <key>.pem ubuntu@<public-ip>

Step 4: Read the welcome note

Every instance writes a per instance welcome note on first boot. It contains no secrets; it confirms the installed version and reminds you of the authorised only use policy and where the scheduled scan reads its targets.

sudo cat /root/wapiti-instance.txt

Step 5: Confirm the scanner and its attack modules

Confirm the installed Wapiti version and list the attack modules that are loaded. The module set includes the core web attack modules such as xss, sql, exec, file, xxe, ssrf and redirect.

wapiti --version

wapiti --list-modules

Step 6: Run your first scan

Point Wapiti at a web application you own or are authorised to test. The example below runs the default module set and writes an HTML report into a directory. Wapiti also supports -f json, -f xml and -f txt output formats, and the -m flag to select specific modules (for example -m xss,sql).

wapiti -u https://your-app.example/ -f html -o wapiti-report/

When the scan completes, open the report's index.html in a browser (copy it back with scp, or serve the directory) to review the findings. Each finding includes the vulnerable parameter, the payload that proved it, and the full HTTP request Wapiti sent, so you can reproduce and fix it.

The screenshot above shows Wapiti actively confirming a reflected cross site scripting vulnerability: it identified the injectable name parameter, injected an XSS payload, observed it reflected unescaped in the response, and reported the finding. This is Wapiti working as designed.

Step 7: The scheduled scan (optional)

The image ships a systemd timer, wapiti-scan.timer, that can run Wapiti daily against a list of authorised targets and write an HTML report for each into /var/log/wapiti/. The timer is enabled and active, but the target list at /etc/wapiti/targets.conf ships empty, so nothing is ever scanned until you add a target yourself.

systemctl is-active wapiti-scan.timer

To enable scheduled scanning, add one URL per line to the targets file for each web application you are authorised to test. Lines beginning with # and blank lines are ignored.

echo "https://staging.your-app.example/" | sudo tee -a /etc/wapiti/targets.conf

The scheduled scan is fail closed: a drop-in requires the first boot self verification to have completed and re-checks on every run that the scanner resolves and executes, so a broken install can never silently run a no-op scan. Reports accumulate under /var/log/wapiti/; wire them into your own review workflow to track a web application's security posture over time.

Step 8: Keeping the image current

The operating system and system Python install from the Ubuntu archive and are covered by unattended-upgrades, so security patches for the base are applied automatically. Wapiti itself and its Python dependencies are pinned inside the virtualenv for reproducibility; cloudimg refreshes them by re-cutting the image, which is the standard update model for a Python application appliance. To move to a newer Wapiti, launch a fresh instance from the latest cloudimg AMI.

Troubleshooting

• wapiti: command not found — the wrapper is at /usr/local/bin/wapiti; ensure /usr/local/bin is on your PATH, or invoke it by full path.
• A scan hangs or takes a long time — large applications take time to crawl and fuzz. Use --max-scan-time <seconds> to cap a scan, --scope url to limit it to the given URL, or -m <module> to run only specific modules.
• A scan reports no findings — that is a valid result; it means Wapiti did not prove any vulnerability in the scope it tested. Widen the scope, add modules, or provide authentication for pages behind a login.
• You must only scan authorised targets — if you are unsure whether you are authorised to test a system, do not scan it.

Support

cloudimg provides 24/7 technical support for this image by email and live chat. Our engineers help with running scans, choosing and tuning attack modules, interpreting reports, configuring the scheduled scan against authorised targets, integrating Wapiti into CI/CD security gates, and upgrade planning. Contact support@cloudimg.co.uk with your instance ID, Region, and a description of your question.