VergeCloud WAF Penetration Test Results and Analysis

VergeCloud Web Application Firewall (WAF) Penetration Test

 This guide provides a practical security evaluation of the VergeCloud Web Application Firewall (WAF) under real-world attack scenarios. It demonstrates how common threats such as XSS, SQL Injection, and Stored XSS are tested to assess the system’s ability to detect and block malicious requests before they reach the origin server. The results highlight how the WAF consistently responds with 403 Forbidden errors, effectively preventing potential exploits and strengthening overall application security. If you want to understand how this protection layer performs under real attack conditions, continue reading this guide.

XSS Attack Simulation via cURL Request

Command Used:

  1. curl -v "http://example.com/onload=alert("XSS")>"

This is a CLI-based variation of the previous test, where a cURL command simulates a browser making a request with a malicious script in the URL. The test checks whether the WAF or web server logs the payload and blocks it appropriately.


Output:

  1. ~ curl -v "http://example.com/onload=alert(\"XSS\")"
  2. * Host example.com:80 was resolved.
  3. * IPv6: (none)
  4. * IPv4: 31.57.157.1
  5. *   Trying 31.57.157.1:80...
  6. * Connected to example.com (31.57.157.1) port 80
  7. > GET /onload=alert("XSS") HTTP/1.1
  8. > Host: example.com
  9. > User-Agent: curl/8.7.1
  10. > Accept: */*
  11. >
  12. * Request completely sent off
  13. < HTTP/1.1 403 Forbidden
  14. < Date: Mon, 05 May 2025 12:57:27 GMT
  15. < Content-Type: text/html
  16. < Content-Length: 2656
  17. < Connection: keep-alive
  18. < Keep-Alive: timeout=65
  19. < Vary: Accept-Encoding
  20. < Server: vergecloud
  21. < Server-Timing: total;dur=0
  22. < X-Served-By: 7500
  23. <
  24. * Connection #0 to host example.com left intact
  25. <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width"><link href="//example.com/favicon.ico"></head><title>403 Forbidden</title><body><main class="mainContainer"><section class="topSection"><div class="errorContainer"><img class="errorIcon" src="/cdn-cgi/images/icons/block.svg" alt="Title Icon"><h1><b>403</b><span>Forbidden</span></h1><div class="reason">Access to this resource is forbidden.</p></div></div><div class="imageContainer"><img class="errorIllustrate" src="/cdn-cgi/images/error-pages/403.svg" alt="Page Image"></div></section><footer><div class="accordionContainer"><div class="accordionBox"><h1 class="questionTitle">Why This Happens?<i class="accordionButton vc-arrow" onclick="handleAccordionClick2(this)"></i></h1><p class="answer">This error occurs when the server denies access to a resource, like a webpage or API. It may happen if a <b>WAF</b> rule blocks the request, <b>firewall</b> settings restrict access, or the <b>secure link</b> is invalid.</p></div><div class="questionBox"><h1 class="questionTitle">What can you do about this?<i class="accordionButton vc-arrow" onclick="handleAccordionClick2(this)"></i></h1><p class="answer">If you are the <b>website owner</b>, review your WAF and firewall configurations and ensure the secure link is valid. If you are a <b>visitor</b>, check the link or contact the website administrator for assistance.</p></div></div><div class="s

 

Outcome:
The terminal output also shows an HTTP 403 Forbidden response.
Like the browser-based version, the WAF intercepted the malicious payload and denied access.

Conclusion:
The WAF effectively blocked the CLI-based reflected XSS attempt as well.

SQL Injection Attempt on URL Query Parameter

Command Used:

  1. curl "http://example.com/users/?id=SELECT+*+FROM+users"\; -v

 

This test sends an SǪL Injection attempt by modifying a query parameter (id=) to try and fetch all user data. If the input is not properly escaped or sanitized, it can expose the backend database to unauthorized data access. The WAF should detect and block such attempts.
 

Output:

  1. ~ curl "http://example.com/users/?id=SELECT+*+FROM+users"; -v
  2. * Host example.com:80 was resolved.
  3. * IPv6: (none)
  4. * IPv4: 31.57.157.1
  5. *   Trying 31.57.157.1:80...
  6. * Connected to example.com (31.57.157.1) port 80
  7. > GET /users/?id=SELECT+*+FROM+users; HTTP/1.1
  8. > Host: example.com
  9. > User-Agent: curl/8.7.1
  10. > Accept: */*
  11. >
  12. * Request completely sent off
  13. < HTTP/1.1 403 Forbidden
  14. < Date: Mon, 05 May 2025 12:58:45 GMT
  15. < Content-Type: text/html
  16. < Content-Length: 2656
  17. < Connection: keep-alive
  18. < Keep-Alive: timeout=65
  19. < Vary: Accept-Encoding
  20. < Server: vergecloud
  21. < Server-Timing: total;dur=6
  22. < X-Served-By: 7500
  23. <
  24. * Connection #0 to host example.com left intact
  25. <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width"><link href="//example.com/favicon.ico"></head><title>403 Forbidden</title><body><main class="mainContainer"><section class="topSection"><div class="errorContainer"><img class="errorIcon" src="/cdn-cgi/images/


Outcome:

Again, the server responds with an HTTP 403 Forbidden.
The HTML response page mentions that the request was blocked due to a security restriction.

Conclusion:
The WAF detected and prevented a potential SǪL injection, indicating solid protection on query parameter inputs.

Stored XSS Payload Submission via API Endpoint


Command
 Used:

  1. curl -i -X POST \
  2. -H "Content-Type: application/json" \
  3. -d '{"title":"Hello","body":"<script>alert(\"stored\")</script>"}' \
  4. http://example.com/api/posts

This is the actual stored XSS test against the example.com endpoint. The payload tries to persist malicious JavaScript in the backend. A strong WAF and backend validation should prevent the data from being saved or flagged for review before rendering.

Output:

  1. ~ curl -i -X POST \
  2.    -H "Content-Type: application/json" \
  3.    -d '{"title":"Hello","body":"<script>alert(\"stored\")</script>"}' \
  4.    http://example.com/api/posts
  5. HTTP/1.1 403 Forbidden  
  6. Date: Mon, 05 May 2025 13:13:04 GMT  
  7. Content-Type: text/html  
  8. Content-Length: 2656  
  9. Connection: keep-alive  
  10. Keep-Alive: timeout=65  
  11. Vary: Accept-Encoding  
  12. Server: vergecloud  
  13. Server-Timing: total;dur=2  
  14. X-Served-By: 7500  
  15.  
  16. <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width"><link href="//example.com/favicon.ico"></head><title>403 Forbidden</title><body><main class="mainContainer"><section class="topSection"><div class="errorContainer"><img class="errorIcon" src="/cdn-cgi/images/icons/block.svg" alt="Title Icon"><h1><b>403


Outcome:

The server responded with HTTP 403 Forbidden.
This implies that either the WAF or the backend validation blocked the POST request due to detection of malicious content.

Conclusion:
The system blocked the stored XSS attempt, likely using content inspection of the request body.