Web - Port 80,443

Ports 80 and 443 are the primary ports for web traffic, with port 80 handling unencrypted HTTP traffic and port 443 managing encrypted HTTPS traffic.

Support VeryLazyTech 🎉

• Become VeryLazyTech member! 🎁

• Follow us on Twitter @VeryLazyTech, Github @VeryLazyTech, and Medium @VeryLazyTech.

• Visit our shop for e-books and courses. 📚

• Support us and buy me a coffee. ☕

Basic Info

Ports 80 and 443 are the primary ports for web traffic, with port 80 handling unencrypted HTTP traffic and port 443 managing encrypted HTTPS traffic. Both are crucial to understand in web penetration testing, as they form the backbone of most web applications and are frequently targeted for vulnerabilities. Let’s explore each one in detail.

---

Port 80 - HTTP (HyperText Transfer Protocol)

• Overview: Port 80 is the default port for HTTP, a protocol used for transmitting web pages from servers to browsers. HTTP is stateless and unencrypted, which means all data sent over HTTP is visible in plaintext, making it an easy target for attackers.

• Common Vulnerabilities:

  • Open Redirects: Maliciously redirecting users to a different website.

  • Insecure Session Handling: HTTP lacks encryption, leaving session cookies and other sensitive data vulnerable to interception.

  • Sensitive Information Disclosure: HTTP can expose headers, server information, and response content that attackers can use for further exploits.

---

Port 443 - HTTPS (HTTP Secure)

• Overview: Port 443 is the default for HTTPS, which is HTTP over SSL/TLS. HTTPS encrypts data between the client and server, ensuring confidentiality and integrity, but it’s not immune to attacks.

• Common Vulnerabilities:

  • SSL/TLS Misconfigurations: Weak cipher suites, expired certificates, or improper SSL configurations can lead to attacks such as SSL stripping or BEAST.

  • Mixed Content: When HTTPS pages load HTTP content, attackers can potentially intercept or manipulate that content.

  • Certificate Issues: Self-signed, expired, or mismatched certificates weaken security by compromising trust.

---

Understanding HTTP Methods

• Common Methods: GET, POST, PUT, DELETE, OPTIONS

• Risks: Some methods (like PUT and DELETE) allow file uploads or deletions. Misconfigurations that allow these methods on sensitive endpoints expose the server to data tampering.

• Practical Testing:

  • Use curl -X OPTIONS http://<target-ip> to check available methods. If PUT or DELETE is enabled, this can indicate a potential vulnerability.

---

Attack Vectors on Ports 80 and 443

• Cross-Site Scripting (XSS): Injecting malicious scripts into web pages, often exploiting unsanitized input fields.

• SQL Injection: Sending malicious SQL queries through vulnerable input fields to access database content.

• Directory Traversal: Manipulating URL paths to access restricted directories and files.

• Man-in-the-Middle (MitM) Attacks: Especially relevant on port 80, where attackers can intercept unencrypted HTTP traffic.

---

Tools for Web Pentesting on Ports 80 and 443

• Nmap: Scanning for open ports and service versions.

• Burp Suite: Intercepting and analyzing HTTP/HTTPS traffic.

• Nikto: Scanning for web server vulnerabilities.

• OWASP ZAP: Automated and manual testing for web app vulnerabilities.

• SSL Labs: Testing the strength of SSL/TLS configurations.

---

Web API Guidance for Penetration Testing

APIs are an essential part of modern web applications, providing programmatic access to data and services over HTTP or HTTPS. While they enable seamless integration and data exchange, APIs also open up potential attack vectors, especially on commonly targeted ports like 80 (HTTP) and 443 (HTTPS).

1. Mapping the API Endpoints

• Tools:

  • Burp Suite: Capture and catalog requests as you explore the API.

  • OWASP ZAP: Use its Spider tool to map endpoints.

  • Postman: Manually query endpoints to verify responses.

• Example Command: Use cURL to test endpoints and methods manually.

  curl -X GET http://<api-url>/endpoint

• Wordlists for Endpoint Discovery:

  • Common Wordlists: Use lists such as api-endpoints.txt from repositories like SecLists to guess endpoint names.

  • Example Command with wfuzz:

    wfuzz -c -z file,/path/to/api-endpoints.txt --hc 404 http://<api-url>/FUZZ

