A Checklist for nginx Pentesting

with o1-pro

Below is a 50-item checklist for pentesting nginx, crafted by o1-pro from OpenAI.

This should be useful for pentesters and cybersecurity professionals. I am not an expert in pentesting nginx, thus I cannot confirm the validity of all the checks. So, if you’re good in this realm, share your criticism/thoughts below.

(!use ethically and legally with permission from your clients)

---

1. Enumerate NGINX Version and Modules

• Goal: Identify potential known vulnerabilities associated with a specific version or module.

• Method:

  • Use curl -I <target> or nmap -p 80,443 --script=http-server-header <target> to grab HTTP headers and see if the server leaks version details.

  • Look for “Server: nginx/1.18.0” or similar.

2. Check for Default or Sensitive Files

• Goal: Locate unremoved sample files or default pages.

• Method:

  • Common paths: /nginx_status, /server-status, /info, /test, /admin, /backup/

  • Use a content discovery tool like dirb, dirsearch, or ffuf to find hidden endpoints.

3. Test for Directory Listing / Indexing

• Goal: Identify misconfiguration that allows directory listing.

• Method:

  • Send requests to directories (e.g., GET /images/) to see if the server returns directory listings with file names.

4. Directory Traversal (Misconfigured alias or root)

• Goal: Access files outside the web root if NGINX alias or root directives are misconfigured.

• Potential Payload:

  • GET /..%2F..%2Fetc/sensitive HTTP/1.1

  • GET /../etc/sensitive

• Check: If the response reveals system files, the server is vulnerable.

5. Path Normalization and Double Encoding

• Goal: Bypass security filters or rewrite rules.

• Potential Payload:

  • GET /..%252F..%252Fetc/sensitive

  • GET /%2e%2e/%2e%2e/etc/sensitive

• Check: If the server incorrectly normalizes paths, you may gain access to restricted files.

6. Test for Unrestricted Proxy Pass

• Goal: Exploit proxy_pass directives that forward requests to internal services or external domains.

• Method:

  • If a location block is configured with proxy_pass but no host validation, you can craft requests to internal IPs (10.x.x.x, 192.168.x.x) or other services.

7. Server-Side Request Forgery (SSRF) via Misconfigured Proxy

• Goal: Pivot from the NGINX server to internal network or local services (e.g., AWS metadata).

• Potential Payload:

  • GET /?url=http://169.254.169.254/latest/meta-data/

• Check: If the server fetches the internal resource and returns data, SSRF is possible.

8. HTTP Request Smuggling (Chunked Encodings)

• Goal: Bypass front-end security devices or cause desynchronization with backend servers.

• Payload Example (truncated chunk encoding):

POST / HTTP/1.1
Host: target
Transfer-Encoding: chunked

4
POST /admin HTTP/1.1
Content-Length: 35

0

• Check: Observe the response to see if your injected request is processed by NGINX or the backend differently than intended.

9. Check for Reverse Proxy Cache Poisoning

• Goal: Cache malicious payload or inject undesired responses for legitimate users.

• Method:

  • Send requests with ambiguous headers (X-Forwarded-Host, X-Original-URL, Host) or unusual query parameters to see if the server merges them incorrectly.

  • Attempt to poison the cache by including a malicious parameter that gets cached for other users.

10. Host Header Injection

• Goal: Manipulate how the server interprets the Host header for virtual host routing or internal re-routes.

• Payload:

GET / HTTP/1.1
Host: evil.com

• Check: If the server processes the request as if from evil.com, it may serve unexpected pages or allow cache poisoning.

11. Check for NGINX + PHP-FPM Misconfigurations

• Goal: Bypass .php location blocks or pass .php files to the interpreter from unintended locations.

• Payload:

  • GET /uploads/test.jpg/evil.php

  • GET /uploads/test.phar

• Check: If the server executes your code or serves the raw source, configuration might be insecure.

12. Insecure FastCGI (FPM) Settings

• Goal: Directly access php-fpm listening sockets from the outside.

• Method:

  • Scan for open ports (e.g., 9000) or misconfigured server blocks that allow fastcgi_pass 127.0.0.1:9000;.

  • Attempt an FCGI request directly to see if you can bypass NGINX-level controls.

