WEB APP PENTESTING CHECKLIST

This OWASP based checklist was developed to include additional useful details and techniques for modern application assessments (Always in-progress)

Excel Version (in-depth) of Checklist is also available fore download here:

154KB

WSTG Checklist.xlsx

Open

https://github.com/CristiVlad25/misc/tree/master

Scope configuration:

Nongreedy match .*?website.com$

INFORMATION GATHERING

Open Source Reconnaissance - WSTG-INFO-01

• Perform Google Dorks search

  • Effective dorks in the GHDB

• Perform OSINT for as much public information as possible from online resources

• Utilize Infohunter by Martian Defense

• Search engines often expose sensitive info such as network details, login credentials, and private organizational data.

• Use as many: Different search engines, including Baidu, Bing, Google, and DuckDuckGo, offer unique results due to their specific algorithms and indexing times.

• Use search operators: Advanced operators like site:, inurl:, and filetype: refine search queries for more targeted findings.

• View Cached Content: The cache: operator helps retrieve previously indexed, changed, or removed online content.

Fingerprinting Web Server - WSTG-INFO-02

• Find the type of Web Server

• Find the version details of the Web Server

  • View Wappylyzer, Whatruns, Server Reponses

• Perform banner grabbing using tools like telnet for HTTP or openssl for TLS/SSL requests to analyze web server response headers​​.

• Send malformed requests to the web server and examine error responses or default error pages for server identification​​.

• Use automated scanning tools like Netcraft, Nikto, and Nmap/Zenmap for more robust web server fingerprinting, leveraging their extensive databases of known responses

Looking For Metafiles - WSTG-INFO-03

• View the Robots.txt file

  • https://www.google.com/search?q=site.com+robots.txt

• View the Sitemap.xml file

• View the Humans.txt file

• View the Security.txt file

• Examine <META> tags within the HTML documents for directives or information that could aid in mapping the application's structure or technology​​.

Enumerating Web Server’s Applications - WSTG-INFO-04

• Enumerating with Nmap

  • nmap –Pn –sT –sV –p0-65535 <IP or Domain>

• Enumerating with Netcat

• Perform a DNS lookup

• Perform a Reverse DNS lookup

• Attempt Zone Transfer

  • First identify nameservers for the site

    host -t ns www.site.com

  • Transfer to discovered nameservers

    host -l www.site.com ns1.securesite.net

• Check for web applications on non-standard URLs through methods like directory browsing, search engine indexing (using site: operator), and probing likely URLs (e.g., /webmail, /admin)​​.

• Use a port scanner like Nmap with the -sV option to identify HTTP[S] services on non-standard ports, scanning the full range of TCP ports​​.

• For virtual host discovery, attempt DNS zone transfers using tools like nslookup, host, or dig, and perform inverse (PTR) DNS record queries to identify associated DNS names​​.

• Inspect HTTPS server certificates for Common Name (CN) and Subject Alternate Name (SAN) to find associated hostnames using tools like OpenSSL​​.

Review The Web Contents - WSTG-INFO-05

• Inspect the page source for sensitive info

• Try to find Sensitive Javascript codes

• Try to find any keys

• Make sure the autocomplete is disabled

• Review web page comments and metadata in HTML source code for debugging information or sensitive data like SQL code, credentials, or internal IP addresses​​.

• Identify and examine JavaScript code and external .js files for hardcoded sensitive information such as API keys, internal IP addresses, sensitive routes, or credentials​​.

• Check for source map files by appending the “.map” extension to JavaScript files, and analyze these files for sensitive information that could provide insights into the application​​.

• Inspect redirect responses, especially those resulting from authentication or authorization checks, for leaked content using browser developer tools or personal proxies like ZAP, Burp, Fiddler, or Charles​​.

Identifying Application’s Entry Points - WSTG-INFO-06

• Identify what the methods used are?

• Identify where the methods used are?

• Identify the Injection point

• Understand the application's structure by analyzing all HTTP requests, focusing on parameters and form fields in GET and POST requests. Use tools like intercepting proxies for deeper inspection of these requests, paying special attention to hidden form fields in POST requests​​.

• Record observed parameters, custom headers, and other request/response details in a structured format (e.g., spreadsheet). Note the type of request, authentication status, TLS usage, involvement in multi-step processes, and use of WebSockets​​.

• Scrutinize GET and POST requests for parameters in URLs and request bodies, including hidden fields and query strings. Also, look out for custom headers and other unusual or additional headers​​.

• Examine response characteristics, such as new or modified cookies, redirects, status codes like 403 Forbidden or 500 Internal Server Errors, and any notable headers (e.g., load balancing indicators)​​.

• Utilize the OWASP Attack Surface Detector tool as a plugin in ZAP or Burp Suite, or as a command-line tool to uncover web application endpoints, parameters, and data types, including those not typically found by spiders​​.

• Document the discovered code paths in black-box testing, focusing on combinatorial and boundary value analysis for decision paths, data flow or taint analysis for variable assignments, and race conditions involving concurrent data manipulation​​.

• Use automatic spidering tools like the Zed Attack Proxy (ZAP) to automatically discover new URLs and resources on the site. Begin with a list of seed URLs to guide the spidering process​​.

• Leverage ZAP's various spidering options, including the standard Spider, Ajax Spider, and OpenAPI Support, to comprehensively map the application's execution paths​​.

Mapping Execution Paths - WSTG-INFO-07

• Use Burp Suite

• Use Dirsearch

• Use Gobuster

• Use Feroxbuster

  • feroxbuster -H "User-Agent: PENTEST" -w fzf-wordlists -u http://site/

  • feroxbuster -H "User-Agent: PENTEST" -w $WORDLIST -u SITE -t $THREADS

  • Document the discovered code paths in black-box testing, focusing on combinatorial and boundary value analysis for decision paths, data flow or taint analysis for variable assignments, and race conditions involving concurrent data manipulation​​.

  • Use automatic spidering tools like the Zed Attack Proxy (ZAP) to automatically discover new URLs and resources on the site. Begin with a list of seed URLs to guide the spidering process​​.

  • Leverage ZAP's various spidering options, including the standard Spider, Ajax Spider, and OpenAPI Support, to comprehensively map the application's execution paths​​.

Fingerprint Web Application Framework - WSTG-INFO-08, WSTG-INFO-09 (Merged)

• Use the Wappalyzer browser extension

• Use Whatweb

• View URL extensions

• View HTML source code

• View the cookie parameter

• View the HTTP headers

• To identify web application frameworks, consider several common locations including HTTP headers, cookies, HTML source code, specific files and folders, file extensions, and error messages​​.

• Examine X-Powered-By field in HTTP headers using tools like netcat, but be aware that this can be easily obfuscated or disabled for security​​.

• Look for framework-specific cookies which can indicate the underlying web framework more reliably than some other methods​​.

• Analyze HTML source code for patterns, comments, framework-specific paths (like CSS or JS folders), or script variables that point to a specific framework​​.

• Use dirbusting techniques to identify specific file and folder structures on the server unique to web components, enhancing the accuracy of framework identification​​.

• Investigate URLs for file extensions, as these can often indicate the technology used, such as .php for PHP, .aspx for Microsoft ASP.NET, and .jsp for Java Server Pages​​.

Map Application Architecture - WSTG-INFO-10

• Map the overall site structure

• Map the application architecture by identifying different components such as web servers, application servers, database servers, LDAP servers, and firewalls. This can be done through documentation provided by the application developers or through blind penetration tests​​.

• Detect reverse proxies and web application firewalls by analyzing server banners and responses to web requests. Look for discrepancies in expected vs. actual responses, or specific error messages that may indicate the presence of these elements​​.

• Identify network load balancers by analyzing multiple requests and comparing results to determine if requests are going to the same or different web servers. Look for distinct headers or cookies, such as those introduced by F5 BIG-IP load balancers​​.

• Detect application web servers by observing response headers and cookies set by the server. For example, JSESSIONID cookies are indicative of J2EE servers​​.

• Determine the use of backend databases by observing the dynamic content generation patterns and request formats, such as numeric identifiers for articles in an online shop. Knowledge of the underlying database may also be inferred from vulnerabilities like SQL injection​​.

---

CONFIGURATION & DEPLOYMENT MANAGEMENT TESTING

Test Network Configuration - WSTG-CONF-01

• Check the network configuration

• Check for default settings

• Check for default credentials

• Review known server vulnerabilities, especially those that allow unauthorized file uploads or replacements. Use automated tools for remote testing, but be aware of false positives/negatives and limitations in detecting non-exposed components like authentication backends or databases. Detailed internal information about software versions, releases, and patches is crucial for effective vulnerability analysis​​.

• Examine administrative tools used in the web server infrastructure, such as web-based interfaces, configuration files, or operating-system GUI tools. Ensure the security of these tools, particularly regarding access control mechanisms, and change default credentials to prevent unauthorized access​​.

Test Application Configuration - WSTG- CONF-02

• Ensure only required modules are used

• Ensure unwanted modules are disabled

• Ensure the server can handle DOS

• Check how the application is handling 4xx & 5xx errors

• Check for the privilege required to run

• Check logs for sensitive info

• Examine sample and known files and directories provided by default in web and application servers, as they may be vulnerable. Use CGI scanners for a quick check, but a full review of the server's contents is recommended to ensure that these files are not related to the application itself​​.

• Perform a comment review to check for any sensitive information leaked through inline HTML comments or commented-out source code. This can be done through a thorough analysis of the web server's static and dynamic content and file searches​​.

• Assess system configuration using tools like CIS-CAT Lite, Microsoft’s Attack Surface Analyzer, and NIST’s National Checklist Program to ensure conformance to configuration baselines or benchmarks​​.