2. Analyzing API Documentation

• Tool: Swagger UI or Postman: Compare documented endpoints with actual functionality, looking for discrepancies or undocumented features.

• Example: Use Postman to request each documented endpoint and cross-check responses.

• Documentation-Based Wordlists:

  • Check for endpoints often used by APIs but sometimes undocumented, such as /admin, /v2/, or /private.

3. Testing Authentication Mechanisms

• Tools:

  • JWT.io: For inspecting JSON Web Tokens (JWTs).

  • Burp Suite: Allows token manipulation and session hijacking tests.

  • AuthMatrix (Burp Extension): Automates authorization tests.

• Example Commands:

  • Testing JWTs: Use jwt-tool to analyze and manipulate JWT tokens.

    jwt_tool.py <JWT_TOKEN> -A <ATTACK_TYPE>

  • Brute-forcing Tokens: Use Hydra or Patator to brute-force token-based authentication.

    hydra -L usernames.txt -P passwords.txt -s 80 http-post-form "/api/login:username=^USER^&password=^PASS^:F=Invalid"

• Wordlists:

  • Use token-related wordlists like rockyou.txt for brute-forcing weak passwords.

  • Default Token Secrets: Some APIs use default secrets for JWT signing (e.g., default, password, etc.). Try lists like jwt_secrets.txt from SecLists.

4. Validating Input Fields for Injection Attacks

• Tools:

  • SQLmap: For SQL injection testing.

  • Burp Suite Intruder: Injects custom payloads into requests.

  • NoSQLMap: Tests NoSQL injections, particularly in MongoDB-based APIs.

• Example Commands:

  • SQL Injection with SQLmap:

    sqlmap -u "http://<api-url>/endpoint?param=value" --batch

  • Testing JSON Injection: Use curl with JSON payloads to check for injection points.

    curl -X POST http://<api-url>/endpoint -H "Content-Type: application/json" -d '{"username":"admin' OR 1=1--","password":"any"}'

• Injection Payload Wordlists:

  • SQL Injection: fuzzing/SQLi.txt from SecLists.

  • JSON/NoSQL Injection: nosql_payloads.txt for MongoDB-based injections.

5. Testing for Rate Limiting

• Tools:

  • OWASP ZAP: The automated scanner can flood requests to check for rate limiting.

  • Burp Suite Repeater: Send multiple requests manually to observe rate limits.

  • ffuf: Command-line tool for fast and controlled API requests.

• Example Command:

  • Flooding with ffuf:

    ffuf -u http://<api-url>/endpoint -c -w /path/to/wordlist.txt -H "Authorization: Bearer <TOKEN>"

  • Example with Curl and a Loop: Use Bash to simulate a rapid burst of requests.

    for i in {1..100}; do curl -X GET http://<api-url>/endpoint; done

• Wordlists for Rate Limiting:

  • Use a simple wordlist to flood the server, e.g., a list with repeated GET or POST requests.

6. Examining Response Codes and Data Exposures

• Tools:

  • Burp Suite: Capture and analyze HTTP status codes and response headers.

  • HTTPie: A command-line tool to inspect response headers and status codes more easily.

• Example Command:

  • Checking for 400/500 Error Codes with Curl:

    curl -X POST http://<api-url>/endpoint -d '{"param": "<test_payload>"}'

  • HTTPie: Makes it easy to read response codes and data.

    http GET http://<api-url>/endpoint

• Wordlists for Data Exposure Testing:

  • Common File and Path Wordlists: directory-list-2.3-medium.txt from SecLists, which can help find unprotected endpoints like /backup or /config.

7. Broken Object-Level Authorization (BOLA)

• Tools:

  • Postman: Manually test object-level access using different user tokens.

  • Burp Suite: Create different user sessions and attempt to access restricted data.

• Example Command:

  • Testing Object Access with Curl:

    curl -X GET http://<api-url>/user/123 -H "Authorization: Bearer <TOKEN_1>"

    Then, repeat with a different token to check if one user’s token can access another user’s data.

