An open-source project in Golang to asess different API Security tools and WAF for detection logic and bypasses
An open-source project in Golang to asess different API Security tools and WAF for detection logic and bypasses
GoTestWAF is a tool for API and OWASP attack simulation that supports a wide range of API protocols including REST, GraphQL, gRPC, SOAP, XMLRPC, and others.
It was designed to evaluate web application security solutions, such as API security proxies, Web Application Firewalls, IPS, API gateways, and others.
GoTestWAF generates malicious requests using encoded payloads placed in different parts of HTTP requests: its body, headers, URL parameters, etc. Generated requests are sent to the application security solution URL specified during GoTestWAF launch. The results of the security solution evaluation are recorded in the report file created on your machine.
Default conditions for request generation are defined in the testcases folder in the YAML files of the following format:
payload:
- '"union select -7431.1, name, @aaa from u_base--w-'
- "'or 123.22=123.22"
- "' waitfor delay '00:00:10'--"
- "')) or pg_sleep(5)--"
encoder:
- Base64Flat
- URL
placeholder:
- UrlPath
- UrlParam
- JSUnicode
- Header
type: SQL Injection
payload is a malicious attack sample (e.g XSS payload like <script>alert(111)</script> or something more sophisticated).
Since the format of the YAML string is required for payloads, they must be encoded as binary data.
encoder is an encoder to be applied to the payload before placing it to the HTTP request. Possible encoders are:
placeholder is a place inside HTTP request where encoded payload should be. Possible placeholders are:
The RawRequest placeholder will allow you to do an arbitrary HTTP request. The payload is substituted by replacing the string {{payload}} in the URL path, Headers or body. Fields of RawRequest placeholder:
methodpathheadersbody Required fields for RawRequest placeholder:
method fieldExample:
…
type is a name of entire group of the payloads in file. It can be arbitrary, but should reflect the type of attacks in the file.Request generation is a three-step process involving the multiplication of payload amount by encoder and placeholder amounts. Let's say you defined 2 payloads, 3 encoders (Base64, JSUnicode, and URL) and 1 placeholder (URLParameter - HTTP GET parameter). In this case, GoTestWAF will send 2x3x1 = 6 requests in a test case.
During GoTestWAF launch, you can also choose test cases between two embedded: OWASP Top-10, OWASP-API,
or your own (by using the configuration option testCasePath).
The steps below walk through downloading and starting GoTestWAF with minimal configuration on Docker.
Pull the GoTestWAF image from Docker Hub:
docker pull wallarm/gotestwaf
Start the GoTestWAF image:
docker run --rm --network="host" -it -v ${PWD}/reports:/app/reports \
wallarm/gotestwaf --url=<EVALUATED_SECURITY_SOLUTION_URL>
If required, you can replace ${PWD}/reports with the path to another folder used to place the evaluation report.
If you don't want to optionally email the report, just press Enter after the email request message appears, or you can use --noEmailReport to skip the message:
docker run --rm --network="host" -v ${PWD}/reports:/app/reports \
wallarm/gotestwaf --url=<EVALUATED_SECURITY_SOLUTION_URL> --noEmailReport
If the evaluated security tool is available externally, you can skip the option --network="host". This option enables interaction of Docker containers running on 127.0.0.1.
To perform the gRPC tests you must have a working endpoint and use the --grpcPort cli option.
docker run --rm --network="host" -it -v ${PWD}/reports:/app/reports \
wallarm/gotestwaf --grpcPort 9000 --url=http://my.grpc.endpoint
Check your email for the report.
You have successfully evaluated your application security solution by using GoTestWAF with minimal configuration. To learn advanced configuration options, please use this link.
Check the evaluation results logged using the STDOUT and STDERR services. For example:
…
The report file waf-evaluation-report-<date>.pdf is available in the reports folder of the user directory. You can also specify the directory to save the reports with the reportPath parameter and the name of the report file with the reportName parameter. To learn advanced configuration options, please use this link.
You can found an example of PDF report here.
You can try GoTestWAF by running the demo environment that deploys NGINX‑based ModSecurity using OWASP Core Rule Set and GoTestWAF evaluating ModSecurity on Docker.
To run the demo environment:
Clone this repository and go to the cloned directory:
git clone https://github.com/wallarm/gotestwaf.git
cd gotestwaf
Start ModSecurity from the Docker image by using the following make command:
make modsec
Settings for running the ModSecurity Docker container are defined in the rule modsec of the cloned Makefile. It runs the ModSecurity Docker container on port 8080 with minimal configuration defined in the cloned file ./resources/default.conf.template and the PARANOIA value set to 1.
If required, you can change these settings by editing the rule modsec in the cloned Makefile. Available options for ModSecurity configuration are described on Docker Hub.
To stop ModSecurity containers use the following command:
make modsec_down
Start GoTestWAF with minimal configuration by using one of the following methods:
Start the Docker image by using the following docker pull and docker run commands:
docker pull wallarm/gotestwaf
docker run --rm --network="host" -v ${PWD}/reports:/app/reports \
wallarm/gotestwaf --url=http://127.0.0.1:8080 --noEmailReport
Build the GoTestWAF Docker image from the Dockerfile and run the
image by using the following make commands (make sure ModSec is running on port 8080; if not, update the port value in the Makefile):
make gotestwaf
make scan_local_from_docker
Start GoTestWAF natively with go by using the following make command:
(make sure ModSec is running on port 8080; if not, update the port value in the Makefile):
make scan_local
Find the report file waf-evaluation-report-<date>.pdf in
the reports folder that you mapped to /app/reports inside the container.
In addition to running the GoTestWAF Docker image downloaded from Docker Hub, you can run GoTestWAF by using the following options:
Clone this repository and build the GoTestWAF Docker image from the Dockerfile, for example:
git clone https://github.com/wallarm/gotestwaf.git
cd gotestwaf
DOCKER_BUILDKIT=1 docker build --force-rm -t gotestwaf .
docker run --rm --network="host" -it -v ${PWD}/reports:/app/reports \
gotestwaf --url=<EVALUATED_SECURITY_SOLUTION_URL>
If the evaluated security tool is available externally, you can skip the option --network="host". This option enables interaction of Docker containers running on 127.0.0.1.
Clone this repository and run GoTestWAF with go, for example:
git clone https://github.com/wallarm/gotestwaf.git
cd gotestwaf
go run ./cmd --url=<EVALUATED_SECURITY_SOLUTION_URL>
Clone this repository and build GoTestWAF as the Go module:
git clone https://github.com/wallarm/gotestwaf.git
cd gotestwaf
go build -mod vendor -o gotestwaf ./cmd
Supported GoTestWAF configuration options are described below.
…
GoTestWAF supports two HTTP clients for performing requests, selectable via the --httpClient option. The default client is the standard Golang HTTP client. The second option is Chrome, which can be used with the --httpClient=chrome CLI argument. Note that on Linux systems, you must add the --cap-add=SYS_ADMIN argument to the Docker arguments to run GoTestWAF with Chrome as the request performer.
For better scanning, GTW supports sending malicious vectors through valid application requests. Instead of constructing requests that are simple in structure and send them to the URL specified at startup, GoTestWAF creates valid requests based on the application's API description in the OpenAPI 3.0 format.
How it works:
GoTestWAF loads an OpenAPI file and constructs request templates. All templates are then divided into groups based on what placeholders they support (e.g., if there is a string parameter in the request path, then such a request will be assigned to a group of requests that support URLPath placeholder)
The next malicious vector is selected from the queue for sending. Based on the placeholder specified for it, all query templates are selected into which this vector can be substituted. Next, the vector is substituted into template and the request is sent.
Based on the possible responses specified in the OpenAPI file, it is determined whether the request was blocked by WAF or passed to the application. If the status of the response code and its scheme match those described in the OpenAPI file, the request is marked as bypassed. Otherwise, it will be marked as blocked. It is possible that the application only responds with a status code, and this status code matches the response from the WAF. In this case, the request will be marke
No open issues yet, or sync has not completed.