• Conduct a configuration review of the web server or application server. This includes ensuring only necessary server modules are enabled, custom handling of server errors, running the server with minimized privileges, proper logging of access and errors, and configuring the server to handle overloads and prevent Denial of Service attacks​​.

• Evaluate logging mechanisms to detect flaws in applications and sustained attacks. Ensure logs do not contain sensitive information, are stored securely, are not susceptible to causing Denial of Service conditions, are rotated and kept for appropriate durations, are reviewed effectively, and that logged data is validated​​.

Test File Extension Handling - WSTG-CONF-03

• Ensure the server won’t return sensitive extensions

  • dirb http://site-being-tested.com /path/to/wordlist -X .php,.bak,.conf

• Ensure the server won’t accept malicious extensions

• Test for file upload vulnerabilities

• Submit requests with various file extensions and check how they are handled on a per-directory basis, especially in directories allowing script execution. Use scanning tools for directory identification and mirror the website structure to map the web directories​​.

• As an example, accessing a file like connection.inc can reveal sensitive information such as database credentials, indicating the presence of a MySQL DBMS backend​​.

• Certain file extensions, like .asa, .inc, and .config, should never be served by the web server as they may contain sensitive information. Other extensions like .zip, .java, .txt, .pdf, and office document formats should be carefully checked to ensure they are intended to be served and do not contain sensitive data​​.

• Employ a mix of techniques, including vulnerability scanners, spidering and mirroring tools, manual inspection, and search engine queries, to identify files with specific extensions. This approach helps overcome limitations in automatic spidering and addresses security issues related to "forgotten" files​​.

• Be aware of legacy file handling mechanisms, such as Windows 8.3, which can sometimes bypass file upload filters, leading to potential security vulnerabilities. Examples include the processing of file.phtml as PHP code and the expansion of SHELL~1.PHP by the OS shell followed by processing by the PHP ISAPI handler​​.

Review Backup & Unreferenced Files - WSTG-CONF-04

• Ensure unreferenced files don’t contain any sensitive info

• Ensure the namings of old and new backup files

• Check the functionality of unreferenced pages

• Inference from Naming Scheme: Enumerate application's pages and functions, inferring unreferenced pages from the naming scheme.

• Clues in Published Content: Review source code for hidden clues like comments, disabled forms, and JavaScript links.

• Blind Guessing: Use tools like netcat with common filenames, focusing on server responses.

• Server Vulnerabilities/Misconfigurations: Look for directory listings and specific server vulnerabilities.

• Public Information: Search engines and caches for unlinked but present pages.

• Filename Filter Bypass: Exploit OS filename expansion features and parsing differences.

• Gray-Box Testing: Manually and scriptedly inspect directories for backup or old files with predictable extensions.

Enumerate Infrastructure & Admin Interfaces - WSTG-CONF-05

• Try to find the Infrastructure Interface

• Try to find the Admin Interface

• Identify the hidden admin functionalities

• Use directory and file enumeration techniques, such as guessing paths like /admin or /administrator, and employ tools for brute-forcing server contents. Check for filenames of administrative pages.

• Examine source code for comments and links that might reveal links to administrator functionality.

• Review server and application documentation for default configurations and access information. Consult default password lists if administrative interface is found.

• Look for publicly available information about common administrative interfaces, like those in WordPress.

• Check for administrative interfaces on alternative server ports, such as Apache Tomcat’s interface often seen on port 8080.

• Investigate potential parameter tampering, like GET/POST parameters or cookies that might enable administrator functionality.

• Verify server/application hardening, check for non-default credentials/configurations, and review source code for clear user/admin role separation.

Testing HTTP Methods - WSTG-CONF-06

• Discover the supported methods

• Ensure the PUT method is disabled

• Ensure the OPTIONS method is disabled

• Test access control bypass

• Test for XST attacks

• Test for HTTP method overriding

• Identify supported HTTP methods using an OPTIONS request or by directly requesting each method and observing server responses.

• Test the PUT and DELETE methods for potential file creation or deletion on the server, noting their different effects based on server configuration.

• Check for the TRACE method, which echoes back request contents, noting its deprecation but importance for server hardening.

• Examine the CONNECT method that could allow traffic proxying through the server.

• Investigate the PATCH method for object modification instructions.

• Test for access control bypass using different HTTP methods like HEAD or custom methods.

• Test for HTTP method overriding using headers like X-HTTP-Method, X-HTTP-Method-Override, or X-Method-Override.

Test HSTS - WSTG-CONF-07

• Ensure HSTS is enabled

  • This can also be detected pretty well with the Wappalyzer browser extension

• Confirm the presence of the HSTS header by inspecting server responses via an intercepting proxy.

• Use curl to check for the HSTS header:

  • curl -s -D- https://example.org | grep -i strict-transport-security

Test RIA Cross Domain Policy - WSTG-CONF-08

• Check for Adobe’s Cross Domain Policy

• Ensure it has the least privilege

Test File Permission - WSTG-CONF-09

• Ensure the permissions for sensitive files

• Test for directory enumeration

• Use the ls command in Linux to check file permissions. Alternatively, namei can recursively list file permissions ($ namei -l /PathToCheck/).

• Focus on testing permissions of web files/directories, configuration files, sensitive files (e.g., encrypted data, passwords, keys), log files, executables, database files, temporary files, and upload directories.

Test For Subdomain Takeover - WSTG-CONF-10

• Test DNS, A, and CNAME records for subdomain takeover

• Test NS records for subdomain takeover

• Test 404 response for subdomain takeover

• Enumerate victim's DNS servers and resource records using methods like DNS enumeration with common subdomains, brute force, or OSINT data sources, and check for DNS server response messages like NXDOMAIN, SERVFAIL, REFUSED, or no servers could be reached.

• Perform basic DNS enumeration with tools like dnsrecon to identify inactive or unused DNS records, especially A and CNAME records.

• For A records, perform a whois lookup to identify the service provider and check for a "404 - File not found" response which indicates vulnerability.

• Test NS record subdomain takeover by identifying all nameservers for the domain and checking if any are associated with domains available for purchase.

Test Cloud Storage - WSTG-CONF-11

• Check the sensitive paths of AWS

• Check the sensitive paths of Google Cloud

• Check the sensitive paths of Azure

• URL Identification: Determine the URL for accessing the cloud storage service. For Amazon S3, identify the bucket URL, which can be in virtual hosted style or path-style.

• Read Unauthorized Data: Use curl -X GET to test reading an object from the storage service. Example: curl -X GET https:///.

• Analyzing Test Results: Success or failure in performing these actions, such as unauthorized read or upload, indicates the configuration state of the S3 bucket, revealing potential misconfigurations.