• Wordlists for Parameter Tampering:

  • Parameter Wordlists: parameter_names.txt from SecLists can help test common parameter names in BOLA tests (e.g., id, user_id, account_id).

8. Advanced Tips and Commands

• Certificate Testing:

  • SSL Labs: Use SSL Labs' SSL Test for comprehensive SSL/TLS checks.

  • Nmap SSL Scan:

    nmap --script ssl-enum-ciphers -p 443 <target-ip>

• Automated API Fuzzing:

  • ffuf and Wfuzz are both excellent tools for fuzzing with controlled requests.

  • Example:

    ffuf -u http://<api-url>/FUZZ -w /path/to/api-endpoints.txt -H "Authorization: Bearer <TOKEN>"

---

Methodology Summary: API/Web Penetration Testing for a Targeted Domain or Subdomain

In this methodology, the focus is solely on testing a single domain or subdomain within the defined scope. Each discovered domain, subdomain, or IP address with a web server will be individually tested, ensuring that all vulnerabilities are identified and addressed. This step-by-step approach allows for a systematic, comprehensive assessment of each component within the scope.

Step 1: Initial Reconnaissance

• Objective: Identify subdomains, endpoints, and open ports.

• Tools: Sublist3r, Amass, MassDNS, Nmap

• Commands:

  • Discover subdomains:

    sublist3r -d target.com

  • Enumerate open ports:

    nmap -p 80,443 -sV target.com

• Outcome: Gather a list of all web servers (domains and subdomains) to be tested.

Step 2: Endpoint Enumeration

• Objective: Map out all accessible endpoints on each subdomain.

• Tools: FFuF, Dirsearch, Burp Suite

• Commands:

  • Directory Brute-forcing:

    ffuf -u http://target.com/FUZZ -w /path/to/wordlist.txt

• Outcome: Obtain a list of accessible directories and API endpoints.

Step 3: Analyzing Authentication Mechanisms

• Objective: Evaluate authentication and authorization methods.

• Tools: Postman, JWT.io, Burp Suite

• Common issues:

  • Token Replay Attacks

  • Lack of Token Expiration

  • Insufficient Token Validation (Signature Verification)

  • Weak or No Signing Algorithm in JWT

  • Token Manipulation (Role Tampering or Privilege Escalation)

  • Missing Audience (aud) and Issuer (iss) Validation

  • Lack of Secure Storage for Tokens (LocalStorage Vulnerability)

  • Insecure Refresh Token Implementation

  • Missing or Weak Anti-CSRF Protections

  • Missing or Inadequate Rate Limiting

  • Lack of IP Binding or Device Binding

  • Exposed Tokens in URL Parameters

  • Token Leakage via Logs or Debug Information

  • Use of Predictable or Weak Secrets

  • Failure to Revoke Tokens on Logout

  • Lack of Multi-Factor Authentication (MFA)

  • Overly Permissive Scopes in OAuth Tokens

  • Insecure Token Transport (Missing HTTPS)

  • Inconsistent Token Expiry Between Access and Refresh Tokens

  • No Mechanism for Token Rotation

• Outcome: Identify weaknesses in authentication that could allow unauthorized access.

Step 4: Testing for Injection Vulnerabilities

• Objective: Test for SQL, command, and JSON injections.

• Tools: SQLmap, NoSQLMap, Burp Suite Intruder

• Commands:

  • SQL Injection:

    sqlmap -u "http://target.com/endpoint?param=value" --batch

• Outcome: Discover injection vulnerabilities that could lead to unauthorized data access.

Step 5: Rate Limiting and DoS Testing

• Objective: Check for rate limiting and potential for Denial of Service (DoS).

• Tools: ffuf, curl

• Commands:

  • Rapid request flood:

    for i in {1..100}; do curl -X GET http://target.com/endpoint; done

• Outcome: Determine if rate limits are in place and if they can be bypassed.

Step 6: Assessing Authorization and Access Controls (BOLA)

• Objective: Test for broken object-level authorization (BOLA).

• Tools: Burp Suite, Postman

1. Identify Endpoints with Object Identifiers

• Look for endpoints that reference unique object IDs, such as /api/user/12345/profile or /api/order/67890.

