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.
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,OPTIONSRisks: Some methods (like
PUTandDELETE) 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. IfPUTorDELETEis 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>/endpointWordlists for Endpoint Discovery:
Common Wordlists: Use lists such as
api-endpoints.txtfrom 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 likejwt_secrets.txtfrom 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" --batchTesting 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.txtfrom SecLists.JSON/NoSQL Injection:
nosql_payloads.txtfor 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
GETorPOSTrequests.
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.txtfrom SecLists, which can help find unprotected endpoints like/backupor/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.txtfrom 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,NmapCommands:
Discover subdomains:
sublist3r -d target.comEnumerate 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 SuiteCommands:
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 SuiteCommon 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) ValidationLack 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 IntruderCommands:
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,curlCommands:
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/profileor/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 Forbiddenor404 Not Foundif access is restricted correctly.Vulnerable Response: If you receive
200 OKor 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 SuiteCommands:
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
PHPSESSIDor.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
-sVflag 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 vulnerabilityIf 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 FirewallSome 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-detectscript 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:
; lsA 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
POSTorPUT. Try using alternative methods likeHEADorOPTIONSto 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.comWapiti
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/projectAcunetix
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.
WPScan (for WordPress)
Detecting vulnerabilities in WordPress installations, including plugins, themes, and core files.
wpscan --url http://example.com --enumerate p,t,u--enumerate pfor plugins--enumerate tfor themes--enumerate ufor users
JoomScan (for Joomla)
Detecting vulnerabilities in Joomla websites, including outdated components and configurations.
joomscan -u http://example.comDroopescan (for Drupal)
Finding vulnerabilities in Drupal installations, including modules, themes, and core versions.
droopescan scan drupal -u http://example.comWhatWeb (for multiple CMS platforms)
Identifying the CMS, version, and associated technologies used on a website.
whatweb http://example.comCMSmap (for multiple CMS platforms)
Identifying vulnerabilities in WordPress, Joomla, Drupal, and other CMS platforms.
python cmsmap.py -u http://example.comWPScan 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,uCMS 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.xmland/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.phpor 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/%sor 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, orsslyzeto check for SSL/TLS vulnerabilities. Look for weak ciphers, missing certificates, or outdated SSL protocols.
Commands:
./testssl.sh [--htmlfile] 10.10.10.10:443sslscan <host:port>sslyze --regular <ip:port>
4. Spidering and Content Discovery
Web Crawling:
Use spidering tools like
gospider,hakrawler,dirhunt, ormegto automatically discover paths and files within the web application.Tools like
gauandwaymorecan help discover historical data from external sources like Archive.org or VirusTotal.
JavaScript Parsing:
Use tools like
LinkFinderorgoLinkFinderto 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, andFeroxbustercan 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.txtorseclists/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, orx8to discover hidden parameters in the web application’s requests.
6. Investigating Special Files and API Endpoints
Files of Interest:
Check for
.gitfiles,.envfiles, or configuration files that may contain sensitive information such as API keys, passwords, and database credentials.
API Keys:
Use tools like
SecretFinder,TruffleHog, orRegHexto 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
GETrequests 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
sqlmapfor 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
RetireJSorJSHolecan 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/danielmiessler/SecLists/tree/master/Discovery/Web-Content
raft-large-directories-lowercase.txt
directory-list-2.3-medium.txt
RobotsDisallowed/top10000.txt
/usr/share/wordlists/dirb/common.txt
/usr/share/wordlists/dirb/big.txt
/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Last updated
Was this helpful?