1.1 - Conduct Search Engine Discovery Reconnaissance for Information Leakage
Check relevant GHDB (https://www.exploit-db.com/google-hacking-database) queries to identify potential information leakage.
Utilize automation tools such as Metagoofil to search and download specific file types or other sensitive information.
Utilize automation tools such as Metagoofil to search and download specific file types or other sensitive information.
Conduct searches using specialized search engines like Shodan to identify internet-facing devices or systems that might be vulnerable to exploitation or information leakage.
Perform OSINT (https://osintframework.com/)
1.2 -Fingerprinting Web Server
Use banner grabbing to analyze response headers from the web server.
Analyze the HTTP response to identify server software, version, and other details unique to the HTTP response.
Analyze the SSL certificate to identify server software, version, and other details.
Use automated tools like Nmap, WhatWeb, and Wappalyzer to send requests to the web server and analyze the response. Note that permission from the owner of the web server is necessary before using these tools.
Use tools like Netcat, Curl, and Wget for banner grabbing and data transfer between client and server.
Send requests with invalid headers, parameters, methods, or HTTP versions to test the web server's response.
Use automation tools like httprint, Wappalyzer, WhatWeb, and Nuclei templates to identify web technologies and server software.
1.3 -Review Webserver Metafiles for Information Leakage
Use Burp Suite or ZAP to automate the process of identifying sensitive information present in webserver metafiles.
Check META tag: Check if there is any “” entry present in the web pages. If not, then the “Robots Exclusion Protocol” defaults to “INDEX,FOLLOW” respectively.
Analyze the contents: Analyze the contents of each metafile to identify any sensitive information that may be disclosed, such as directory paths, usernames, passwords, or confidential data.
1.4 -Enumerate Applications on Webserver
Identify the scope of your testing, including the web server IP address or domain name and the port(s) to scan.
Use automated scanning tools like Nmap or Nessus to scan for open ports and running services on the web server.
Analyze the web server homepage by reviewing the HTML and JavaScript code for any references to web applications.
Manually browse through directories and subdirectories on the server to identify web applications.
Use directory and file brute-forcing tools like DirBuster, wfuzz, gobuster, or Burp Suite to find hidden web applications.
Once web applications have been identified, try appending different file extensions like “.php,” “.asp,” and “.aspx” to the application URLs to see if the server can process them.
Use vulnerability scanners to identify any known vulnerabilities in the web server or its applications.
1.5- Review Webpage Content for Information Leakage
Review the HTML code of the webpage to look for any metadata tags or comments.
Identify any potentially sensitive information that may have been leaked through the comments and metadata. This can include version numbers, system paths, internal IP addresses, and other confidential data.
Review the page source of the webpage to determine if any comments or metadata have been hidden from view.
Use automated scanning tools like Burp Suite or OWASP ZAP to identify metadata that may have been missed during a manual review.
1.6 -Identify Application Entry Points
Conduct a thorough analysis of the application's architecture and components to identify potential entry points.
Review documentation and diagrams of the application's architecture to identify potential entry points.
Use web application scanners such as Burp Suite, OWASP ZAP, or Nikto to scan the application and identify potential entry points.
Sub-Heading
Select All
Checklist Item
Justification
2.1 - Test Network Infrastructure Configuration
Scan the all reachable port
Run the security scan using some automation tool such as OpenVAS, Nessus.
2.3 - Test File Extensions Handling for Sensitive Information
Scan the application with automation tool such as Burp Suite.
Perform directory fuzzing as per application technology. Below are some wordlists:
2.3 - Test File Extensions Handling for Sensitive Information
Use vulnerability scanners, spidering and mirroring tools, and querying search engines to identify files with a given extension. connection.inc, .config, .asa
Manually inspect the application to identify sensitive files.
Validate that no sensitive information is being disclosed through file extensions.
2.5 - Enumerate Infrastructure and Application Admin Interfaces
Directory and file enumeration: An administrative interface may be present but not visibly available to the tester. The path of the administrative interface may be guessed by simple requests such as /admin or /administrator.
Comments and links in source code.
Parameter tampering: A GET or POST parameter, or a cookie may be required to enable the administrator functionality. Clues to this include the presence of hidden fields such as:
2.6 - Test HTTP Methods
Discover the supported methods by making an OPTIONS request to the server.
Test for access control bypass by attempting to use non-standard HTTP methods.
Test HTTP method overriding techniques by attempting to use a different HTTP method than the one intended.
2.7 - Test HTTP Strict Transport Security
Confirm the presence of the HSTS header by examining the response headers of the web application.
2.8 - Test RIA Cross Domain Policy
Locate the cross-domain policy file of the RIA by examining the web application's source code or by using a web application scanner.
Review the contents of the cross-domain policy file (Crossdomain.xml vs. Clientaccesspolicy.xml) and check if it restricts access to sensitive data and services.
2.9 - Test File Permission
Identify the files and directories that require file permission testing, including web files/directory, configuration files/directory, and sensitive files.
Review the file permissions of the identified files and directories and check if they are properly configured and secured.
2.11 - Test Cloud Storage
Access Control: Are there any publicly accessible storage buckets?
Access Control: Are permissions set correctly for users and roles?
Access Control: Can unauthorized users access sensitive files?
Data Exposure: Are sensitive files exposed to the public?
Data Exposure: Is there a mechanism to report or remove exposed data?
Encryption: Is data encrypted at rest?
Encryption: Is data encrypted in transit?
Encryption: Are encryption keys managed securely?
Authentication: Are strong passwords enforced?
Authentication: Is multi-factor authentication implemented?
Authentication: Are there any default credentials in use?
Backup and Recovery: Are backups taken regularly?
Backup and Recovery: Is there a tested recovery plan in place?
Backup and Recovery: Is versioning enabled for data recovery?
2.12 - Test for Content Security Policy
The Pentester examines the HTTP response headers and confirms the presence of the "Content-Security-Policy" header.
Sub-Heading
Select All
Checklist Item
Justification
3.1 Test Role Definitionsn
Role Definitions: Are roles defined with appropriate permissions?
Role Definitions: Is there a clear distinction between roles?
Role Definitions: Are roles documented and easily understandable?
Role Assignment: Are users assigned to roles based on their job functions?
Role Assignment: Are there any users with excessive permissions?
Access Control: Do users have access only to resources they are authorized to use?
Access Control: Can users perform actions that their role should not allow?
Privilege Escalation: Can users modify their own roles or the roles of others?
Privilege Escalation: Are there any vulnerabilities that allow privilege escalation?
Role Management: Is there an audit trail for role changes?
Role Management: Is there a process for reviewing and updating role definitions?
3.2 Test User Registration Process
Input Validation: Are user inputs properly validated and sanitized?
Input Validation: Do error messages reveal sensitive information?
Account Enumeration: Can valid and invalid usernames or emails be distinguished through error messages?
Password Policy: Are strong password requirements enforced?
Password Policy: Are common passwords disallowed?
CAPTCHA: Is CAPTCHA implemented to prevent automated registrations?
CAPTCHA: Can CAPTCHA be bypassed?
Email Verification: Is an email verification process in place?
Email Verification: Can users access the application without verifying their email?
Security Questions: Are security questions effective against social engineering attacks?
Security Questions: Are there common answers that could be easily guessed?
Identity Requirements: Can anyone register for access?
Identity Requirements: Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
Identity Requirements: Can the same person or identity register multiple times?
Identity Requirements: Can users register for different roles or permissions?
Identity Requirements: What proof of identity is required for a registration to be successful?
Identity Requirements: Are registered identities verified?
Registration Process: Can identity information be easily forged or faked?
Registration Process: Can the exchange of identity information be manipulated during registration?
3.3 Test Account Provisioning Process
Role Assignments: Are roles assigned based on the principle of least privilege?
Role Assignments: Can users be assigned roles they should not have?
Access Controls: Are there proper access controls to prevent unauthorized account creation?
Access Controls: Can users modify or delete accounts they do not own?
Account Deactivation: Is there a secure process for deactivating accounts?
Account Deactivation: Are deactivated accounts truly inaccessible?
Automation: Are automated provisioning processes secure?
Automation: Are there any hard-coded credentials or security flaws in the automation scripts?
Audit Trails: Are account provisioning activities logged?
Audit Trails: Is sensitive information masked in the logs?
3.4 Testing for Account Enumeration and Guessable User Account
Account Enumeration: Can the application reveal valid or invalid user accounts?
Account Enumeration: Are error messages consistent and not informative?
Guessable User Accounts: Can user accounts be easily guessed or predicted?
Guessable User Accounts: Are there any measures in place to prevent guessable user accounts?
Password Recovery: Is the password recovery process secure and does not expose user accounts?
Password Recovery: Are there any limitations on the number of password recovery attempts?
3.5 Testing for Weak or Unenforced Username Policy
Username Format: Does the application enforce a specific format for usernames?
Username Format: Are special characters or spaces allowed in usernames?
Username Length: Is there a minimum length requirement for usernames?
Username Length: Is there a maximum length limit for usernames?
Uniqueness: Does the application prevent duplicate usernames?
Uniqueness: Are users notified if a username is already taken?
Predictability: Can common or easily guessable usernames be registered?
Predictability: Are there any restrictions on using common usernames (e.g., "admin", "test")?
Error Messages: Are error messages informative without revealing sensitive information?
Error Messages: Do error messages provide hints about valid username formats or existing usernames?
Sub-Heading
Select All
Checklist Item
Justification
4.2 Testing for Default Credentials
Enumerate the applications for default credentials and validate if they still exist.
4.3 Testing for Weak Lock Out Mechanism
Determine the criteria for triggering a lockout (e.g., number of failed login attempts, time period).
Test the lockout mechanism by exceeding the allowed number of failed login attempts.
Determine if the lockout mechanism is triggered as expected and denies access.
Assess whether the lockout period is appropriate and provides sufficient protection against brute-force attacks.
Test the lockout mechanism for bypass using automated tools or techniques.
Evaluate the effectiveness of any CAPTCHA implementation in preventing automated attacks.
4.4 Testing for Bypassing Authentication Schema
Test for direct page request (forced browsing) to identify unprotected pages.
Attempt parameter modification to gain unauthorized access to protected areas.
Check for predictable session ID generation and potential session hijacking.
Test for SQL injection vulnerabilities in the authentication process.
Assess the application's source code for potential vulnerabilities and weak comparisons.
4.5 Testing for Vulnerable Remember Password
Review the implementation of the "Remember Password" feature.
Identify where remembered passwords are stored.
Evaluate encryption and security measures for stored passwords.
Test the password retrieval process for authentication.
Verify the presence of expiry and revocation mechanisms for saved passwords.
Assess CORS policies to prevent unauthorized access to stored passwords.
Evaluate error handling for remembered password-related scenarios.
4.6 Testing for Browser Cache Weaknesses
Understand how the web application utilizes browser caching.
Review Cache-Control headers for caching directives.
Inspect HTTPS configuration for encryption of sensitive data.
Test for cache poisoning by manipulating caching headers or parameters.
Verify cache clearing mechanisms for users to remove sensitive data.
Check CORS policies to prevent unauthorized access to cached sensitive data.
Test for persistence of sensitive data across sessions in the browser cache.
4.7 Testing for Weak Password Policy
Evaluate character requirements for passwords.
Assess the complexity requirements for passwords, including minimum length and the use of special characters.
Check for restrictions on password reuse.
Evaluate if the application enforces password aging policies.
4.8 Testing for Weak Security Question Answer
Review security questions for predictability.
Manually attempt guessing answers.
Use automation tools to brute force common answers.
Check if attempt limits are applied.
Test account access with known question-answer pairs.
4.9 Testing for Weak Password Change or Reset Functionalities
Assess the strength of the reset process compared to authentication.
Check for protections against automated attacks.
Evaluate vulnerability to common attacks such as SQL injection or cross-site scripting.
Review email-based reset mechanisms for security.
Assess the security of tokens sent via SMS or phone call.
Consider the effectiveness of using security questions for authentication.
Verify the need for re-authentication before changing passwords.
Check for vulnerabilities like CSRF in the password change form.
Evaluate the strength and effectiveness of the applied password policy.
Sub-Heading
Select All
Checklist Item
Justification
5.1 - Testing Directory Traversal File Include
Utilize security scanning tools (e.g., Burp Suite, OWASP ZAP) to identify potential directory traversal and file inclusion vulnerabilities.
Configure scanners to manipulate input parameters and analyze responses for anomalies.
Employ fuzz testing tools to generate a variety of input combinations, including potential traversal attempts.
Analyze application responses for unexpected behavior.
5.2 - Testing for Bypassing Authorization Schema
Review and understand the application's access control policies and configurations.
Verify access based on different user roles.
Test for access to resources restricted to higher-privileged users.
Attempt to access administrative functions with non-administrative user credentials.
Test how the application handles special request headers, such as X-Forwarded-For or X-Original-URL.
Explore if manipulating these headers can lead to unauthorized access or bypass of security controls.
5.3 - Testing for Privilege Escalation
Verify that it is not possible to modify user privileges or roles.
Test for the ability to access resources or functions that should be restricted to higher-privileged users.
Attempt to access administrative functions with non-administrative user credentials.
5.4 - Testing for Insecure Direct Object References
Identify Input Points: Enumerate all input points where the application interacts with user-controlled data, such as URLs, parameters, and form fields.
Manipulate Object References: Systematically manipulate object references by altering values in URLs, parameters, or input fields.
Test Direct Object References: Attempt to access objects directly by tampering with identifiers or references in requests.
Enumerate and Brute Force: Enumerate potential object references and perform brute-force attacks to discover hidden or sensitive data.
5.5 - Testing for OAuth Weaknesses
Inspect OAuth Configuration: Review client ID, client secret, and OAuth endpoints for proper configuration.
Inspect OAuth Configuration: Check for the use of insecure client secrets.
Check Token Validation: Attempt to use invalid or tampered access tokens.
Check Token Validation: Verify that the application validates tokens issued by legitimate authorization servers.
Test Token Storage and Handling: Assess token storage and handling practices.
Test Token Storage and Handling: Check for vulnerabilities such as insecure storage or transmission of tokens.
Explore Token Scope Limitations: Test if the application enforces proper OAuth token scopes.
Explore Token Scope Limitations: Attempt to access resources with tokens that have limited scopes.
Examine Redirect URI Security: Verify that redirect URIs are securely registered and trusted.
Examine Redirect URI Security: Test for open redirect vulnerabilities.
Test for Token Expiration Handling: Use expired tokens to check how the application handles token expiration.
Test for Token Expiration Handling: Verify that tokens are automatically refreshed or reauthorized as needed.
Sub-Heading
Select All
Checklist Item
Justification
6.1 Testing for Session Management Schema
Session Creation:
Verify that session tokens are securely generated using a cryptographically strong random number generator.
Ensure session identifiers are unique and not easily guessable.
Check for any predictable patterns or sequences in session token generation.
Session Management:
Test session timeout by keeping a session idle for the configured duration and then making a request.
Validate session persistence across different application functions and pages.
Check if session-related cookies are marked with secure and HttpOnly flags.
Session Termination:
Test logout functionality to ensure it effectively terminates the session.
Verify that session data is cleared both client-side (cookies) and server-side upon logout.
Assess how the application handles session expiration due to user inactivity.
Session Token Handling:
Examine how session tokens are transmitted (e.g., over HTTPS, not in URLs).
Review session token storage mechanisms to ensure they are not exposed to client-side scripting (e.g., XSS).
Check for token regeneration upon privilege level changes or sensitive actions (e.g., password change).
6.2 Testing for Cookies Attributes
Check if session cookies are marked with the secure flag such as Secure , HTTPOnly , SameSite and so on.
6.3 Testing for Session Fixation
Check if a new session ID is issued upon successful authentication.
Attempt to send a valid session identifier to a user and verify privilege assignment.
6.4 Testing for Exposed Session Variables
How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields).
Are Session IDs always sent over encrypted transport by default?
Is it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTPS to HTTP?
What cache-control directives are applied to requests/responses passing Session IDs?
Are these directives always present? If not, where are the exceptions?
Are GET requests incorporating the Session ID used?
If POST is used, can it be interchanged with GET?
6.5 Testing for Cross Site Request Forgery
List out critical actions that require authentication (e.g., changing settings, making transactions).
Identify if the application uses anti-CSRF tokens or headers like SameSite cookies.
Create a proof-of-concept CSRF attack to test against identified critical functionalities.
Explore how CSRF might affect different user roles and scenarios within the application.
Analyze if the application has implemented effective CSRF protections (e.g., unique tokens per session, enforcing Referer headers).
6.6 Testing for Logout Functionality
Test the functionality of the logout button or URL to ensure it effectively terminates the session.
Inspect cookies, local storage, and session storage to confirm that sensitive information is cleared upon logout.
Attempt to access authenticated resources after logout to verify proper redirection to the login page.
Determine the configured session timeout duration and test if sessions expire after this duration of inactivity.
6.8 Testing for Session Puzzling
Determine how session IDs are created (e.g., random strings, timestamps, user-specific data).
Attempt to manually guess session IDs based on patterns or common sequences.
Employ automated tools or scripts to brute-force session IDs and identify vulnerabilities.
6.9 Testing for Session Hijacking
Session Token Strength:
Are session tokens unpredictable and sufficiently long?
Is a secure algorithm used for token generation?
Cookie Security:
Are the HttpOnly and Secure flags set for session cookies?
Is the SameSite attribute configured properly?
Session Fixation:
Can an attacker set a session ID before authentication?
Does the application regenerate session IDs after login?
Session Expiration:
Does the application have a session timeout policy?
Is the session invalidated after logout?
Replay Attacks:
Can captured session tokens be reused to access the application?
Are there mechanisms in place to detect and prevent replay attacks?
6.10 Testing JSON Web Tokens
Inspect JWT Structure: Ensure it follows the standard format and doesn't expose sensitive data.
Verify Algorithm: Check for strong, secure algorithms and reject none algorithm.
Validate Signatures: Ensure signatures are validated using the correct keys.
Check Expiration: Ensure JWTs have a reasonable expiration time and are properly enforced.
Verify Audience and Issuer: Ensure JWTs have the correct aud and iss claims.
Test for Replay Attacks: Ensure tokens cannot be reused inappropriately.
Review Key Management: Ensure secure storage and rotation of JWT keys.
6.11 Testing for Concurrent Sessions
Capture a valid session token (e.g., cookie or JWT) during user login.
Attempt to create multiple active sessions using the same token.
Test the application's behavior when accessing it with the same token from different browser instances.
Evaluate the application's handling of concurrent sessions originating from the same IP address.
Assess the application's ability to manage concurrent sessions from different IP addresses and locations.
Sub-Heading
Select All
Checklist Item
Justification
7.1 Testing for Reflected Cross Site Scripting
Identify all user input points in the application.
Craft a variety of XSS payloads.
Submit payloads via GET and POST requests.
Test for different input encodings.
Check for script execution in the response.
Evaluate the effectiveness of any input validation or sanitization mechanisms.
7.2 Testing for Stored Cross Site Scripting
Locate all places where user input is stored and can be retrieved later (e.g., user profiles, comments, messages).
Use a variety of payloads to test for different contexts and encodings.
Ensure payloads are stored correctly and executed when retrieved.
Check if the payload is executed when the stored data is retrieved and rendered.
Look for signs of script execution like alerts, changes in HTML structure, or unexpected behaviors.
Attempt to bypass input filters using different encoding methods (e.g., URL encoding, HTML encoding).
7.4 Testing for HTTP Parameter Pollution
Identify all user input points that accept GET or POST parameters.
Craft payloads with duplicate parameters having the same name but different values.
7.5 Testing for SQL Injection
Verify all potential input vectors (forms, URLs, headers, etc.).
Use a range of SQL injection payloads including simple, union-based, error-based, and blind injections.
Look for error messages, unexpected behaviors, or changes in application response time.
Confirm the injection is possible and determine the impact (e.g., unauthorized data access, database modification).
7.6 Testing for LDAP Injection
Identify all input fields and parameters that interact with LDAP systems.
Develop and collect a range of LDAP injection payloads to test different aspects of LDAP queries.
Test each input field with your prepared payloads and observe the application's behavior.
Look for signs of LDAP query manipulation, such as unauthorized data access or system errors.
7.7 Testing for XML Injection
Identify all input fields that accept XML data (GET, POST, file uploads).
Test for common XML injection payloads.
Check for error messages indicating XML processing issues.
Use automated tools to scan for vulnerabilities.
Conduct blind injection tests to infer data.
7.8 Testing for SSI Injection
List all fields and parameters that might be processed by SSI (e.g., file uploads, URL parameters).
Test for SSI injection vulnerabilities using both manual and automated methods.
Check for the presence of .shtml files or other indicators of SSI support.
Test for common SSI injection payloads.
7.9 Testing for XPath Injection
Identify all input fields that accept user data (GET, POST, headers).
Test for common XPath injection payloads.
Check for error messages indicating XPath processing issues.
7.10 Testing for IMAP SMTP Injection
Identify potential IMAP/SMTP injection points in the web application.
Test for IMAP/SMTP injection vulnerabilities using both manual and automated methods.
Analyze application responses for signs of IMAP/SMTP injection.
Attempt to exploit the vulnerabilities to demonstrate impact (e.g., unauthorized emails sent).
7.11 Testing for Code Injection
Identify Input Fields: List all fields where user input is accepted.
Test for Code Execution: Submit known payloads that could execute code (e.g., <?php phpinfo(); ?>).
Check Response Codes: Monitor HTTP response codes and application behavior after submitting payloads.
7.11.1 Testing for File Inclusion
File Inclusion Vulnerability Testing Checklist
Identify Input Parameters: List all input fields that might accept file paths.
Test for RFI: Use payloads to attempt including remote files.
Test for LFI: Use directory traversal techniques to access sensitive local files.
Check Error Messages: Analyze any error messages returned by the application for clues about file paths and vulnerabilities.
7.12 Testing for Command Injection
Command Injection Vulnerability Testing Checklist
Identify input fields and parameters that could interact with the system shell.
Test with common command injection characters (;, &&, |, etc.).
Observe server responses and look for evidence of unintended command execution.
If direct responses are not shown, attempt blind command injection using time delays or external calls (e.g., DNS requests).
Ensure testing is done on different OS platforms (Windows, Linux) with appropriate system commands.
Use automation tools like Burp Suite or OWASP ZAP/Commix to assist in finding injection points.
7.13.1 Testing for Format String Injection
Identify input fields where user input might be passed to formatting functions (e.g., error messages, logging, string outputs).
Inject common format specifiers such as %s, %x, %d, and observe the application's response.
Check for unexpected outputs like memory addresses, crash reports, or sensitive data leaks.
Use %n specifier to test if it's possible to write data to memory (this can signal a critical vulnerability).
Conduct blind format string injection by reviewing server logs and monitoring error messages for unintended output.
7.14 Testing for Incubated Vulnerability
Identify all user input points in the application.
Send various payloads and inputs to dormant inputs, including known vulnerabilities like SQLi or XSS.
Analyze how the application handles and processes inputs intended for dormant features, looking for vulnerabilities or unexpected behavior.
7.15 Testing for HTTP Splitting Smuggling
Identify all input points that can influence HTTP headers.
Submit payloads with CR and LF characters. Analyze responses for signs of splitting.
Look for conflicting Content-Length and Transfer-Encoding headers. Send crafted requests and analyze server behavior.
7.16 Testing for HTTP Incoming Requests
Identify all input points that can influence HTTP headers.
Submit payloads with CR and LF characters. Analyze responses for signs of splitting.
Look for conflicting Content-Length and Transfer-Encoding headers. Send crafted requests and analyze server behavior.
7.17 Testing for Host Header Injection
Identify Points of Host Header Usage: Look for places where the application uses the Host header, such as URL generation and redirects.
Test Host Header Manipulation: Modify the Host header to check if the application trusts the injected value.
Check for Password Reset Poisoning: Manipulate the Host header during password reset requests to see if the generated link uses your malicious domain.
Test for Cache Poisoning: Attempt to poison the cache by injecting a malicious Host header and analyzing how the application caches content.
Analyze Logs and Responses: Ensure that manipulated Host headers do not appear in server logs or responses, and that no unexpected behavior occurs.
7.18 Testing for Server-side Template Injection
Look for functions that fetch URLs, generate previews, or handle external resources: Identify areas in the application that interact with external resources.
Attempt to use internal IP addresses, local addresses (127.0.0.1), or metadata services in your input: Probe internal networks for potential SSRF vulnerabilities.
Test if the server can send requests to external domains under your control: Confirm outbound SSRF by checking if the server can reach your controlled domains.
Check if the server’s response leaks sensitive information: Analyze responses for any sensitive data or evidence that the request was made.
Ensure the application has adequate filtering mechanisms: Verify that the application prevents requests to internal systems or unauthorized external services.
7.20 Testing for Mass Assignment
Locate where user input is mapped directly to internal objects: Identify areas where user input can directly affect internal objects, such as user profiles or transactions.
Test adding unexpected parameters to the request body or URL: Attempt to include parameters like roles, permissions, or financial data to see how the application responds.
Determine if the server accepts and applies unauthorized changes: Check if the application allows unauthorized modifications, indicating a potential mass assignment vulnerability.
Check if the application restricts certain fields from being modified: Verify if the application implements whitelisting for allowed fields to prevent unauthorized changes.
Sub-Heading
Select All
Checklist Item
Justification
8.1 Testing for Improper Error Handling
Submit invalid data or requests to trigger errors and observe the application's error handling.
Check if detailed error messages reveal sensitive information like file paths, database errors, or stack traces.
Sub-Heading
Select All
Checklist Item
Justification
9.1 Testing for Weak Transport Layer Security
Identify all endpoints that use TLS for secure communication.
Check the supported versions of TLS and ensure only TLS 1.2 or higher is enabled.
Evaluate the cipher suites used by the application and ensure only strong cipher suites are supported.
Verify the validity of SSL/TLS certificates, including expiration and issuer trust.
Perform SSL/TLS scans to identify vulnerabilities and weaknesses in the configuration.
9.2 Testing for Padding Oracle
Determine encryption method : Identify the encryption algorithm (e.g., AES, DES) and the mode (e.g., CBC).
Check for error messages: Look for application responses indicating padding errors.
Alter ciphertext: Modify ciphertext blocks and analyze the responses.
Craft and launch attack: Use manual methods or tools like PadBuster to exploit the padding oracle vulnerability.
Validate the impact: Confirm the extent of the data leakage and its potential risk to the application (e.g., session hijacking, sensitive data disclosure).
9.3 Testing for Sensitive Information Sent via Unencrypted Channels
Ensure all sensitive data (e.g., login forms, payment info) is transmitted via HTTPS.
Ensure that only secure versions of TLS (1.2 or higher) are used, and older protocols like SSLv2 or SSLv3 are disabled.
Ensure that HTTP Strict Transport Security (HSTS) headers are set to enforce HTTPS usage.
9.4 Testing for Weak Encryption
Verify the algorithms used in the application (e.g., AES, RSA).
Ensure the application does not use weak algorithms like MD5, SHA-1, or RC4.
Ensure encryption keys are securely stored and managed.
Sub-Heading
Select All
Checklist Item
Justification
10.00 Introduction to Business Logic Testing
Gain a thorough understanding of the application’s business logic, workflows, and rules.
Identify where business logic could be exploited or bypassed by attackers (e.g., double submission, price manipulation).
Verify that users cannot bypass restrictions based on their role or permissions.
Try changing the sequence of operations or altering parameters to see if you can bypass business rules.
Test if actions like submitting forms multiple times or replaying requests can exploit the business logic (e.g., triggering duplicate payments or orders).
10.1 Test Business Logic Data Validation
Understand business rules: Ensure you have a clear understanding of the core business logic rules, workflows, and expected behaviors.
Identify critical data points: Focus on data inputs that directly affect the business logic (e.g., prices, discounts, user roles).
Manipulate data inputs: Test for logical data manipulation (e.g., altering prices, applying unauthorized discounts).
Test edge cases: Look for scenarios like submitting negative values, skipping steps, or reordering workflow steps to exploit business logic flaws.
Check for inconsistent validation: Ensure that the same validation rules are enforced consistently across all relevant parts of the application.
10.2 Test Ability to Forge Requests
Review application documentation and understand business logic workflows.
Use an interception proxy (e.g., Burp Suite) to capture HTTP requests.
Identify hidden fields and parameters in forms and URLs.
Modify request parameters and analyze responses for unexpected behavior.
Attempt to bypass critical steps in workflows (e.g., skipping payment confirmation).
Ensure all sensitive data (e.g., login forms, payment info) is transmitted via HTTPS.
Ensure that only secure versions of TLS (1.2 or higher) are used, and older protocols like SSLv2 or SSLv3 are disabled.
Ensure that HTTP Strict Transport Security (HSTS) headers are set to enforce HTTPS usage.
10.3 Test Integrity Checks
Identify critical business data that should not be tampered with (prices, transaction IDs, user roles, etc.).
Intercept key requests and modify values like prices or quantities.
Test if hidden form fields can be altered and sent back to the server.
Check if the server properly validates data integrity (e.g., recalculating totals or checking for unauthorized modifications).
Attempt replay attacks to submit altered data multiple times.
Ensure that data integrity checks are server-side, not just client-side.
10.4 Test for Process Timing
Identify critical workflows that rely on timing or sequence of operations.
Test if time-sensitive processes (like sessions or deadlines) are properly enforced.
Send simultaneous or rapidly repeated requests to check for race conditions.
Test session expiration and timeout handling.
Check if rate limiting is implemented to prevent excessive requests in short timeframes.
Ensure proper synchronization in multi-step processes to avoid timing issues.
10.5 Test Number of Times a Function Can Be Used Limits
Identify functions that should have usage limits (e.g., promo codes, file uploads, reward redemptions).
Attempt to exceed these limits through repeated actions or requests.
Test the same functionality through different channels (web, API, mobile) to see if limits are consistently enforced.
Send replayed or simultaneous requests to check for race conditions or lack of usage tracking.
Verify if proper error messages are shown when limits are exceeded.
Verify the algorithms used in the application (e.g., AES, RSA).
Ensure the application does not use weak algorithms like MD5, SHA-1, or RC4.