• Common object identifiers include user IDs, order numbers, document IDs, etc., and can often be found in URL paths, query parameters, or request bodies.

2. Gather User Tokens for Different Roles

• Standard User: Authenticate as a regular user and capture the token or session cookie.

• Admin or Higher-Privileged User: If possible, authenticate as an admin or elevated user for comparison.

• Lower-Privileged User: For multi-role applications, use tokens from users with lower permissions.

3. Test Unauthorized Access Attempts

• Modify Object IDs: Change the object ID to one that belongs to another user or a resource not owned by the current user.

  • Example: If the original request is /api/order/12345, modify it to /api/order/67890.

• Send Request with Original Token: Using Burp Suite Repeater or Postman, send the request with the modified object ID while keeping the same token or session identifier.

4. Observe Responses for Authorization Failures

• Expected Response: The server should return 403 Forbidden or 404 Not Found if access is restricted correctly.

• Vulnerable Response: If you receive 200 OK or a valid data response for the unauthorized object, there is likely a BOLA vulnerability.

5. Test Various Object Types and Permissions

• User Profiles: Try accessing other users’ profiles using different user tokens.

• Private Data: Check for access to private documents or files that should only be accessible to the owner.

• Administrative Endpoints: Test for access to admin-only resources or settings with non-admin tokens.

• Example Commands in Burp Repeater:

  GET /api/user/12345/profile HTTP/1.1
  Authorization: Bearer <Regular_User_Token>

  Modify to:

  GET /api/user/67890/profile HTTP/1.1
  Authorization: Bearer <Regular_User_Token>

6. Automate with Intruder for Large ID Ranges

• Setup Intruder in Burp to automate ID testing by setting object ID positions.

• Payload Position: Set the object ID as the variable position in Intruder.

• Wordlist: Use a wordlist of possible object IDs or iterate through likely ID values.

• Outcome: Find misconfigured authorization that may expose sensitive data.

Step 7: Response Validation and Data Exposure

• Objective: Validate HTTP response codes and inspect data returned in responses.

• Tools: HTTPie, Burp Suite

• Commands:

  • Inspect responses for error codes and data leaks:

    http GET http://target.com/endpoint

• Outcome: Identify improper data handling, such as verbose error messages or sensitive data leakage.

---

Server Version

Check if there are known vulnerabilities for the server version that is running. The HTTP headers and cookies of the response could be very useful to identify the technologies and/or version being used.

1. Identify the Server Version

HTTP Headers and Cookies

• Inspect the response headers for any information related to the server version.

  • Common headers: Server, X-Powered-By, X-Backend, etc.

  • Example:

    HTTP/1.1 200 OK
    Server: Apache/2.4.29 (Ubuntu)
    X-Powered-By: PHP/7.2.1

• In the example above, you can see that the server is running Apache 2.4.29, and PHP 7.2.1.

• Cookies might also reveal details about the underlying technology, such as PHPSESSID or .ASP.NET_SessionId.

Nmap Scan for Server Version

• Nmap is an effective tool for scanning the target server and identifying its version.

  • nmap -sV <target_ip>

  • The -sV flag forces Nmap to attempt to identify the version of services running on open ports.

  • Example Output:

    PORT     STATE SERVICE    VERSION
    80/tcp   open  http       Apache httpd 2.4.29 (Ubuntu)
    443/tcp  open  ssl/http   Apache httpd 2.4.29 (Ubuntu)

• Nmap will provide detailed information about the web server software, including the version, making it easy to correlate with vulnerabilities.

Web Technology Fingerprinting Tools

• WhatWeb: Detects and reports web technologies, including server versions.

  • whatweb <target_url>

  • Example Output:

    http://target.com [Apache/2.4.29 (Ubuntu)] [PHP/7.2.1]

• WebTech: Another tool for detecting technologies on a web server.

  • webtech <target_url>

• BuiltWith: A web-based tool that provides insights into the technologies behind a website, including server versions.

  • Visit: https://builtwith.com

  • Simply enter the URL of the target website to view detailed information about the technologies it uses.

2. Cross-Reference with Known Vulnerabilities

