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.
Last updated
Was this helpful?
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.
Last updated
Was this helpful?
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.
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.
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.
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.
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.
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.
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).
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.
Wordlists for Endpoint Discovery:
Example Command with wfuzz:
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.
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.
Brute-forcing Tokens: Use Hydra or Patator to brute-force token-based authentication.
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.
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:
Testing JSON Injection: Use curl with JSON payloads to check for injection points.
Injection Payload Wordlists:
SQL Injection: fuzzing/SQLi.txt from SecLists.
JSON/NoSQL Injection: nosql_payloads.txt for MongoDB-based injections.
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:
Example with Curl and a Loop: Use Bash to simulate a rapid burst of requests.
Wordlists for Rate Limiting:
Use a simple wordlist to flood the server, e.g., a list with repeated GET or POST requests.
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:
HTTPie: Makes it easy to read response codes and data.
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.
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:
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).
Certificate Testing:
SSL Labs: Use SSL Labs' SSL Test for comprehensive SSL/TLS checks.
Nmap SSL Scan:
Automated API Fuzzing:
ffuf and Wfuzz are both excellent tools for fuzzing with controlled requests.
Example:
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.
Objective: Identify subdomains, endpoints, and open ports.
Tools: Sublist3r, Amass, MassDNS, Nmap
Commands:
Discover subdomains:
Enumerate open ports:
Outcome: Gather a list of all web servers (domains and subdomains) to be tested.
Objective: Map out all accessible endpoints on each subdomain.
Tools: FFuF, Dirsearch, Burp Suite
Commands:
Directory Brute-forcing:
Outcome: Obtain a list of accessible directories and API endpoints.
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.
Objective: Test for SQL, command, and JSON injections.
Tools: SQLmap, NoSQLMap, Burp Suite Intruder
Commands:
SQL Injection:
Outcome: Discover injection vulnerabilities that could lead to unauthorized data access.
Objective: Check for rate limiting and potential for Denial of Service (DoS).
Tools: ffuf, curl
Commands:
Rapid request flood:
Outcome: Determine if rate limits are in place and if they can be bypassed.
Objective: Test for broken object-level authorization (BOLA).
Tools: Burp Suite, Postman
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.
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.
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.
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.
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:
Modify to:
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.
Objective: Validate HTTP response codes and inspect data returned in responses.
Tools: HTTPie, Burp Suite
Commands:
Inspect responses for error codes and data leaks:
Outcome: Identify improper data handling, such as verbose error messages or sensitive data leakage.
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.
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:
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.
The -sV flag forces Nmap to attempt to identify the version of services running on open ports.
Example Output:
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.
Example Output:
WebTech: Another tool for detecting technologies on a web server.
BuiltWith: A web-based tool that provides insights into the technologies behind a website, including server versions.
Simply enter the URL of the target website to view detailed information about the technologies it uses.
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
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.
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.
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:
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:
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:
Some WAFs may return error messages with clues about their identity, such as "Cloudflare Ray ID" or "ModSecurity."
Wappalyzer
Wappalyzer is a browser extension or online tool that can help detect technologies used on a website, including WAFs.
WhatWeb
WhatWeb can identify a variety of web technologies, including WAFs.
Example Output:
WAFW00F
WAFW00F is a dedicated tool to identify WAFs and their type.
Command:
Example Output:
Nmap Script for WAF Detection
Nmap includes scripts for detecting WAFs. The http-waf-detect script can be used to identify WAFs.
Example Output:
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:
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:
AWS WAF:
AWS WAF often uses specific error responses or headers that identify it.
Example Response Header:
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:
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:
If blocked, the WAF might return an error indicating that the request was filtered.
Command Injection Test Payloads
Use command injection payloads like:
A WAF may detect and block this request, returning an error message or a 403 response.
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:
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.
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 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.
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:
OWASP ZAP
Automated vulnerability scanning, including active and passive testing for common web vulnerabilities like XSS, SQL injection, and CSRF.
Start an automated scan:
Nikto
Identifying common web server vulnerabilities such as outdated software, misconfigurations, and server issues.
Wapiti
Automated fuzz testing to find vulnerabilities like XSS, SQL injection, and file inclusion issues.
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:
OWASP Dependency-Check
Identifying known vulnerabilities in third-party libraries and dependencies used in web applications.
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:
Retire.js
Scanning JavaScript libraries to detect known vulnerabilities.
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.
--enumerate p for plugins
--enumerate t for themes
--enumerate u for users
JoomScan (for Joomla)
Detecting vulnerabilities in Joomla websites, including outdated components and configurations.
Droopescan (for Drupal)
Finding vulnerabilities in Drupal installations, including modules, themes, and core versions.
WhatWeb (for multiple CMS platforms)
Identifying the CMS, version, and associated technologies used on a website.
CMSmap (for multiple CMS platforms)
Identifying vulnerabilities in WordPress, Joomla, Drupal, and other CMS platforms.
WPScan API (for automated scanning in CI/CD pipelines for WordPress)
Automating vulnerability scans for WordPress websites in continuous integration/continuous deployment environments.
CMS Vulnerability Scanner (general)
Scanning a variety of CMS platforms (e.g., WordPress, Joomla, Drupal) for common vulnerabilities.
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.
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.
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>
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.
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.
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.
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).
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.
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:
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
Common Wordlists: Use lists such as api-endpoints.txt from repositories like to guess endpoint names.
Visit:
NVD (National Vulnerability Database):
Exploit-DB:
Visit:
Use tools like to deobfuscate JavaScript code and search for vulnerabilities or hidden functionality.
Become VeryLazyTech ! 🎁
Follow us on Twitter , Github , and Medium .
Visit our for e-books and courses. 📚
Support us and . ☕