WEB APP PENTESTING CHECKLIST

PreviousChecklists NextAPI Testing Checklist

Last updated 5 months ago

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 -

Perform Google Dorks search
- Effective dorks in the
Perform OSINT for as much public information as possible from online resources
Utilize 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.

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

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

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.

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.

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

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.

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.

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

Check for Adobe’s Cross Domain Policy
Ensure it has the least privilege

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

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"

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.

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

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

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

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.

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.

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.

AUTHORIZATION TESTING

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

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

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

WEAK CRYPTOGRAPHY TESTING

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

Look for URL redirect parameters
Test for URL redirection on domain parameters
Test for URL redirection by using a payload list