• Search for Known Vulnerabilities: After identifying the version of the server and associated technologies, cross-reference with publicly available vulnerability databases such as:

  • CVE Database: https://cve.mitre.org

  • NVD (National Vulnerability Database): https://nvlpubs.nist.gov/nistpubs/

  • Exploit-DB: https://www.exploit-db.com

  • Security Advisories: Check for security advisories from vendors or communities related to the server version identified (e.g., Apache, Nginx, PHP, etc.).

• Search Example: If the server is identified as Apache 2.4.29, visit the CVE database and search for vulnerabilities related to Apache 2.4.29:

  • CVE Example: Apache 2.4.29 vulnerability

  • If the search returns results like CVE-2017-15715, you can assess whether the vulnerability applies to the target system.

3. Automated Tools for Vulnerability Scanning

• Nessus: A comprehensive vulnerability scanner that can detect known vulnerabilities based on the server version and other configurations.

  • Launch Nessus and run a scan against the target IP or URL. The tool will provide detailed vulnerability reports including CVEs associated with the server software version.

• OpenVAS: An open-source alternative to Nessus that can detect vulnerabilities related to server software versions.

• Nikto: A web scanner that identifies potential security issues, including outdated server versions.

  • nikto -h <target_url>

---

To check if a web application is protected by a Web Application Firewall (WAF), you need to observe certain characteristics and use various tools that can help identify the presence of WAFs. Here’s a detailed methodology to detect and test for WAFs:

---

Check for WAF

1. Manually Check for WAF Indicators

Look for HTTP Response Headers

• WAFs often add unique headers or modify response headers that can reveal their presence.

• Common WAF-specific headers include:

  • X-Secured-By: This header indicates the presence of a security solution like a WAF.

  • X-WAF: Another header that might directly indicate a WAF.

  • Server: Some WAFs modify this header to hide the true web server.

  • Example Headers:

    HTTP/1.1 200 OK
    X-Secured-By: Cloudflare
    X-Content-Type-Options: nosniff
    Server: nginx

Look for Error Messages or Blocking Responses

• When trying to send a potentially malicious request, a WAF might block or filter it and return a custom error message indicating the presence of a WAF.

• Example of a WAF blocking message:

  403 Forbidden: Request blocked by Web Application Firewall

• Some WAFs may return error messages with clues about their identity, such as "Cloudflare Ray ID" or "ModSecurity."

2. Automated Tools to Detect WAFs

Wappalyzer

• Wappalyzer is a browser extension or online tool that can help detect technologies used on a website, including WAFs.

• Visit: https://www.wappalyzer.com

WhatWeb

• WhatWeb can identify a variety of web technologies, including WAFs.

• whatweb <target_url>

• Example Output:

  http://example.com [Cloudflare] [Apache/2.4.29 (Ubuntu)] [PHP/7.2.1]

WAFW00F

• WAFW00F is a dedicated tool to identify WAFs and their type.

• Command:

  wafw00f <target_url>

• Example Output:

  Detected WAF: Cloudflare (Cloudflare WAF)

Nmap Script for WAF Detection

• Nmap includes scripts for detecting WAFs. The http-waf-detect script can be used to identify WAFs.

• nmap --script=http-waf-detect -p 80,443 <target_ip>

• Example Output:

  80/tcp  open  http    Apache httpd 2.4.29 (Ubuntu)
  | http-waf-detect:
  |   WAF Detected: Cloudflare

3. Check for Common WAFs and Their Responses

Common WAFs and how to identify them:

• Cloudflare:

  • Checks for challenges like CAPTCHA, JavaScript challenges, or HTTP response headers like cf-ray.

  • Example Response Header:

    cf-ray: 55b6f23fb7794e44-SFO

• ModSecurity:

  • A popular open-source WAF, often integrated with Apache, Nginx, and other web servers.

  • May return specific error messages such as "ModSecurity Action" or a custom error page indicating that a rule was triggered.

• Sucuri WAF:

  • This is a cloud-based WAF, and it can add headers like X-Sucuri-ID.

  • Example Response Header:

    X-Sucuri-ID: 12345

• AWS WAF:

  • AWS WAF often uses specific error responses or headers that identify it.

  • Example Response Header:

    X-Amzn-Trace-Id: Root=1-5f8d3e64-72a1b1b37b2fe56e0c62b9e0