13. Look for Old or Unpatched CVEs

• Goal: Exploit known vulnerabilities that remain unpatched.

• Examples:

  • CVE-2021-23017 (1-byte memory overwrite in NGINX resolver).

  • CVE-2019-20372 (HTTP/2 stack buffer overflow in older NGINX).

• Method: Confirm version and compare with known CVEs. Test PoCs if available.

14. TLS/SSL Misconfigurations

• Goal: Identify weak ciphers, outdated protocols, or misconfig leading to MITM vulnerabilities.

• Method:

  • Use sslscan, testssl.sh, or nmap --script ssl-enum-ciphers to see which ciphers and protocols are enabled.

  • Flag outdated TLS versions (TLS 1.0, 1.1) or known weak ciphers (RC4, DES).

15. HTTP Method Tampering

• Goal: Check if TRACE, TRACK, PUT, or DELETE are enabled or incorrectly allowed.

• Method:

  • curl -X TRACE https://target/

  • curl -X PUT https://target/uploaded_file.txt -d "test content"

• Check: If these methods succeed, potential vulnerabilities exist.

16. Check Gzip/Compression Issues (BREACH/CRIME)

• Goal: Evaluate NGINX’s compression settings that might allow partial plaintext extraction in TLS.

• Method:

  • Look at server headers or configuration. Attempt traffic analysis if feasible in a controlled environment.

• Check: If compression is enabled and unmitigated, the site might be susceptible to related side-channel attacks.

17. Cookie Security Flags

• Goal: Identify missing HttpOnly, Secure, or SameSite flags on session cookies.

• Method:

  • Observe Set-Cookie headers in HTTP responses.

• Check: If flags are missing, escalate with XSS or sniffing to hijack sessions.

18. Access Logs or Error Logs Disclosure

• Goal: Detect if logs are exposed in a world-readable location.

• Method:

  • Attempt to access paths like /logs/ or check for error_log or access_log references in the config that might leak.

• Check: Confirm if logs can be downloaded.

19. NGINX Status Page Exposure

• Goal: ngx_http_stub_status_module misconfiguration can reveal internal stats or server info.

• Method:

  • Test common endpoints: /nginx_status, /status.

• Check: If the page is accessible externally without auth, it’s a finding.

20. WebDAV Misconfiguration

• Goal: If WebDAV is enabled by NGINX modules or proxies, it can allow file upload or manipulation.

• Method:

  • Use cadaver or curl -X OPTIONS <target> to see if WebDAV methods are allowed.

  • Attempt file upload with curl -T.

21. Testing Common Admin Interfaces

• Goal: Some NGINX-based panels or control interfaces are left in default states.

• Method:

  • Check for server: nginx in subdomains, default credentials like admin:admin, or known panels like Nginx Proxy Manager.

• Check: If discovered, attempt typical credential combos.

22. HTTP/2 Specific Attacks

• Goal: Identify parsing or DoS vulnerabilities in NGINX’s HTTP/2 implementation.

• Method:

  • Use specialized fuzzers or tools (e.g., h2spec, nghttp) to send malformed frames.

• Check: If the server crashes or misbehaves, it’s vulnerable.

23. Cache-Control / Caching Misconfig

• Goal: Access data intended for other users, or store sensitive data in caches.

• Method:

  • Check Cache-Control, Expires, and Pragma headers.

  • Attempt replay of cached endpoints with session tokens.

24. HTTP to HTTPS Redirection Logic

• Goal: See if partial content is served over HTTP or if redirects are incomplete, leading to MITM.

• Method:

  • Inspect site with a plugin or your proxy to detect mixed content or unencrypted endpoints.

• Check: If sensitive endpoints are not forced to HTTPS, escalate.

25. Missing Security Headers

• Goal: Exploit the lack of headers that mitigate XSS, clickjacking, MIME sniffing, etc.

• Method:

  • Inspect the HTTP responses for:

    • X-Frame-Options

    • X-Content-Type-Options

    • Strict-Transport-Security

    • Content-Security-Policy

• Check: If absent, potential vulnerabilities open up.

