DEV Community

Lia
Lia

Posted on

How to Test Path Traversal and XXE Requests on a WAF with SafeLine

#waf #security #testing #xxe

Testing a web application firewall requires more than sending a suspicious URL and seeing an error. You need to confirm that traffic reaches the firewall, establish normal application behavior, and inspect evidence that explains what happened to each test request.

This guide explains how to test path traversal and XXE requests on a WAF using a controlled SafeLine deployment. SafeLine's documentation lists both attack categories among its defenses and supplies example requests for each. Those examples are useful starting points, but they do not establish complete coverage of every application or parser configuration. Source: SafeLine introduction

1. Prepare a controlled test environment

Use an application and infrastructure you own or have permission to test. Prefer a staging application with synthetic data. Record the application hostname, its upstream address, and the address of the server that will run SafeLine.

For an x86_64 installation, check the documented prerequisites: Linux, Docker 20.10.14 or later, Docker Compose 2.0.0 or later, at least one CPU core, 1 GB of memory, and 5 GB of disk space. The deployment guide also lists the ssse3 CPU requirement. Check these requirements before installation rather than discovering a missing dependency during testing. Source: installation guide

Prepare a small test record with columns for request, timestamp, expected result, observed response, and supporting evidence. Keep the exact request representation, including encoding, so another tester can reproduce it.

2. Install SafeLine and access the console

The official installation guide recommends this automated installation command, which requires root privileges:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Enter fullscreen mode Exit fullscreen mode

Review the installation instructions and the downloaded script before executing it on your chosen host. After installation, open the documented console address:

https://<safeline-ip>:9443/
Enter fullscreen mode Exit fullscreen mode

Retrieve the administrator credentials using the documented command:

docker exec safeline-mgt resetadmin
Enter fullscreen mode Exit fullscreen mode

Use the returned credentials to sign in. These installation and account-access steps come directly from the official deployment guide.

3. Configure the application traffic path

In the SafeLine console, open Applications and select Add Application. Enter the application's domain, the port SafeLine should listen on, and the upstream address of the original application. Select the SSL option for an HTTPS application. Resolve the configured domain to the SafeLine server's IP address. Source: application configuration

This routing matters because SafeLine operates as an HTTP/HTTPS reverse proxy: it receives requests and forwards allowed traffic to the upstream application. Requests sent directly to the upstream do not exercise that configured proxy path. Source: application configuration

Before sending suspicious input, load a normal application page through the configured hostname. Confirm that it works and record its response. If ordinary traffic fails, resolve the routing or application problem before interpreting attack-test results.

4. Send the documented path traversal probe

The official application guide supplies this path traversal example:

https://YOUR-TEST-DOMAIN/?id=../../../../etc/passwd
Enter fullscreen mode Exit fullscreen mode

Replace the placeholder with your authorized test hostname. The example places a traversal pattern in the id query parameter. It tests how the configured WAF handles that request; it does not establish that the application actually uses id to access files. Source: documented attack examples

Record the response and time. Then inspect the attack list in the SafeLine console and open the relevant entry's detail view, as described in the application guide. A blocking page together with a corresponding attack entry gives clearer evidence than an HTTP status alone.

5. Send the documented XXE probe and interpret it carefully

The official guide also provides an XXE example in a query parameter:

https://YOUR-TEST-DOMAIN/?id=<?xml+version="1.0"?><!DOCTYPE+foo+SYSTEM+"">
Enter fullscreen mode Exit fullscreen mode

Use your test hostname and record the request representation that your client actually sends. Characters such as angle brackets and quotation marks may be encoded by the client. Preserve that detail in your test record. Source: documented attack examples

This is a documented suspicious-input probe, not a complete demonstration of external entity resolution. Its external identifier is empty, and a query parameter does not necessarily reach an XML parser. Treat a block as evidence about this particular request.

For application-specific assessment, identify whether the application accepts XML, which endpoint processes it, and which content type it expects. Use an isolated fixture and harmless synthetic resources for any deeper parser testing. The supplied SafeLine documents do not prescribe an XML endpoint integration or a comprehensive XXE test suite.

6. Compare results against the baseline

Repeat the normal request after the probes. Compare successful legitimate access with the suspicious requests, their responses, and the available attack details.

Separate three conclusions in your notes: whether traffic reached SafeLine, whether the particular probe was blocked, and whether the application itself has a vulnerability. These are different findings. A block does not prove the upstream is secure, while an application error does not prove the WAF blocked anything.

FAQ

Does a blocking page prove complete path traversal protection?

No. It supports a conclusion about the request you sent. Coverage across other endpoints, encodings, and application behaviors requires additional controlled testing.

Is the documented XXE URL a complete XXE vulnerability test?

No. It is an example request supplied by SafeLine. Confirming an application vulnerability requires understanding whether attacker-controlled XML reaches a parser and how that parser handles external entities.

Where should I check the SafeLine result?

The official application guide directs you to the console's attack list and the detail view for a specific attack. Match the entry to your test time and request. Source: application guide

What if both normal and suspicious requests fail?

Check the configured hostname, listening port, HTTPS selection, upstream address, and domain resolution first. Restore a working baseline before attributing failures to attack detection.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)