4. Manually Trigger WAF Responses

If you're unsure whether a WAF is active, try triggering common WAF detection techniques, such as:

Sending SQL Injection Test Payloads

• Attempting basic SQLi payloads like:

  ' OR 1=1 --

• If a WAF blocks it, you may see a 403 Forbidden error or a message such as "Request Blocked by Security."

Cross-Site Scripting (XSS) Test Payloads

• Try sending an XSS payload like:

  <script>alert('XSS')</script>

• If blocked, the WAF might return an error indicating that the request was filtered.

Command Injection Test Payloads

• Use command injection payloads like:

  ; ls

• A WAF may detect and block this request, returning an error message or a 403 response.

5. Use Specific Payloads for WAF Testing

You can also try known WAF bypass techniques, such as:

Encoding Payloads:

• Some WAFs might block traditional payloads but allow URL-encoded or double-encoded payloads. Example:

  <script>alert('XSS')</script> becomes %3Cscript%3Ealert('XSS')%3C%2Fscript%3E

Use of HTTP Methods:

• Some WAFs are configured to block only certain HTTP methods like POST or PUT. Try using alternative methods like HEAD or OPTIONS to see if the WAF blocks those methods as well.

6. Consider WAF Fingerprinting Services

• BuiltWith (mentioned earlier) can also help determine if a website is using a WAF, by showing detailed information on security technologies and services used by the site.

• ThreatPinch: Another commercial tool that identifies WAFs and their specific configurations.

---

Source code review

Source code review is a critical process in web penetration testing that involves thoroughly examining the source code of a web application to identify vulnerabilities, weaknesses, and potential security flaws before the application is deployed. The review focuses on several key areas. First, authentication and authorization mechanisms must be scrutinized to ensure they are securely implemented, using proper hashing algorithms (like bcrypt or Argon2) and access controls. It is essential to check for issues such as Insecure Direct Object References (IDOR) or Broken Object Level Authorization (BOLA), and improper session management.

Another key aspect is input validation, where the source code should be inspected to ensure all user inputs are properly sanitized and validated, protecting the application from common attack vectors like SQL injection, Cross-Site Scripting (XSS), and command injection. Sensitive data exposure must be closely reviewed, ensuring that sensitive information, such as passwords and API keys, is properly encrypted both in transit and at rest. This means using strong encryption algorithms and not storing passwords in plain text.

Session management is another vital area, and the code must be checked for secure session handling practices, including the proper use of session tokens, expiry times, and ensuring that session IDs are unpredictable to prevent attacks like session fixation or hijacking. Cross-Site Request Forgery (CSRF) protection should also be checked to ensure that sensitive state-changing requests are properly protected with anti-CSRF tokens.

Additionally, error handling should be examined to prevent the application from exposing sensitive information in error messages, such as database details or stack traces. The review should also focus on API security, making sure that all endpoints are properly authenticated, authorized, and have sufficient protection against abuse, such as rate limiting and input validation.

Finally, third-party libraries and dependencies should be audited to ensure that no outdated or vulnerable libraries are being used. Tools like OWASP Dependency-Check or Retire.js can help identify known vulnerabilities in third-party code. While using static application security testing (SAST) tools such as Checkmarx, SonarQube, and Fortify can automate much of the vulnerability identification, manual review of critical files, such as authentication, payment processing, and user data handling code, is essential. This combination of automated and manual review processes helps ensure that the application is secure and ready for production.

---

Automatic scanners

• Burp Suite

  • Comprehensive web application security testing, including active and passive scanning for vulnerabilities such as SQL Injection, XSS, and more.

  • Use the graphical interface to start a scan, but here's an example of how to run Burp Suite in headless mode:

    java -jar burpsuite_community_v1.7.36.jar --headless --project-file=project.burp

• OWASP ZAP

  • Automated vulnerability scanning, including active and passive testing for common web vulnerabilities like XSS, SQL injection, and CSRF.

  • Start an automated scan:

    zap.sh -cmd -quickurl http://example.com

• Nikto

  • Identifying common web server vulnerabilities such as outdated software, misconfigurations, and server issues.

  nikto -h http://example.com