26. Check for File Upload Functionality

• Goal: Exploit insecure file upload that may allow remote code execution or path traversal.

• Method:

  • Upload test payloads like .php, .php3, .phtml, or even .php;.jpg.

• Check: If NGINX is incorrectly configured (especially try_files or fastcgi_pass), an uploaded file could be executed.

27. Misconfigured try_files Directive

• Goal: Bypass file extension checks or rewrite rules that incorrectly pass requests to the backend.

• Method:

  • If try_files is used incorrectly, you might access unintended files or scripts.

  • Payload example: GET /some-existing-file%00.php

• Check: Look for path or extension bypass.

28. HTTP Header Injection (XSS/CRLF)

• Goal: Inject additional headers or HTML into the response.

• Payload:

  • GET /%0D%0AHeader: InjectedHeaderValue

• Check: If the server merges your header into the response, you can create custom responses or possibly XSS.

29. Check Reverse Proxy Bypass

• Goal: Some NGINX deployments reverse-proxy to an internal service that uses different host/path constraints.

• Method:

  • Try referencing internal endpoints: /internal_endpoint or using weird host rewrites.

• Check: If you can bypass authentication by going directly to internal paths.

30. Look for Debug/Verbose Errors

• Goal: See if NGINX is in debug or verbose mode that reveals sensitive data (source code paths, environment variables).

• Method:

  • Submit crafted requests causing 500/404 to see if the error pages show internal file paths or stack traces.

31. Check Rate-Limiting or DoS Protections

• Goal: Identify if NGINX limit_req or limit_conn modules are absent or misconfigured, enabling brute force or DoS.

• Method:

  • Attempt multiple rapid requests or dictionary attacks; see if the server throttles or blocks IPs.

32. Virtual Host Enumeration

• Goal: Discover hidden vhosts that might lead to additional domains or admin panels.