• AWS CLI Testing: Apart from curl, AWS CLI can be used for listing (aws s3 ls s3://), uploading (aws s3 cp arbitrary-file s3://bucket-name/path-to-save), and removing objects (aws s3 rm s3://bucket-name/object-to-remove) in an S3 bucket.

• Upload Arbitrary File: Test file upload capability with curl -X PUT. For Windows, use double quotes. Example:

  • curl -X PUT -d 'test' "https:///test.txt"

Testing for Content Security Policy - WSTG-CONF-12

• Test for CSP misconfigurations by examining the Content-Security-Policy HTTP response header or CSP meta element for:

  • The unsafe-inline directive, which enables inline scripts/styles and increases XSS vulnerability.

  • The unsafe-eval directive that allows eval() use, prone to bypass techniques like data URL injection.

  • The unsafe-hashes directive permitting inline scripts/styles based on specific hashes.

  • Wildcard sources () in directives, allowing resources like scripts to be loaded from any origin, and check for partial match wildcards like https:// or *.cdn.com.

  • The frame-ancestors directive using wildcards, potentially leading to clickjacking vulnerabilities if not properly defined.

Test Path Confusion - WSTG-CONF-13

• In black-box testing, replace existing application paths with non-existent ones and observe the behavior and status codes. For instance, modify a known path like https://example.com/user/dashboard to https://example.com/user/dashboard/non.js to check for Web Cache Deception vulnerabilities.

• In white-box testing, examine the application's routing configuration, often involving regular expressions. Look for incorrect patterns that could lead to vulnerabilities, such as misconfigured expressions in Django's urls.py.

---

IDENTITY MANAGEMENT TESTING

Test Role Definitions - WSTG-IDNT-01

• Test for forced browsing

• Test for IDOR (Insecure Direct Object Reference)

• Test for parameter tampering

• Ensure low privilege users can’t able to access high privilege resources

• Identify application roles for testing through application documentation, developer/administrator guidance, comments within the application, and fuzzing possible roles via cookie/account variables or hidden directories/files.

• Test and validate access to identified roles. Be aware that the mere existence of roles does not necessarily indicate a vulnerability.

• Review and understand the permissions assigned to each role to ensure appropriate access levels, such as preventing support engineers from performing administrative functions or restricting administrators' powers with maker-checker principles or multi-factor authentication (MFA).

Test User Registration Process - WSTG-IDNT-02

• Ensure the same user or identity can’t register again and again

• Ensure the registrations are verified

• Ensure disposable email addresses are rejected

• Check what proof is required for successful registration

• Verify user registration aligns with business and security needs by checking if:

  • Anyone can register for access.

  • Registrations are vetted manually or automatically.

  • Multiple registrations are allowed per identity.

  • Users can register for different roles or permissions.

  • Required proof of identity for successful registration.

  • Registered identities are verified.

• Validate the registration process by assessing:

  • The ease of forging or faking identity information.

  • Potential manipulation in the exchange of identity information during registration.

Test Account Provisioning Process - WSTG-IDNT-03

• Check the verification for the provisioning process

• Check the verification for the de-provisioning process

• Check the provisioning rights for an admin user to other users

• Check whether a user is able to de-provision themself or not?

• Check for the resources of a de-provisioned user

• Determine which roles can provision users and the types of accounts they can create. Investigate the following:

  • The presence of verification, vetting, and authorization for provisioning and de-provisioning requests.

  • Whether administrators can provision other administrators or only users.

  • If administrators or users can provision accounts with higher privileges than their own.

  • The ability of administrators or users to de-provision themselves.

  • The management of files or resources owned by de-provisioned users, including whether they are deleted or if access is transferred.

Testing For Account Enumeration - WSTG-IDNT-04

• Check the response when a valid username and password entered

• Check the response when a valid username and an invalid password entered

• Check the response when an invalid username and password entered

• Ensure the rate-limiting functionality is enabled in username and password fields

• To test for user enumeration, record server responses for:

  • Valid user ID and password.

  • Valid user ID with wrong password.

  • Invalid user ID with a password.

• Analyze differences in error messages and HTTP responses for these scenarios.

• Enumerate users through methods like analyzing error codes on login pages, URL redirections, URI probing, web page titles, recovery facility messages, friendly 404 error messages, and response times.

• Test staff impersonation by ensuring reserved usernames (e.g., admin) can't be used in registration or profile editing.

• For gray-box testing, confirm uniformity in authentication error messages across all failed attempts.

Test For Weak Username Policy - WSTG-IDNT-05

• Check the response for both valid and invalid usernames

• Check for username enumeration

• Determine the structure of account names.

• Evaluate the application’s response to valid and invalid account names.

• Use different responses to valid and invalid account names to enumerate valid account names.

• Use account name dictionaries to enumerate valid account names.

---

AUTHENTICATION TESTING

Test For Un-Encrypted Channel - WSTG-ATHN-01

• Check for the HTTP login page

• Check for the HTTP register or sign-in page

• Check for HTTP forgot password page

• Check for HTTP change password

• Check for resources on HTTP after logout

• Test for forced browsing to HTTP pages

Test For Default Credentials - WSTG-ATHN-02

• Test with default credentials

• Test organization name as credentials

• Test for response manipulation

• Test for the default username and a blank password

• Review the page source for credentials

• Identify the software in use and search for its default passwords using methods like online searches, reviewing manuals, checking common default password databases, and inspecting application source code or hardware.

• Test for organization-specific default passwords, which are often predictable and can be identified through guessing or brute-forcing, especially in grey-box or white-box testing scenarios.

• Check for application-generated default passwords by creating multiple accounts and comparing the passwords, looking for patterns like static strings, hashed account details, or weak pseudo-random number generation.

Test For Weak Lockout Mechanism - WSTG-ATHN-03

• Ensure the account has been locked after 3-5 incorrect attempts

• Ensure the system accepts only the valid CAPTCHA

• Ensure the system rejects the invalid CAPTCHA

• Ensure CAPTCHA code regenerated after reloaded

• Ensure CAPTCHA reloads after entering the wrong code

• Ensure the user has a recovery option for a lockout account

• Attempt login with incorrect password incrementally (3, 4, 5 times) to check at which point lockout triggers.

• After lockout, try correct password at different intervals (5, 10, 15 minutes) to determine automatic unlock time​​.

• Assess CAPTCHA for weaknesses like easily solvable challenges, server-side validation issues, and bypass possibilities including cookie manipulation and direct server-side requests​​.

• Apply testing process to all application functionalities requiring lockout mechanisms​​.

• Initiate unlock mechanism; inspect for vulnerabilities, especially in mechanisms like secret questions or one-time email links​​.

Test For Bypassing Authentication Schema - WSTG-ATHN-04

• Test forced browsing directly to the internal dashboard without login

• Test for session ID prediction

• Test for authentication parameter tampering

• Test for SQL injection on the login page

• Test to gain access with the help of session ID

• Test multiple logins allowed or not?

• Use direct page requests to access protected pages without authentication.

• Modify URL parameters or cookies to bypass login.

• Predict or brute-force session IDs for unauthorized access.

• Exploit SQL injection vulnerabilities in authentication forms.

• Look for PHP loose comparison vulnerabilities or similar flaws in source code.

Test For Vulnerable Remember Password - WSTG-ATHN-05

• Ensure that the stored password is encrypted

• Ensure that the stored password is on the server-side

• Examine if credentials are stored in encoded form in browser storage; follow web storage testing and session analysis scenarios.

• Test for vulnerabilities to Clickjacking and CSRF attacks due to automatic credential injection.

• Analyze token lifetimes to ensure they expire appropriately and don't pose a risk if stolen.

Test For Browser Cache Weakness - WSTG-ATHN-06

• Ensure proper cache-control is set on sensitive pages

• Ensure no sensitive data is stored in the browser cache storage

• Enter sensitive information, log out, and use the browser's Back button to check if sensitive data can be accessed unauthenticated.

• Ensure pages are delivered over HTTPS and use Cache-Control: must-revalidate to prevent sensitive data storage in browser history.

• Use a proxy like ZAP to check server responses for Cache-Control: no-cache, no-store, Expires: 0, Pragma: no-cache directives on pages with sensitive information.

• Verify browser cache handling on different browsers and operating systems; inspect cache directories for stored sensitive information.

• Test mobile browser cache handling separately, using tools like Chrome’s Device Mode or Firefox’s Responsive Design Mode, and personal proxies to simulate mobile User-Agent strings.

Test For Weak Password Policy - WSTG-ATHN-07

• Ensure the password policy is set to strong

• Check for password reusability

• Check the user is prevented to use his username as a password

• Check for the usage of common weak passwords

• Check the minimum password length to be set

• Check the maximum password length to be set

• Check permitted and forbidden characters for passwords, and requirements for character sets like upper/lowercase letters, digits, and symbols.

• Determine the frequency of password changes and if rapid consecutive changes can bypass password history requirements.

• Assess if the application enforces regular password changes and complies with standards like PCI DSS. -Investigate how often a user can reuse a password and if the application tracks password history.

• Evaluate how different consecutive passwords must be.

• Verify if the application prevents use of username or personal information in passwords.

• Examine the minimum and maximum password length settings for appropriateness.

Testing For Weak Security Questions - WSTG-ATHN-08

• Check for the complexity of the questions

• Check for brute-forcing

• Obtain a list of security questions by creating a new account or using the password recovery process. Identify questions vulnerable to attacks like guessing, brute-forcing, or social media information.

• Create security questions in an existing account to check if the system permits insecure self-generated questions.

• Assess if incorrect security answers trigger a lockout mechanism.

• Focus on exploiting security questions with public, factual, or limited answer options.

• Determine the number of permissible guesses, presence of lockout mechanisms, and potential for Denial of Service attacks via incorrect answers.

Test For Weak Password Reset Function - WSTG-ATHN-09

• Check what information is required to reset the password

• Check for password reset function with HTTP

• Test the randomness of the password reset tokens

• Test the uniqueness of the password reset tokens

• Test for rate limiting on password reset tokens

• Ensure the token must expire after being used

• Ensure the token must expire after not being used for a long time

• Gather information about available password reset mechanisms, including requirements for initiating a reset.

• Evaluate the security of the password reset process, ensuring it's as secure as the authentication process and protected against automated attacks.

• Check for common vulnerabilities like SQL injection or XSS in the reset process.

• Assess email-based password reset methods for security concerns like unencrypted password transmission, secure password generation, and anti-spoofing measures.

• Evaluate link-based password reset methods, focusing on HTTPS usage, token security, link expiry, and exposure to third parties.

• For SMS/phone call-based resets, check token security, rate limiting, and overall security considerations.

• Ensure authenticated password changes require re-authentication and are not vulnerable to CSRF attacks, and that a strong password policy is enforced.

Test For Weak Password Change Function - WSTG-ATHN-09

• Check if the old password asked to make a change

• Check for the uniqueness of the forgotten password

• Check for blank password change

• Check for password change function with HTTP

• Ensure the old password is not displayed after changed

• Ensure the other sessions got destroyed after the password change

• Gather information about available password reset mechanisms, including requirements for initiating a reset.

• Evaluate the security of the password reset process, ensuring it's as secure as the authentication process and protected against automated attacks.

• Check for common vulnerabilities like SQL injection or XSS in the reset process.

• Assess email-based password reset methods for security concerns like unencrypted password transmission, secure password generation, and anti-spoofing measures.

• Evaluate link-based password reset methods, focusing on HTTPS usage, token security, link expiry, and exposure to third parties.

• For SMS/phone call-based resets, check token security, rate limiting, and overall security considerations.

• Ensure authenticated password changes require re-authentication and are not vulnerable to CSRF attacks, and that a strong password policy is enforced.

Test For Weak Authentication In Alternative Channel - WSTG-ATHN-10

• Test authentication on the desktop browsers

• Test authentication on the mobile browsers

• Test authentication in a different country

• Test authentication in a different language

• Test authentication on desktop applications

• Test authentication on mobile applications

• Thoroughly test the primary authentication functions to understand account creation, password recovery/reset, and any enhanced authentication measures.

• Identify alternative channels by reviewing site content, searching HTTP proxy logs for specific keywords, and using search engines to find related sites or applications.

• Enumerate authentication functions in each alternative channel, comparing them with the primary channel, and note any extra functions or weaker security measures.

• Review and test all identified channels, including out-of-scope or information-only channels, using tests from other authentication test cases in the guide.

• Ensure a consistent and equally secure authentication policy across all channels.

---

AUTHORIZATION TESTING

Testing Directory Traversal File Include - WSTG-ATHZ-01

• Identify the injection point on the URL

• Test for Local File Inclusion

• Test for Remote File Inclusion

• Test Traversal on the URL parameter

• Test Traversal on the cookie parameter

• Enumerate input vectors: Identify all parts of the application accepting user content, including HTTP GET and POST queries, file uploads, and HTML forms.

• Analyze input validation functions: Test for validation checkpoint failures using paths like ../../../../etc/passwd or external content links, considering system knowledge and file locations.

• Consider different path separators: Be aware of OS-specific path separators (Unix-like /, Windows \ or /, macOS :) and test with various encodings and directory traversal payloads (see PayloadsAllTheThings).

• Windows-specific testing: For shell and API calls, test with path alterations (angle brackets, double quotes, extraneous markers). Use UNC filepaths and NT device namespace for SMB shares and device access.

• Gray-Box Testing: Utilize source code access to search for inclusion functions and filesystem operations, employing tools like grep and regex patterns for PHP, JSP/Servlet, and ASP. Insert crafted path traversal strings into database-stored values and parameters.

Testing Traversal With Encoding -

• Test Traversal with Base64 encoding

• Test Traversal with URL encoding

• Test Traversal with ASCII encoding

• Test Traversal with HTML encoding

• Test Traversal with Hex encoding

• Test Traversal with Binary encoding

• Test Traversal with Octal encoding

• Test Traversal with Gzip encoding

Testing Traversal With Different OS Schemes -

• Test Traversal with Unix schemes

• Test Traversal with Windows schemes

• Test Traversal with Mac schemes

Test Other Encoding Techniques

• Test Traversal with Double encoding

• Test Traversal with all characters encode

• Test Traversal with only special characters encode

Test Authorization Schema Bypass - WSTG-ATHZ-02

• Test for Horizontal authorization schema bypass

• Test for Vertical authorization schema bypass

• Test override the target with custom headers

• Test horizontal authorization: Generate two users with identical privileges, keep distinct sessions active, alter session identifiers and parameters in requests, and check if responses contain private data or indicate operation success on another user's resources.

• Test administrative function access: Execute administrative function requests as a non-admin user and observe whether the operation succeeds or the user is created with privileges.

• Test role-based resource access: As a normal user, attempt to access, modify, or delete resources assigned to different roles, such as files in a restricted area.

• Test special header handling: Send requests with X-Original-URL or X-Rewrite-URL headers pointing to non-existing resources and assess response; if supported, attempt access control bypass using these headers.

• Test proxy/forwarding headers for access: Use headers like X-Forwarded-For, X-Remote-IP, adding local network addresses or port elements, to bypass restrictions like web application firewalls.

Test For Privilege Escalation - WSTG-ATHZ-03

• Identify the injection point

• Test for bypassing the security measures

• Test for forced browsing

• Test for IDOR

  IDOR testing Automation Steps for Burp Pro Users

  • Download Standalone Jython Jar file from https://www.jython.org/ and store

  • Start Burp Pro

  • Install Autorize from the Burp App (BApp) Store

  • Capture login request and copy cookie

  • Paste cookie into Autorize Configuration

    • Note: Instead of pasting you can also select "Copy cookie from last request"

  • Turn Autorize on and refresh page or walk the application for auth testing

  • Monitor and verify findings (subject to false positives)

• Test for parameter tampering to high privileged user

• Record and test database functions (create, receive, delete info) for unauthorized role/privilege access.

• Modify groupID and orderID parameters to test for unauthorized access to privileged data.

• Change hidden field values (e.g., profile to SysAdmin) in server responses to test for privilege escalation.

• Test for privilege escalation by altering parameter values in server responses (e.g., changing PVValid value).

• Modify X-Forwarded-For HTTP header to test IP-based access control and login attempt limits.

• For vertical authorization, register different role users and interchange session identifiers to test access to higher role resources.

• Test for authorization bypass by accessing or operating higher role functions through URL traversal and weak session IDs.

Test For Insecure Direct Object Reference - WSTG-ATHZ-04

• Test to change the ID parameter

• Test to add parameters at the endpoints

• Test for HTTP parameter pollution

• Test by adding an extension at the end

• Test with outdated API versions

• Test by wrapping the ID with an array

• Test by wrapping the ID with a JSON object

• Test for JSON parameter pollution

• Test by changing the case

• Test for path traversal

• Test by changing words

• Test by changing methods

• Identify locations in the application where user input is used to directly access database rows, files, or pages.

• Change parameter values used for object references to check if objects belonging to other users can be accessed.

• Use multiple user accounts to cover different owned objects (like private messages, purchase info) and varying privileges (e.g., admin users).

• Test scenarios including retrieving database records, performing system operations (e.g., changing passwords), accessing file resources, and using parameters to access different application functionalities.

• If object references are split between parameters, modify testing approach accordingly.

Testing for OAuth Weaknesses - WSTG-ATHZ-05

• Identify deprecated OAuth grant types in requests to /token endpoint by examining the grant_type parameter.

• For public clients, verify proper use of Authorization Code grant with PKCE by checking for response_type=code and code_challenge=sha256(xyz) in authorization requests.

• For confidential clients, ensure proper use of Authorization Code grant and check if PKCE extension is used.

• In machine-to-machine scenarios, validate the use of Client Credentials grant by checking client_id and client_secret.

• Test for credential leakage by using an HTTP intercepting proxy to analyze OAuth traffic for exposed tokens (access, refresh, authorization code, PKCE code challenge/verifier) in URLs or referrer headers.

---

SESSION MANAGEMENT TESTING

Test For Session Management Schema - WSTG-SESS-01

• Ensure all Set-Cookie directives are secure

• Ensure no cookie operation takes place over an unencrypted channel

• Ensure the cookie can’t be forced over an unencrypted channel

• Ensure the HTTPOnly flag is enabled

• Check if any cookies are persistent

• Check for session cookies and cookie expiration date/time

• Check for session fixation

• Check for concurrent login

• Check for session after logout

• Check for session after closing the browser

• Try decoding cookies (Base64, Hex, URL, etc)

• Test all client-application interactions for: Secure flag on Set-Cookie directives, Cookie operations over encrypted transport, forcing Cookie over unencrypted transport, and security maintenance.

• Analyze persistent cookies for reasonable expiration times and transient cookie configurations.

• Check HTTP/1.1 and HTTP/1.0 Cache-Control settings for Cookie protection.

• Cookie Collection: Surf application to identify cookie creation, modification, necessity for application parts, and map each cookie.

• Session Analysis: Examine session tokens for randomness, uniqueness, and information leakage, including token structure, and test for predictability and randomness.

• Cookie Reverse Engineering: Collect multiple cookie instances, observe patterns, and perform checks on character set, structure, and information carried.

• Test for brute force attacks considering Session ID variance and session duration.

• For Gray-Box Testing: Verify random session token generation, adequate token length, session timeout, and proper cookie configuration (non-persistent, secure, HTTPOnly).

Test For Cookie Attributes - WSTG-SESS-02

• Ensure the cookie must be set with the secure attribute

• Ensure the cookie must be set with the path attribute

• Ensure the cookie must have the HTTPOnly flag

• Ensure cookies use the Secure attribute, which requires transmission over HTTPS, preventing leakage in unencrypted requests.

• Verify HttpOnly attribute usage to restrict cookie access via client-side scripts, reducing XSS attack vectors.

• Check Domain attribute to ensure cookies are sent only to appropriate domain or subdomains, avoiding unintended access.

• Confirm Path attribute correctly scopes cookie access to specified URL paths, preventing misuse across multiple applications on the same server.

• Validate Expires attribute for appropriate persistent cookie lifespan and removal after expiration.

• Test SameSite attribute settings (Strict, Lax, None) for cross-site request handling, with Strict providing highest restriction.

• Review cookies for Host and Secure prefixes, ensuring they meet specific conditions like Secure attribute presence and path restrictions.

• Apply best practices by combining attributes and prefixes effectively, e.g., Set-Cookie: __Host-SID=; path=/; Secure; HttpOnly; SameSite=Strict for maximum security.

Test For Session Fixation - WSTG-SESS-03

• Ensure new cookies have been issued upon a successful authentication

• Test manipulating the cookies

• Make a request to the target site and observe the session identifier set in the response cookie.

• Authenticate to the application and check if a new cookie is issued post-authentication.

• If no new cookie is issued, test for session hijacking possibility by sending the old session identifier to another user and observing if privileges are assigned to this cookie.

• For testing with forced cookies, follow these steps:

  • Access the login page and save a snapshot of the cookie jar, excluding __Host- or __Secure- prefixed cookies.

  • Log in as the victim, then revert to the saved cookie jar.

  • Trigger a secure function and observe if the operation succeeds with the old cookie.

  • Log in as the attacker, replicate the cookie jar setup, and try accessing the victim's account.

Test For Exposed Session Variables - WSTG-SESS-04

• Test for encryption

• Test for GET and POST vulnerabilities

• Test if GET request incorporating the session ID used

• Test by interchanging POST with GET method

• Test for encryption and reuse of session tokens vulnerabilities by ensuring TLS encryption is used and session IDs are protected during transit. Replace https:// with http:// and modify form posts to check for secure and non-secure segregation.

• Ensure different session IDs are used when switching from secure to non-secure site elements.

• Test for proxies and caching vulnerabilities: Session IDs should never be sent over unencrypted transport or cached. Check that encrypted communications are default and enforced, and appropriate cache-control directives are in place.

• Test for GET & POST vulnerabilities: Avoid using GET requests for Session IDs due to exposure risks. Ensure server-side scripts do not accept session data sent via GET when it should be POST.

• Check how Session IDs are transferred (GET, POST, hidden fields), ensure they are always sent over encrypted transport, and verify if the application can be manipulated to send Session IDs unencrypted. Confirm appropriate cache-control directives are applied and consistently present.

Test For Back Refresh Attack

• Test after password change

• Test after logout

Test For Cross Site Request Forgery - WSTG-SESS-05

• Check if the token is validated on the server-side or not

• Check if the token is validated for full or partial length

• Check by comparing the CSRF tokens for multiple dummy accounts

• Check CSRF by interchanging POST with GET method

• Check CSRF by removing the CSRF token parameter

• Check CSRF by removing the CSRF token and using a blank parameter

• Check CSRF by using unused tokens

• Check CSRF by replacing the CSRF token with its own values

• Check CSRF by changing the content type to form-multipart

• Check CSRF by changing or deleting some characters of the CSRF token

• Check CSRF by changing the referrer to Referrer

• Check CSRF by changing the host values

• Check CSRF alongside clickjacking

• Audit the application's session management to identify if it depends solely on client-side values like cookies and HTTP authentication credentials. Such reliance indicates vulnerability to CSRF attacks.

• Test for CSRF vulnerabilities in resources accessible via HTTP GET requests, as these are easily exploitable.

• For POST requests, create and host a malicious HTML page designed to submit unauthorized requests via a victim's browser. This page should contain a self-submitting form with hidden inputs to simulate a CSRF attack.

• For web applications using JSON for server communication, exploit CSRF by using a self-submitting form with JSON payloads. Change the form's encoding type to text/plain to ensure proper payload delivery.

• Remediation measures can be found in the OWASP CSRF Prevention Cheat Sheet.

Test For Weak Logout Functionality - WSTG-SESS-06

• Check the log out function on different pages

• Check for the visibility of the logout button

• Ensure after logout the session was ended

• Ensure after logout we can’t able to access the dashboard by pressing the back button

• Ensure proper session timeout has been set

• Log Out User Interface Testing: Verify the logout button's visibility and accessibility on each web page. Key aspects include:

  • Presence of a logout button on all pages.

  • Easy identification and access to the logout button.

  • Immediate visibility of the logout button without the need to scroll.

  • Optimal placement in a fixed area of the browser viewport.

• Server-Side Session Termination Testing: Store session cookie values, invoke logout, and observe application behavior, especially regarding session cookies. Test for any vulnerabilities by trying to access authenticated pages after logout and by restoring old session cookies.

• Session Timeout Testing: Determine session timeout by requesting an authenticated page with increasing delays. Assess how the application handles timeout-triggered logout, balancing security and usability based on application context (e.g., short timeout for banking apps, longer for forums or wikis).

• Testing in Single Sign-On Environments: Perform logout tests in applications integrated with Single Sign-On (SSO) systems. Check if logging out of the application or the SSO system leads to global session termination, requiring re-authentication to access the application.

Test For Session Timeout - WSTG-SESS-07

• Ensure there is a session timeout exists

• Ensure after the timeout, all of the tokens are destroyed

• Black-Box Testing for Session Timeout:

  • Verify the existence of a session timeout by logging in and observing if the session logs out after a period of inactivity.

  • Determine whether the timeout is enforced client-side or server-side. If session cookies do not store time data, it's likely server-enforced.

  • Test if modifying the cookie's expiration date affects session longevity.

• Gray-Box Testing for Session Timeout:

  • Ensure the logout function destroys or renders session tokens unusable.

  • Check if the server properly invalidates session states to prevent replay of destroyed session identifiers.

  • Confirm that the session timeout is enforced by the server, ideally with server-side session invalidation methods like HttpSession.invalidate() in Java or Session.abandon() in .NET.

Test For Session Puzzling - WSTG-SESS-08

• Identify all the session variables

• Try to break the logical flow of the session generation

• Black-Box Testing for Session Puzzling:

  • Detect and exploit vulnerabilities by enumerating all session variables and understanding their context. This involves accessing different entry points in the application and observing the effect on session variables.

  • Example: Test password reset functionality, which might populate the session with identifying values, and then access other application parts using this session state to potentially bypass authentication.

• Gray-Box Testing for Session Puzzling:

  • Conduct a source code review to effectively identify session puzzling vulnerabilities.

Test For Session Hijacking - WSTG-SESS-09

• Test session hijacking on target that doesn’t has HSTS enabled

• Test by login with the help of captured cookies

• Test session hijacking on sites without full HSTS by using two accounts (victim and attacker).

• Victim logs in, deletes non-'Secure' cookies, and saves the cookie jar.

• Attempt a secure function as the victim.

• If successful, replicate this with the attacker account using the victim's saved cookies.

• Successful execution by the attacker indicates vulnerability to session hijacking.

Testing JSON Web Tokens - WSTG-SESS-10

• Analyze JWT Components: JWTs consist of a header, payload, and signature. Check the header for token type and algorithm, and review the payload for sensitive data.

• Signature Verification: Test if the application properly verifies JWT signatures by modifying the JWT body without altering the header or signature.

• Algorithm Manipulation: Check for vulnerabilities related to the none algorithm and public key vs HMAC confusion. For none, change the alg header to none, remove the signature, and see if the application accepts the modified JWT.

• Weak HMAC Keys: If JWT uses HMAC, investigate if a default HMAC signing key is used or attempt to brute-force the key.

---

INPUT VALIDATION TESTING

Test For Reflected Cross Site Scripting - WSTG-INPV-01

• Ensure these characters are filtered <>’’&””

• Test with a character escape sequence

• Test by replacing < and > with HTML entities < and >

• Test payload with both lower and upper case

• Test to break firewall regex by new line /r/n

• Test with double encoding

• Test with recursive filters

• Test injecting anchor tags without whitespace

• Test by replacing whitespace with bullets

• Test by changing HTTP methods

• Use in-browser tools or proxies to identify all user-defined variables and hidden inputs on web pages.

• Employ web application fuzzers or manual input of crafted data (e.g., alert(123)) to test each input vector for XSS vulnerabilities.

• Analyze results of test inputs for unencoded, unfiltered special characters in HTML (e.g., >, <, &, ', ") or JavaScript (e.g., \n, \r, ', ", , \uXXXX).

• Test for bypassing XSS filters using variations in syntax, encoding, and techniques like HTTP Parameter Pollution, and evaluate effectiveness of web application's input sanitization.

• In gray-box testing, utilize partial knowledge of the application to focus on user input, validation controls, and rendering of input back to the user.

Test For Stored Cross Site Scripting - WSTG-INPV-02

• Identify stored input parameters that will reflect on the client-side

• Look for input parameters on the profile page

• Look for input parameters on the shopping cart page

• Look for input parameters on the file upload page

• Look for input parameters on the settings page

• Look for input parameters on the forum, comment page

• Test uploading a file with XSS payload as its file name

• Test with HTML tags

• Identify all user input storage points in the application (e.g., user profiles, shopping carts, file managers, application settings, forums, blogs, logs) and note how they are displayed.

• Analyze HTML and JavaScript to understand how stored input is used in the context of the page, including out-of-band channels and areas accessible by administrators.

• Test for stored XSS by injecting basic examples (like [e-mail]">alert(document.cookie)) using both HTTP GET and POST requests, with and without JavaScript enabled.

• Use advanced JavaScript frameworks like BeEF for exploiting stored XSS; inject a JavaScript hook (e.g., [e-mail]">) and control the user's browser via the BeEF console.

• Check file upload functionalities for vulnerabilities by testing if HTML content or arbitrary MIME types can be uploaded, and consider browser-specific MIME handling differences.

Test For HTTP Parameter Pollution - WSTG-INPV-04

• Identify the backend server and parsing method used

• Try to access the injection point

• Try to bypass the input filters using HTTP Parameter Pollution

• Identify forms or actions allowing user input. For GET requests, modify query strings in the browser; for POST, use an intercepting proxy.

• Test by appending the same parameter with different values to GET or POST data, then analyze the response for which values are parsed.

• Perform three-step analysis:

  • submit a standard HTTP request and record the response

  • replace parameter value with a tampered one and record

  • combine both requests, submit, and compare responses

• For client-side HPP, identify forms/actions that reflect user input. Append %26HPP_TEST to each HTTP parameter and check for url-decoded occurrences in the response.

Test For SQL Injection - WSTG-INPV-05

• Test SQL Injection on authentication forms

• Test SQL Injection on the search bar

• Test SQL Injection on editable characteristics

• Try to find SQL keywords or entry point detections

• Try to inject SQL queries

• Use tools like SQLmap or Hackbar

• Use Google dorks to find the SQL keywords

• Try GET based SQL Injection

• Try POST based SQL Injection

• Try COOKIE based SQL Injection

• Try HEADER based SQL Injection

• Try SQL Injection with null bytes before the SQL query

• Try SQL Injection with URL encoding

• Try SQL Injection with both lower and upper cases

• Try SQL Injection with SQL Tamper scripts

• Try SQL Injection with SQL Time delay payloads

• Try SQL Injection with SQL Conditional delays

• Try SQL Injection with Boolean based SQL

• Try SQL Injection with Time based SQL

• Identify when the application interacts with a database (e.g., authentication forms, search engines, e-commerce product listings).

• List and test all input fields, including hidden POST fields, HTTP headers, and cookies, to interfere with SQL queries.

• Add a single quote ' or a semicolon ; to input fields to generate errors, indicating SQL injection vulnerabilities.

• Use comment delimiters and SQL keywords like AND/OR to modify queries.

• Monitor web server responses and HTML/JavaScript source code for error messages indicating SQL injection vulnerabilities.

Test For LDAP Injection - WSTG-INPV-06

• Use LDAP search filters

• Try LDAP Injection for access control bypass

• Replace values in LDAP search filters (e.g., user=John to user=*) to test for unfiltered input leading to LDAP injection.

• Insert LDAP metacharacters (e.g., (, |, &, *) in parameters to check for application errors.

• Test login processes using LDAP for user authentication; inject always true LDAP queries to bypass authentication.

• For example, manipulate LDAP user/password filters to gain logged-in status as the first user in the LDAP tree.

Testing For XML Injection - WSTG-INPV-07

• Check if the application is using XML for processing

• Identify the XML Injection point by XML metacharacter

• Construct XSS payload on top of XML

• Insert XML metacharacters (', ", >, <, , &, ) into user inputs to test for malformed XML documents.

• Check for exceptions during XML parsing when metacharacters are part of attribute values in tags.

• Test with open or closed angular parentheses in user input to validate XML document formation.

• Use ampersand (&) without proper encoding (&) to identify undefined entities in XML.

• Inject CDATA section delimiters to evaluate if XML document processes them correctly or includes them in HTML output, potentially leading to XSS vulnerabilities.

Test For Server Side Includes - WSTG-INPV-08

• Use Google dorks to find the SSI

• Construct RCE on top of SSI

• Construct other injections on top of SSI

• Test Injecting SSI on login pages, header fields, referrer, etc

• Inject SSI directives as user input to test for vulnerable SSI implementation.

• Determine if the web server supports SSI by identifying the server type or checking for .shtml extensions.

• Identify all user input vectors, including pages with user input, headers, and cookies.

• Test input validation by attempting to inject characters used in SSI directives.

• Check if injected SSI directives like or are executed by the server.

Test For XPATH Injection - WSTG-INPV-09

• Identify XPATH Injection point

• Test for XPATH Injection

• Test for XPath Injection by inserting a single quote (') in input fields to create syntax errors in XPath queries.

• Check if the application improperly filters user input, allowing XPath code injection that alters query results.

• Use values like ' or '1' = '1 in username and password fields to create queries that always evaluate to true.

• If the application doesn't provide error messages, use Blind XPath Injection techniques to reconstruct the XML data structure.

Test For IMAP SMTP Injection - WSTG-INPV-10

• Identify IMAP SMTP Injection point

• Understand the data flow

• Understand the deployment structure of the system

• Assess the injection impact

• Analyze application input handling by sending bogus requests and observing responses; secure applications should return an error.

• Test IMAP/SMTP injection by manipulating request parameters (e.g., assigning null, random values, or special characters to mailbox parameter).

• Observe error messages from manipulated requests to identify injection points and affected IMAP/SMTP commands.

• Determine injection level (unauthenticated or authenticated) and test accordingly using IMAP commands like CAPABILITY, AUTHENTICATE, LOGIN.

• Structure IMAP/SMTP injection with a header (ending of expected command), body (new command), and footer (beginning of expected command), ensuring command termination with CRLF (%0d%0a) sequence.

Test For Code Injection - WSTG-INPV-11

• Inject malicious code using query strings in URLs, e.g., appending commands to file inclusion parameters.

• Examine ASP code for user input used in execution functions, checking if commands can be entered.

• Review the application's handling of user input in execution functions for code injection vulnerabilities.

• Focus on input validation practices to detect any weak points allowing code injection.

• Use automated scanning tools and manual testing methods to identify potential injection points.

Test For Local File Inclusion

• Look for LFI keywords

• Try to change the local path

• Use the LFI payload list

• Test LFI by adding a null byte at the end

• Inject malicious code using query strings in URLs, e.g., appending commands to file inclusion parameters.

• Examine ASP code for user input used in execution functions, checking if commands can be entered.

• Review the application's handling of user input in execution functions for code injection vulnerabilities.

• Focus on input validation practices to detect any weak points allowing code injection.

• Use automated scanning tools and manual testing methods to identify potential injection points.

Test For Remote File Inclusion

• Look for RFI keywords

• Try to change the remote path

• Use the RFI payload list

Test for Command Injection - WSTG-INPV-12

• Append special characters like | or ; to filenames in URLs to execute commands, e.g., http://example.com/file?name=filename|.

• Use URL encoding like %3B for semicolons to execute appended commands in URLs.

• Employ personal proxies like ZAP or Burp Suite to modify POST requests and inject commands.

• Utilize special characters for command injection: |, ;, &, $, >, <, ', !.

• Test command execution with combinations like cmd1|cmd2 and cmd1;cmd2.

Test For Format String Injection - WSTG-INPV-13

• Identify the Injection points

• Use different format parameters as payloads

• Assess the injection impact

• Use static analysis tools for C/C++ (Flawfinder), Java (FindSecurityBugs), and PHP (String formatter Analyzer) to find format string vulnerabilities.

• Manually inspect code for format string vulnerabilities, especially in cases where static analysis might miss complex code-generated format strings.

• Inject conversion specifiers in string inputs during unit or system tests, and observe for crashes or unexpected outputs.

• Perform manual injection tests using web browsers or API debugging tools with URLs containing encoded conversion specifiers, e.g., %25s%25s%25s%25n.

• Utilize fuzzing tools like wfuzz, with a list of inputs including normal and malicious strings, to automate injection testing.

Testing for Incubated Vulnerability - WSTG-INPV-14

• Verify file upload content types and URLs; use files that exploit local workstation components upon viewing or downloading.

• Inject JavaScript code in vulnerable fields, like in a bulletin board, to capture cookies and impersonate users.

• Test for SQL Injection vulnerabilities and insert XSS attacks in SQL-injectable fields to change database values without proper filtering.

• Utilize misconfigured servers to upload active components, like WAR files, and deploy applications that trusted site users can access.

• Leverage any vulnerabilities to change web page contents at the server, planting incubated attacks.

Testing for HTTP Splitting Smuggling - WSTG-INPV-15

• For Black-Box Testing:

  • Identify user inputs that influence response headers.

  • Inject CR+LF sequences (%0d%0a) to split responses, e.g., in redirection URLs.

  • Target headers like Location and Set-Cookie for splitting.

  • Consider complexities like URL encoding and response caching in real-world exploitation.

• For Gray-Box Testing:

  • Understand target-specific HTTP message parsing for effective HTTP Splitting.

  • Leverage POST instead of GET if needed, using padding between split messages.

  • Exploit HTTP Smuggling by crafting messages parsed differently by various agents (e.g., firewalls, web servers).

  • Create large, structured requests to bypass firewall detection but be executed by target servers.

Testing for HTTP Incoming Requests - WSTG-INPV-16

• Set up a reverse proxy on the web server using Fiddler (Windows) or Charles (Linux) to monitor all HTTP requests.

• Capture, inspect, and optionally modify and replay HTTP traffic through these tools.

• Use port forwarding to intercept HTTP requests without client-side changes, configuring Charles as a SOCKS proxy.

• Capture network traffic at the TCP level using TCPDump or WireShark, then edit and replay HTTP requests using Ostinato.

• For HTTPS traffic, use Wireshark with the web server's private key to decrypt and inspect messages.

Test For Host Header Injection - WSTG-INPV-17

• Test for HHI by changing the real Host parameter

• Test for HHI by adding X-Forwarded Host parameter

• Test for HHI by swapping the real Host and X-Forwarded Host parameter

• Test for HHI by adding two Host parameters

• Test for HHI by adding the target values in front of the original values

• Test for HHI by adding the target with a slash after the original values

• Test for HHI with other injections on the Host parameter

• Test for HHI by password reset poisoning

• Supply a different domain in the Host header field and check if the web server processes this input, potentially causing a redirect or other unexpected behavior.

• Bypass Host header injection mitigation by using the X-Forwarded-Host header.

• Exploit web cache poisoning by manipulating the web cache with a malicious Host header.

• Test for password reset poisoning by modifying the Host header in password reset requests.

• Access private virtual hosts by manipulating the Host header, especially in split-horizon DNS setups.

Test For Server Side Template Injection - WSTG-INPV-18

• Identify the Template injection vulnerability points

• Identify the Templating engine

• Use the tplmap to exploit

• Use common template expressions in plaintext context to identify template execution by monitoring server responses.

• For code context, construct requests that cause blank or error server responses, then attempt to break out of the template statement.

• Identify the templating engine by analyzing server responses to various template expressions, using tools like Tplmap or Backslash Powered Scanner Burp Suite extension.

• Build an RCE exploit by studying template documentation, focusing on syntax, security considerations, built-in methods, and extensions. Explore objects, methods, and properties accessible through the template engine.

Test For Server Side Request Forgery - WSTG-INPV-19

• Look for SSRF keywords

• Search for SSRF keywords only under the request header and body

• Identify the Injection points

• Test if the Injection points are exploitable

  • Use an Online IP encoder to test using various ways that IPv4 can be encoded

• Assess the injection impact

• Test local and remote file inclusion by making the server load or save potentially malicious content. Example: GET https://example.com/page?page=https://malicioussite.com/shell.php.

• Access restricted pages via the loopback interface, like GET https://example.com/page?page=http://localhost/admin.

• Test for SSRF in PDF generators, trying to inject HTML content.

• Fetch local files, for instance, GET https://example.com/page?page=file:///etc/passwd.

• Test SSRF in various HTTP methods and inject into headers and cookies.

• Bypass filters blocking localhost or 127.0.0.1 using alternative IP representations, string obfuscation, or URL manipulation techniques.

Testing for Mass Assignment - WSTG-INPV-20

• Enumerate application parts accepting user content, looking for create/update operations and input patterns like user[name]. Test non-existent attributes and analyze error responses.

• Identify sensitive fields by analyzing HTML, JavaScript, API responses, and differences in requests made by users of varying privilege levels.

• Check the impact by analyzing how test inputs affect the application, focusing on changes that could lead to security issues like privilege escalation.

• In gray-box testing, leverage source code and DB schema access to pinpoint vulnerable handlers and sensitive fields, ensuring controls are in place.

---

ERROR HANDLING TESTING

Test For Improper Error Handling - WSTG-ERRH-01

• Identify the error output

• Analyze the different outputs returned

• Look for common error handling flaws

• Test error handling by modifying the URL parameter

• Test error handling by uploading unrecognized file formats

• Test error handling by entering unrecognized inputs

• Test error handling by making all possible errors

• Trigger web server error messages by searching for non-existent files (404s), requesting existing folders (403s, blank page, directory listing), and sending malformed HTTP requests (e.g., large paths, broken headers).

• For applications, identify input points, analyze expected input types, and fuzz inputs to elicit various error messages like stack traces, memory dumps, or mishandled exceptions.

• Refine fuzzing based on the service generating the error message to extract more detailed information or error specifics.

• Stay vigilant for errors disguised as successful responses, hidden in 302 redirects, or represented in a custom format.

---

WEAK CRYPTOGRAPHY TESTING

Test For Weak Transport Layer Security - WSTG-CRYP-01

• Test for DROWN weakness on SSLv2 protocol

• Test for POODLE weakness on SSLv3 protocol

• Test for BEAST weakness on TLSv1.0 protocol

• Test for FREAK weakness on export cipher suites

• Test for Null ciphers

• Test for NOMORE weakness on RC4

• Test for LUCKY 13 weakness on CBC mode ciphers

• Test for CRIME weakness on TLS compression

• Test for LOGJAM on DHE keys

• Ensure the digital certificates should have at least 2048 bits of key length

• Ensure the digital certificates should have at least SHA-256 signature algorithm

• Ensure the digital certificates should not use MDF and SHA-1

• Ensure the validity of the digital certificate

• Ensure the minimum key length requirements

• Look for weak cipher suites

• Review server configurations for legacy TLS protocols and ciphers with known weaknesses, like SSLv2, SSLv3, TLSv1.0, and weak DHE keys.

• Check digital certificates for minimum 2048-bit key strength, use of SHA-256 or stronger signature algorithms, and validity including trusted CA and correct SAN.

• Identify implementation vulnerabilities in TLS, focusing on known issues in popular libraries like OpenSSL.

• Assess application vulnerabilities related to TLS, including checking for mixed active content, proper redirection from HTTP to HTTPS, and correct usage of security headers.

• Perform automated testing using tools like Nmap, OWASP O-Saft, and SSL Labs, and manual testing with tools like openssl s_client for specific protocols and ciphers.

Testing for Padding Oracle - WSTG-CRYP-02

• Identify potential padding oracle input points by looking for encrypted data, typically base64 encoded, with lengths multiple of common cipher block sizes (8 or 16 bytes).

• Verify application response to bitwise tampering of encrypted values. This involves decoding the base64 value, modifying bits, re-encoding, and observing the behavior.

• Check for three possible states after decryption: correct decryption, garbled data causing errors, or decryption failure due to padding errors.

• In gray-box testing, ensure encrypted data is decrypted securely (using mechanisms like HMAC, GCM, CCM) and all errors are handled uniformly.

Testing for Sensitive Information Sent via Unencrypted Channels - WSTG-CRYP-03

• Capture traffic between a client and web server to identify if sensitive data is transmitted over HTTP instead of HTTPS.

• Test for basic authentication over HTTP using tools like curl to check if credentials are sent in clear text.

• Check if forms transmit user credentials or session IDs over HTTP.

• Ensure password reset, change password, or other account manipulation features use HTTPS.

• Use grep to search for hardcoded sensitive information like passwords or encryption keys in source code or logs.

Testing for Weak Encryption - WSTG-CRYP-04

• Ensure AES128 or AES256 uses a random and unpredictable IV (Initialization Vector). Avoid weak random number generators like java.util.Random.

• Use Elliptic Curve Cryptography (ECC) with secure curves like Curve25519, or RSA encryption with at least a 2048-bit key.

• Avoid weak hash/encryption algorithms like MD5, RC4, DES, Blowfish, SHA1, and ensure adequate key lengths for different cryptographic uses.

• Conduct a source code review for the use of weak algorithms, improper IV usage, and hardcoded sensitive information.

---

BUSINESS LOGIC TESTING

Test Business Logic Data Validation - WSTG-BUSL-01

• Identify the logic of how the application works

• Identify the functionality of all the buttons

• Test by changing the numerical values into high or negative values

• Test by changing the quantity

• Test by modifying the payments

• Test for parameter tampering

• Review project documentation and use exploratory testing to find data entry points or hand-off points between systems.

• Insert logically invalid data into the application/system to test data validation.

• Conduct frontend GUI Functional Valid testing to ensure only valid values are accepted.

• Use an intercepting proxy to observe HTTP POST/GET requests, focusing on potential injection or tamper points.

• Test fields with logically invalid data, like incorrect social security numbers or identifiers, to verify server-side validation.

Test Ability to Forge Requests - WSTG-BUSL-02

• Use an intercepting proxy to observe HTTP POST/GET requests, looking for patterns indicating incrementing or guessable values.

• Change guessable values to assess if unexpected visibility or access is gained.

• Also, observe HTTP POST/GET requests for hidden features like debug options that can be activated.

• Attempt to change these values to see if the application responds differently or reveals additional functionality.

Test Integrity Checks - WSTG-BUSL-03

• Capture HTTP traffic with a proxy to find hidden fields, then compare these fields with the GUI application. Manipulate these values through the proxy to test if you can bypass business logic.

• Look for non-editable areas in the application where information can be inserted. Test these fields by submitting different data values to circumvent business logic.

• Identify application components like logs or databases that could be impacted. Attempt to read, edit, or remove information in these components to test integrity checks.

Test for Process Timing - WSTG-BUSL-04

• Identify processes dependent on timing, such as task completion windows or execution times that could allow control bypass.

• Automate requests to exploit these processes for more precise timing analysis than manual testing.

• Map out process flows and injection points, and prepare requests to target these vulnerable processes.

• Conduct close analysis after testing to identify differences in process execution and any deviations from expected business logic.

Test Number of Times a Function Can Be Used Limits - WSTG-BUSL-05

• Review the project documentation and explore the application to identify functions or features that should have a limit on the number of times they can be executed.

• Develop abuse/misuse cases for each identified function or feature to test if a user can execute it more times than allowed. This includes testing whether a user can repeatedly navigate back and forth through the application's pages to re-execute a function or exploit features like shopping carts for additional discounts.

Testing for the Circumvention of Work Flows - WSTG-BUSL-06

• Start a transaction and proceed past points that trigger credits or points to a user's account. Then cancel or alter the transaction to test if the points or credits are correctly adjusted.

• On content management or bulletin board systems, enter valid initial text or values, then attempt to append, edit, or remove data to leave it in an invalid state, ensuring the system prevents saving incorrect information.

Test Defenses Against Application Misuse - WSTG-BUSL-07

• Monitor for indications of in-built application self-defense mechanisms during all other tests, such as changed responses, blocked requests, or actions that log out or lock a user's account.

• Look for localized defenses like rejecting input with certain characters or temporary account lockout after multiple authentication failures.

• Assess if there are defenses against general misuse like forced browsing, bypassing input validation, multiple access control errors, and receiving blatantly malicious payloads.

• Check if the application responds appropriately to misuse patterns such as rapid or automated usage, changing geo-locations, or accessing multi-stage processes in the wrong order.

Test Upload of Unexpected File Types - WSTG-BUSL-08

• Review the application's logical requirements to understand the expected file types.

• Prepare a set of files not approved for upload, such as JSP, EXE, or HTML files containing scripts.

• Use the file submission or upload mechanism in the application to attempt uploading these non-approved files.

• Verify that the application properly prevents the upload of unapproved file types.

• Check if the application relies only on client-side JavaScript for file type checks.

• Assess if the application checks file types by “Content-Type” in HTTP requests or by file extension.

• Test if uploaded files can be accessed directly by a specified URL or include code/script injection.

• Check for file path validation, especially for compressed files that might extract to an unintended path.

Test For Malicious File Upload - WSTG-BUSL-09

• Test malicious file upload by uploading malicious files

• Test malicious file upload by putting your IP address on the file name

• Test malicious file upload by right to left override

• Test malicious file upload by encoded file name

• Test malicious file upload by XSS payload on the file name

• Test malicious file upload by RCE payload on the file name

• Test malicious file upload by LFI payload on the file name

• Test malicious file upload by RFI payload on the file name

• Test malicious file upload by SQL payload on the file name

• Test malicious file upload by other injections on the file name

• Test malicious file upload by Inserting the payload inside of an image by the bmp.pl tool

• Test malicious file upload by uploading large files (leads to DOS)

• Ensure only trusted file types can be uploaded.

• Protect against web shells by uploading with a random name, password protection, and IP restrictions.

• Bypass filters using techniques like changing Content-Type, file extensions, and trailing characters.

• Validate file contents, including scanning for malware and checking for harmful content based on file type.

• Test for archive directory traversal and Zip bomb attacks.

• Assess XML file vulnerabilities like XXE and denial of service attacks.

• Review source code for APIs/methods related to file handling.

Test Payment Functionality - WSTG-BUSL-10

• Examine different payment gateway integration methods, such as third-party redirection, IFRAME loading, cross-domain POST requests, or direct API posts.

• Understand the relevance of PCI DSS, especially for systems that store, process, or transmit cardholder data.

• Check for quantity tampering in e-commerce sites, ensuring items added to the basket are correctly quantified and validated.

• Test multiple methods for modifying basket contents, like adding negative quantities or tampering with dropdown menus for item quantities.

---

CLIENT SIDE TESTING

Test For DOM Based Cross Site Scripting - WSTG-CLNT-01

• Try to identify DOM sinks

• Build payloads to that DOM sink type

• Examine different payment gateway integration methods, such as third-party redirection, IFRAME loading, cross-domain POST requests, or direct API posts.

• Understand the relevance of PCI DSS, especially for systems that store, process, or transmit cardholder data.

• Check for quantity tampering in e-commerce sites, ensuring items added to the basket are correctly quantified and validated.

• Test multiple methods for modifying basket contents, like adding negative quantities or tampering with dropdown menus for item quantities.

• Crawl the website to identify all instances of JavaScript execution and where user input is accepted. This helps in understanding the code being executed dynamically by the server.

• Identify two main forms of user input: input written to the page by the server and input obtained from client-side JavaScript objects.

• Analyze how input is handled, focusing on whether it undergoes server-side filtering or browser-side encoding.

• Recognize that JavaScript can be executed outside blocks, like in event handlers or CSS blocks with expression attributes.

Note: the limitations of automated testing in detecting DOM-based XSS, emphasizing the need for manual testing. This includes examining areas where parameters are referred to that could be exploited by an attacker, where code is dynamically written to the page, or where the DOM is modified or scripts are directly executed.

Testing for JavaScript Execution - WSTG-CLNT-02

• The primary objective is to identify sinks and possible JavaScript injection points.

• Examine the application's JavaScript code for any areas where user-supplied input is directly used or executed.

• Test cases like the provided script example, where the location.hash source is controlled by the attacker, can be exploited to inject JavaScript into the message value. This could potentially allow an attacker to take control of the user's browser.

Testing for HTML Injection - WSTG-CLNT-03

• Identify HTML injection points and assess the severity of the injected content. This involves pinpointing areas in the application where HTML code can be inserted by an external user and determining the impact of such injections.

• For a comprehensive approach: examine input fields, URL parameters, and any other data entry points that could be manipulated to inject HTML. The severity assessment would consider the potential impact, such as unauthorized access, data leakage, or client-side script execution.

Test For URL Redirect - WSTG-CLNT-04

• Look for URL redirect parameters

• Test for URL redirection on domain parameters

• Test for URL redirection by using a payload list

• Test for URL redirection by using a whitelisted word at the end

• Test for URL redirection by creating a new subdomain with the same as the target

• Test for URL redirection by XSS

• Test for URL redirection by profile URL flaw

• Identify client-side redirections in the code, particularly those using the window.location object.

• Check for lack of validation in redirection scripts, like in the example where user-supplied input (redir) is directly assigned to window.location without encoding, creating a URL redirection vulnerability.

• Test redirection scenarios with different inputs in the query string to see if the application redirects to unintended locations.

• Be aware of potential JavaScript injection vulnerabilities in redirection scripts and how different browsers may treat characters differently.

Testing for CSS Injection - WSTG-CLNT-05

• Crawl the website to identify all instances of JavaScript execution and where user input is accepted. This helps in understanding the code being executed dynamically by the server.

• Identify two main forms of user input: input written to the page by the server and input obtained from client-side JavaScript objects.

• Analyze how input is handled, focusing on whether it undergoes server-side filtering or browser-side encoding.

• Recognize that JavaScript can be executed outside blocks, like in event handlers or CSS blocks with expression attributes.

• Note the limitations of automated testing in detecting DOM-based XSS, emphasizing the need for manual testing. This includes examining areas where parameters are referred to that could be exploited by an attacker, where code is dynamically written to the page, or where the DOM is modified or scripts are directly executed.

Testing for Client-side Resource Manipulation - WSTG-CLNT-06

• Identify whether the application allows user-controlled inputs to specify external resources without proper validation.

• Investigate client-side scripts handling URLs associated with various resources like images, videos, objects, CSS, and iframes for potential vulnerabilities.

• Focus on injection points (sinks) where an attacker can include client-side code, potentially leading to XSS vulnerabilities. These include tags and methods such as:

  • Frame: iframe src

  • Link: a href

  • AJAX Request: xhr.open(method, [url], true); URL

  • CSS: link href

  • Image: img src

  • Object: object data

  • Script: script src

Test For Cross Origin Resource Sharing - WSTG-CLNT-07

• Look for “Access-Control-Allow-Origin” on the response

• Use the CORS HTML exploit code for further exploitation

• Manually identify if the application allows user inputs to specify external resources without proper validation.

• Investigate client-side scripts handling URLs associated with various resources like images, videos, CSS, iframes, etc., for potential vulnerabilities.

• Check for possible injection points or sinks, such as the src attribute in iframes, href in links, URLs in AJAX requests (xhr.open method), and the src attribute in script tags.

• Focus on sinks that allow client-side code injection, which could lead to cross-site scripting (XSS) vulnerabilities.

Testing for Cross Site Flashing - WSTG-CLNT-08

• Create a simple web page with an iframe containing the target site to test if it can be loaded in an inline frame.

• If the target site loads in the frame, it's vulnerable to clickjacking; if not, it may have some form of protection.

• Test for Frame Busting bypass using techniques like Double Framing, Disabling JavaScript, or exploiting XSS filters in browsers.

• Explore client-side protections like Frame Busting scripts, and server-side protections such as the X-FRAME-OPTIONS header.

• Consider the less complex nature of mobile website versions which may have fewer protections against such attacks.

Test For Clickjacking - WSTG-CLNT-09

• Create a simple web page with an iframe containing the target site to test if it can be loaded in an inline frame.

  • If using Burp Suite, consider using ClickBandit: https://portswigger.net/burp/documentation/desktop/tools/clickbandit

• If the target site loads in the frame, it's vulnerable to clickjacking; if not, it may have some form of protection.

• Test for Frame Busting bypass using techniques like Double Framing, Disabling JavaScript, or exploiting XSS filters in browsers.

• Consider the less complex nature of mobile website versions which may have fewer protections against such attacks.

• Ensure “X-Frame-Options” headers are enabled

• Exploit with iframe HTML code for POC

Testing WebSockets - WSTG-CLNT-10

• Identify WebSocket usage by inspecting client-side code for ws:// or wss:// URI schemes, using Chrome’s Developer Tools, or ZAP's WebSocket tab.

• Test origin handling by attempting to connect with a WebSocket client; if successful, the server may not be validating the origin header.

• Ensure WebSocket connections use TLS (wss://) for confidentiality and integrity, and check for HTTPS implementation issues.

• Perform standard black-box authentication and authorization tests, as WebSockets don't handle these.

• Use ZAP to replay and fuzz WebSocket requests and responses for input sanitization.

Testing Web Messaging - WSTG-CLNT-11

• Ensure the application filters and processes messages only from trusted domains and that postMessage() does not use * for the target origin.

• Check for message event listeners in code and verify domains before data manipulation to prevent security risks.

• Treat data from web messages as untrusted, and check for insecure methods like eval() or innerHTML, which can lead to DOM-based XSS vulnerabilities.

• Perform static code analysis on JavaScript to assess restrictions on messages from untrusted domains and data handling for trusted ones.

Testing Browser Storage - WSTG-CLNT-12

• Test localStorage by listing all key-value entries, noting that entries persist even after the browser window closes, except in Private/Incognito mode.

• Examine sessionStorage similarly; its entries are ephemeral and cleared when the browser tab/window is closed.

• Inspect IndexedDB, which stores more than strings, including complex JavaScript objects like CryptoKeys. Ensure CryptoKeys are set to extractable: false for security.

• Review cookies for session management and arbitrary data storage; they are key-value storage mechanisms.

• Check the global window object for custom attributes, as any data attached will be lost on page refresh or close.

Testing for Cross-Site Script Inclusion (XSSI) - WSTG-CLNT-13

• Collect data using both authenticated and unauthenticated sessions to identify endpoints sending sensitive data, focusing on dynamically generated JavaScript responses.

• Check for sensitive data leakage through global variables, global function parameters, CSV with quotations theft, JavaScript runtime errors, and prototype chaining using this.

• Test global variables and function parameters for leaks by creating a mock attack site that includes the victim's JavaScript files.

• Inject JavaScript into CSV data to test for data leakage.

• Exploit JavaScript runtime errors in older browsers (like IE9/10) and prototype chaining vulnerabilities to leak sensitive data.

OTHER COMMON ISSUES

Test For No-Rate Limiting

• Ensure rate limiting is enabled

  • Example responses: x-rate-limit:, x-rate-limit-remaining:, Retry-After:

• Try to bypass rate limiting by changing the case of the endpoints

• Try to bypass rate limiting by adding / at the end of the URL

• Try to bypass rate limiting by adding HTTP headers

• Try to bypass rate limiting by adding HTTP headers twice

• Try to bypass rate limiting by adding Origin headers

• Try to bypass rate limiting by IP rotation

• Try to bypass rate limiting by using null bytes at the end

• Try to bypass rate limiting by using race conditions

Test For EXIF Geodata

• Ensure the website is striping the geodata

• Test with EXIF checker

Test For Broken Link Hijack

• Ensure there is no broken links are there

• Test broken links by using the blc tool

Test For SPF

• Ensure the website is having SPF record

• Test SPF by nslookup command

Test For Weak 2FA

• Try to bypass 2FA by using poor session management

• Try to bypass 2FA via the OAuth mechanism

• Try to bypass 2FA via brute-forcing

• Try to bypass 2FA via response manipulation

• Try to bypass 2FA by using activation links to login

• Try to bypass 2FA by using status code manipulation

• Try to bypass 2FA by changing the email or password

• Try to bypass 2FA by using a null or empty entry

• Try to bypass 2FA by changing the boolean into false

• Try to bypass 2FA by removing the 2FA parameter on the request

Test For Weak OTP Implementation

• Try to bypass OTP by entering the old OTP

• Try to bypass OTP by brute-forcing

• Try to bypass OTP by using a null or empty entry

• Try to bypass OTP by response manipulation

• Try to bypass OTP by status code manipulation