• Wapiti

  • Automated fuzz testing to find vulnerabilities like XSS, SQL injection, and file inclusion issues.

  wapiti -u http://example.com -p "GET,POST"

• Postman (for API testing)

  • Automated testing and validating API endpoints for security issues like authorization flaws, rate limiting, and injection vulnerabilities.

  • Use Postman’s GUI to set up collections, but for command-line testing, you can use Newman:

    newman run collection.json

• OWASP Dependency-Check

  • Identifying known vulnerabilities in third-party libraries and dependencies used in web applications.

  dependency-check --project example --scan ./path/to/your/project

• Acunetix

  • Automated, fast vulnerability scanning with a focus on SQL injection, XSS, and other OWASP Top 10 issues.

  • Use Acunetix’s web interface for scanning. Command-line interface:

    acunetix-cli scan start --url http://example.com

• Retire.js

  • Scanning JavaScript libraries to detect known vulnerabilities.

  retire --path /path/to/your/javascript/project

---

CMS scanner

CMS (Content Management System) scanners are specialized tools designed to identify vulnerabilities in web applications powered by popular CMS platforms like WordPress, Joomla, Drupal, and others. These scanners automate the detection of CMS-specific issues such as outdated plugins, themes, default configurations, and known vulnerabilities.

1. WPScan (for WordPress)

   • Detecting vulnerabilities in WordPress installations, including plugins, themes, and core files.

   wpscan --url http://example.com --enumerate p,t,u

   • --enumerate p for plugins

   • --enumerate t for themes

   • --enumerate u for users

2. JoomScan (for Joomla)

   • Detecting vulnerabilities in Joomla websites, including outdated components and configurations.

   joomscan -u http://example.com

3. Droopescan (for Drupal)

   • Finding vulnerabilities in Drupal installations, including modules, themes, and core versions.

   droopescan scan drupal -u http://example.com

4. WhatWeb (for multiple CMS platforms)

   • Identifying the CMS, version, and associated technologies used on a website.

   whatweb http://example.com

5. CMSmap (for multiple CMS platforms)

   • Identifying vulnerabilities in WordPress, Joomla, Drupal, and other CMS platforms.

   python cmsmap.py -u http://example.com

6. WPScan API (for automated scanning in CI/CD pipelines for WordPress)

   • Automating vulnerability scans for WordPress websites in continuous integration/continuous deployment environments.

   wpscan --url http://example.com --api-token YOUR_API_KEY --enumerate p,t,u

7. CMS Vulnerability Scanner (general)

   • Scanning a variety of CMS platforms (e.g., WordPress, Joomla, Drupal) for common vulnerabilities.

   cms-scan --url http://example.com

---

Step-by-step Web Application Discovery

1. Initial Checks

• Default Pages:

  • /robots.txt: Check for sensitive URLs or paths that might be hidden for search engines but still accessible.

  • /sitemap.xml: Look for pages that should not be exposed to the public.

  • /crossdomain.xml and /clientaccesspolicy.xml: These can expose cross-domain access or allow specific requests from other domains.

  • /.well-known/: This folder can contain various sensitive information, such as security configurations or API keys.

• Comments in Pages:

  • Review both main and secondary pages for comments. Attackers sometimes leave sensitive information in comments.

