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:

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

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)

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

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

Enumerate Infrastructure & Admin Interfaces - WSTG-CONF-05

Testing HTTP Methods - WSTG-CONF-06

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

Test Account Provisioning Process - WSTG-IDNT-03

Testing For Account Enumeration - WSTG-IDNT-04

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

Test For Bypassing Authentication Schema - WSTG-ATHN-04

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

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

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

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

AUTHORIZATION TESTING

Testing Directory Traversal File Include - WSTG-ATHZ-01

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

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

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

Test For Cookie Attributes - WSTG-SESS-02

Test For Session Fixation - WSTG-SESS-03

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

Test For Weak Logout Functionality - WSTG-SESS-06

Test For Session Timeout - WSTG-SESS-07

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

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

Test For HTTP Parameter Pollution - WSTG-INPV-04

Test For SQL Injection - WSTG-INPV-05

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

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 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

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

WEAK CRYPTOGRAPHY TESTING

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