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.

    • Related Articles

    • Advanced HTTP Header-Based Firewall with VergeCloud

      Most traditional firewalls make decisions based on IP addresses. While this is still an important security measure, it doesn't always stop modern attacks. Today, attackers often use VPNs, proxy servers, botnets, and rotating IP addresses to hide ...

    • How to Test Rate Limiting in Verge Cloud

      Rate limiting is a traffic control mechanism used to regulate the number of requests a client can make to a server within a defined time window. It plays a critical role in protecting web applications, APIs, and backend infrastructure from abuse, ...

    • Securing and Optimising WordPress with VergeCloud Edge Protection

      WordPress powers millions of websites worldwide, making it one of the most popular content management systems on the internet. Its popularity, however, also makes it a common target for automated attacks, brute-force login attempts, vulnerability ...

    • VergeCloud Error Codes

      While using VergeCloud services, you may occasionally encounter platform specific error codes. These errors are not random system failures. They usually indicate that a configured rule, security policy, or access restriction has been triggered. This ...

    • Modify HTTP Headers on the Fly with VergeCloud CDN

      HTTP headers are a critical part of how web applications and APIs communicate. They carry information that influences authentication, caching, security, content delivery, and traffic management. In many environments, even a simple header update ...