• Error Pages:

  • Force errors by accessing non-existent pages or adding special characters to input fields. Example paths include /whatever_fake.php or using [], ]], or [[] in URL parameters or cookies.

  • Use different HTTP methods like PATCH, DEBUG, or an invalid method (e.g., FAKE) to see if the server misbehaves or leaks information.

• Fake Pages:

  • Try fake file extensions like .php, .aspx, .html, etc., to observe server responses and potential misconfigurations.

2. Forcing Errors

• Create Errors by Modifying URLs:

  • Add unexpected input to the URL, such as /~randomthing/%s or unusual parameters, to see if it causes unexpected behavior.

• Use HTTP Methods:

  • Experiment with different HTTP verbs (e.g., PUT, DELETE) to identify potential vulnerabilities, such as file uploads via WebDAV or misconfigurations.

3. SSL/TLS Vulnerabilities

• Test for HTTPS Misconfigurations:

  • If HTTPS is not enforced for sensitive data (like login credentials), it exposes the app to Man-in-the-Middle (MitM) attacks.

  • Use tools like testssl.sh, sslscan, or sslyze to check for SSL/TLS vulnerabilities. Look for weak ciphers, missing certificates, or outdated SSL protocols.

• Commands:

  • ./testssl.sh [--htmlfile] 10.10.10.10:443

  • sslscan <host:port>

  • sslyze --regular <ip:port>

4. Spidering and Content Discovery

• Web Crawling:

  • Use spidering tools like gospider, hakrawler, dirhunt, or meg to automatically discover paths and files within the web application.

  • Tools like gau and waymore can help discover historical data from external sources like Archive.org or VirusTotal.

• JavaScript Parsing:

  • Use tools like LinkFinder or goLinkFinder to extract endpoints from JavaScript files. Many applications use JavaScript to load dynamic resources, which could expose vulnerabilities.

5. Brute Force Directories and Files

• Brute-Forcing:

  • Tools like Dirb, Dirbuster, Gobuster, and Feroxbuster can be used to brute-force directories and files. Start by brute-forcing the root folder and any discovered directories.

  • Use a variety of wordlists, such as dirbuster/directory-list-2.3-medium.txt or seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt.

• Check for Backup Files:

  • Look for backups or old versions of files (e.g., file.bak, file.old, file.php~) that may contain sensitive data or code.

• Discover Hidden Parameters:

  • Use tools like Arjun, parameth, or x8 to discover hidden parameters in the web application’s requests.

6. Investigating Special Files and API Endpoints

• Files of Interest:

  • Check for .git files, .env files, or configuration files that may contain sensitive information such as API keys, passwords, and database credentials.

• API Keys:

  • Use tools like SecretFinder, TruffleHog, or RegHex to identify any API keys or sensitive data in files or comments.

7. Handling Authentication and Access Issues

• Bypass 403 Forbidden/401 Unauthorized:

  • Try bypassing HTTP authentication or explore misconfigurations in proxies by sending custom headers. You can also try to use NTLM authentication headers to provoke information disclosure on Windows servers.

• Proxy Errors:

  • If you encounter a 502 Proxy Error, it could indicate a misconfigured proxy. Use GET requests with common headers to test for Server-Side Request Forgery (SSRF).

8. Testing Web Application Vulnerabilities

• Cross-Site Scripting (XSS):

  • Inject malicious scripts into input fields, URLs, or cookies to test for XSS vulnerabilities. Ensure that input is properly sanitized and validated.

• SQL Injection (SQLi):

  • Test for SQL injection vulnerabilities by manipulating input fields and URL parameters. Use tools like sqlmap for automated testing.

• File Upload Vulnerabilities:

  • Check if file upload features allow uploading files that could be executed on the server (e.g., PHP files). Test for file type restrictions and content-type validation.

9. Monitoring JS Files for Vulnerabilities

• JS Vulnerabilities:

  • Look for vulnerabilities in JavaScript libraries or code that could be exploited. Tools like RetireJS or JSHole can help you identify outdated or vulnerable JavaScript libraries.

• Deobfuscation:

  • Use tools like JSDeobfuscator to deobfuscate JavaScript code and search for vulnerabilities or hidden functionality.

---

Recommended dictionaries

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt

• Dirsearch included dictionary

• http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10

• Assetnote wordlists

• https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content

  • raft-large-directories-lowercase.txt

  • directory-list-2.3-medium.txt

  • RobotsDisallowed/top10000.txt

• https://github.com/random-robbie/bruteforce-lists

• https://github.com/google/fuzzing/tree/master/dictionaries

• https://github.com/six2dez/OneListForAll

• https://github.com/random-robbie/bruteforce-lists

• https://github.com/ayoubfathi/leaky-paths

• /usr/share/wordlists/dirb/common.txt

• /usr/share/wordlists/dirb/big.txt

• /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Learn & practice Web pentesting

Support VeryLazyTech 🎉

• Become VeryLazyTech member! 🎁

• Follow us on Twitter @VeryLazyTech, Github @VeryLazyTech, and Medium @VeryLazyTech.

• Visit our shop for e-books and courses. 📚

• Support us and buy me a coffee. ☕