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

      Understanding the Challenge Traditional firewalls focus on IP-based filtering, which can be bypassed by proxy networks, VPNs, and botnets. As attackers evolve, businesses require finer-grained security controls to detect and block threats at the HTTP ...

    • Securing and Optimising WordPress with VergeCloud Edge Protection

      Keeping your WordPress site secure and fast is critical—especially as online threats and performance demands grow. VergeCloud’s edge-based protection services help you defend your site from attacks while improving load speed through intelligent ...

    • Modify HTTP Headers on the Fly with VergeCloud CDN

      Understanding the Challenge Web applications and APIs rely on HTTP headers for authentication, caching, security, and traffic management. However, modifying headers at the origin often requires server-side code changes, leading to: Complex deployment ...

    • How to Record Visitors' True IP Addresses with VergeCloud

      Recording True IP Addresses Behind VergeCloud Proxy VergeCloud employs a reverse proxy approach, meaning the visitor IP addresses displayed in logs often show VergeCloud's IP instead of the actual visitor IPs. To address this, VergeCloud stores the ...

    • Page Rules and Caching Settings for WordPress with VergeCloud CDN

      Setting Up Page Rules and Browser Caching for Your WordPress Site with VergeCloud CDN When you activate VergeCloud CDN for your WordPress site, content is cached on VergeCloud's edge servers for 30 minutes by default. However, some parts of your ...