• Method:

  • Use DNS enumeration (subbrute, amass) or try vhost scanning (ffuf -H "Host: FUZZ.target" -u https://target).

• Check: Additional subdomains or hostnames might reveal new admin endpoints or test environments.

33. Check for Remote Code Execution via CGI

• Goal: If NGINX passes certain scripts to a CGI or a legacy backend, exploit vulnerabilities in the interpreter.

• Method:

  • Attempt shell injection in parameters or file uploads if a CGI is discovered (.cgi, .sh, .pl).

• Check: If you get a shell or see command output in responses, RCE is possible.

34. Inspect Custom Modules or 3rd Party Modules

• Goal: 3rd-party NGINX modules (e.g., for WAF, caching, fancy indexing) might have vulnerabilities.

• Method:

  • Check the presence of modules via curl -I or by analyzing the server’s response or config.

  • Research known bugs in modules like ngx_pagespeed, ModSecurity for NGINX, ngx_lua, etc.

35. SSRF via Lua NGINX Modules

• Goal: Some sites use ngx_lua to implement custom logic, which could open SSRF or RCE if not sandboxed.

• Method:

  • Look for endpoints that allow user input to pass directly to a Lua function that fetches remote resources.

• Payload:

  • GET /lua-endpoint?fetch_url=http://127.0.0.1:8080/admin

• Check: If it returns internal content.

36. YAML or JSON Configuration Injection

• Goal: Certain setups parse YAML or JSON from user input. If integrated with NGINX’s lua, injection is possible.

• Method:

  • Try uploading or sending a payload with malicious placeholders, e.g. !ruby/object.

• Check: If the backend improperly deserializes, leading to code execution or reading sensitive data.

37. Check for WebSocket Proxy Issues

• Goal: Identify if the upgrade from HTTP to WebSocket is restricted or can be abused.

• Method:

  • Use Sec-WebSocket-Key, Sec-WebSocket-Protocol headers, attempt abnormal upgrades or pass restricted data.

• Check: Could lead to SSRF or injection if not validated.

38. CRLF in WebSocket Upgrades

• Goal: Similar to HTTP header injection, might cause message injection or header splitting in proxied WebSocket connections.

• Method:

  • Send an upgrade request with %0d%0a in the path or other fields to see how it’s handled.

39. Brute Force Basic or Digest Auth

• Goal: If NGINX is configured to use basic auth, attempt standard dictionary credentials.

• Method:

  • Tools like hydra or medusa with -m /protected_path.

• Check: If no lockout or rate-limiting, you can guess credentials quickly.

40. Test for Slowloris (Low Bandwidth DoS)

• Goal: See if the server can handle partial HTTP requests or if it ties up threads.

• Method:

  • Use tools like slowhttptest to keep connections open with partial headers.

• Check: If server performance is impacted severely, DoS condition is possible.

41. Malicious Chunked Encoding DoS

• Goal: Crash or degrade performance by sending incomplete or malformed chunk lengths.

• Method:

  • nc target 80, manually craft chunked messages with large or negative chunk sizes.

• Check: If the server stops responding or returns errors.

42. Exploit Missing HSTS

• Goal: Force a downgrade to HTTP to sniff credentials or inject malicious responses.

• Method:

  • If Strict-Transport-Security is not set, see if you can connect over HTTP or block redirections.

• Check: Potential for MITM attacks.

43. Evaluate CSP Bypass with NGINX Configuration

• Goal: If the site sets a CSP header via NGINX but whitelists certain domains (e.g., *.example.com), try subdomain takeovers or injection from those subdomains.

• Method:

  • Check CSP policies, attempt to serve malicious JS from whitelisted domain or subdomain you control.

44. Proxying Web Sockets to Internal Services

• Goal: If NGINX proxies WebSockets to an internal service, you can attempt direct commands or data injection.

• Method:

  • Connect with a WebSocket client to wss://target/, then see if you can pass commands to internal endpoints.

45. Subdomain or Path-based Bypass

• Goal: Bypass domain-level security by using an alternate subdomain or path that is misconfigured in NGINX conf.

• Method:

  • If server_name only matches example.com but api.example.com is not protected, test each vhost separately.

46. Inspect Reverse Proxy “X-Real-IP” or “X-Forwarded-For” Issues

• Goal: Fake your IP address to bypass IP-based security or logging.

• Payload:

  • GET / HTTP/1.1 Host: target X-Forwarded-For: 127.0.0.1

• Check: If the application trusts this header for admin access or logging, you have a bypass.

47. Bypass Security with Large Request Headers

• Goal: Some WAF or front-end checks fail with extremely large headers (buffer overflow or partial bypass).

• Method:

  • Send requests with huge custom headers or very large cookie values.

• Check: If the server crashes or the WAF/filters skip inspection.

48. NGINX + Docker Misconfiguration

• Goal: If NGINX is in a Docker container, see if it’s mapped incorrectly or if Docker socket is exposed.

• Method:

  • Scan for open Docker APIs (port 2375) or volumes that reveal Dockerfiles.

  • If you can access /var/run/docker.sock, you might escalate.

49. Bypass Restrictive location with Trailing Slash

• Goal: Some NGINX rules are only enforced if there’s no trailing slash or a slash is present.

• Method:

  • If location = /admin is protected, try requests like /admin/, /admin/., /admin?.

• Check: If the server incorrectly interprets the route, you might bypass authentication.

50. Exploit Overly Permissive CORS

• Goal: If Access-Control-Allow-Origin: * or dynamic whitelisting is misconfigured, you can steal data from cross-origin contexts.

• Method:

  • Use a malicious domain to load scripts making requests to the target; check the response for data exposure.

• Check: If Access-Control-Allow-Credentials: true is also set, you can hijack authenticated sessions.

---

Wrap-Up / Recommendations

1. Keep NGINX Updated: Always apply security patches promptly to address known CVEs.

2. Harden Configuration: Lock down proxy_pass, remove or protect status endpoints, disable insecure HTTP methods, and enforce strong TLS configurations.

3. Enable Logging/Auditing: Monitor logs for suspicious activity, especially internal access or malformed requests.

4. Test Regularly: Continuous scanning and penetration testing help catch newly introduced misconfigurations or vulnerabilities.

Use this checklist responsibly in authorized environments to improve the security of NGINX-based servers rather than exploit them maliciously.

---

So, what are your thoughts?

---