RedTeam
0.Bookmark
Pentesting Approach

Pentesting Methodology

The set of active tests have been split into 12 categories:

  • Information Gathering
  • Configuration and Deployment Management Testing
  • Identity Management Testing
  • Authentication Testing
  • Authorization Testing
  • Session Management Testing
  • Input Validation Testing
  • Error Handling
  • Cryptography
  • Business Logic Testing
  • Client-side Testing
  • API Testing

https://owasp.org/www-project-web-security-testing-guide/stable/ (opens in a new tab)

Information Gathering

  • ===Search Engine Discovery (Dorking)===
    • network diagrams and configurations;
    • archived posts and emails by administrators or other key staff;
    • logon procedures and username formats;
    • usernames, passwords, and private keys;
    • third-party, or cloud service configuration files;
    • revealing error message content; and
    • development, test, User Acceptance Testing (UAT), and staging versions of sites.
  • ===Fingerprinting web server===
    • Banner Grabbing
    • Sending Malformed Requests
    • Review Webpage Content for Information Leakage
      • Meta tags
        • Robots META Tag
        • Miscellaneous META Information Tags
      • Sitemaps
      • Security.txt
      • JavaScript Code
    • HTTP headers
    • Cookies
      • Cookies names can lead in identifying framework
    • HTML source code
    • Specific files and folders
    • File extensions
    • Error messages
    • Cookies names
    • Specific directory
      • Ex: wp-admin ---> Wordpress
    • File extension

Common Identifiers

Cookies
FrameworkCookie Name
Zopezope3
CakePHPcakephp
Kohanakohanasession
Laravellaravel_session
phpBBphpbb3_
WordPresswp-settings
1C-BitrixBITRIX_
AMPcmsAMP
Django CMSdjango
DotNetNukeDotNetNukeAnonymous
e107e107_tz
EPiServerEPiTrace, EPiServer
Graffiti CMSgraffitibot
Hotaru CMShotaru_mobile
ImpressCMSICMSession
IndicoMAKACSESSION
InstantCMSInstantCMS[logdate]
Kentico CMSCMSPreferredCulture
MODxSN4[12symb]
TYPO3fe_typo_user
DynamicwebDynamicweb
LEPTONlep[some_numeric_value]+sessionid
WixDomain=.wix.com
VIVVOVivvoSessionId
HTML Source Code
ApplicationKeyword
WordPress<meta name="generator" content="WordPress 3.9.2" />
phpBB<body id="phpbb"
Mediawiki<meta name="generator" content="MediaWiki 1.21.9" />
Joomla<meta name="generator" content="Joomla! - Open Source Content Management" />
Drupal<meta name="Generator" content="Drupal 7 (http://drupal.org)" />
DotNetNukeDNN Platform - [http://www.dnnsoftware.com](http://www.dnnsoftware.com)

Deployment Management Testing

  • ===File Extensions Handling for Sensitive Information===
    • Submit requests with different file extensions and verify how they are handled.
    • Web server directories can be identified by scanning tools which look for the presence of well-known directories
    • Verify directories that allow script execution
  • ===Old Backup and Unreferenced Files for Sensitive Informatio===
    • Enumerate all of the application’s pages and functionality. This can be done manually using a browser, or using an application spidering tool. Most applications use a recognizable naming scheme, and organize resources into pages and directories using words that describe their function. From the naming scheme used for published content, it is often possible to infer the name and location of unreferenced pages. For example, if a page viewuser.asp is found, then look also for edituser.asp, adduser.asp and deleteuser.asp. If a directory /app/user is found, then look also for /app/admin and /app/manager.
    • Check javascript files
    • Hidden forms input
    • Robot.txt
  • ===Enumerate Infrastructure and Application Admin Interfaces===
    • Directory and file enumeration
    • Comments and links in source code
    • Javascript files
    • Reviewing server and application documentation
    • Publicly available information
    • Parameter tampering. A GET or POST
  • ===HTTP Methods===
  • ===HTTP Strict Transport Security===
    • max-age: to indicate the number of seconds that the browser should automatically convert all HTTP requests to HTTPS.
    • includeSubDomains: to indicate that all related sub-domains must use HTTPS.
    • preload Unofficial: to indicate that the domain(s) are on the preload list(s) and that browsers should never connect without HTTPS.
    • This is supported by all major browsers but is not official part of the specification. (See hstspreload.org for more information.)
  • ===Cross Domain Policy===
    • allow-access-from domain="*"
    • CORS
    • SOP
  • ===File Permission===
    • namei -l /PathToCheck/
      • Web files/directory
      • Configuration files/directory
      • Sensitive files (encrypted data, password, key)/directory
      • Log files (security logs, operation logs, admin logs)/directory
      • Executables (scripts, EXE, JAR, class, PHP, ASP)/directory
      • Database files/directory
      • Temp files /directory
      • Upload files/directory
  • ===Subdomain Takeover===
    • The victim’s external DNS server subdomain record is configured to point to a non-existing or non-active resource/external service/endpoint.
    • The service provider hosting the resource/external service/endpoint does not handle subdomain ownership verification properly.
  • ===Cloud Storage===

Identity Management

  • ===Role===
    • Application documentation.
    • Guidance by the developers or administrators of the application.
    • Application comments.
    • Fuzz possible roles:
      • cookie variable (e.g. role=admin, isAdmin=True)
      • account variable (e.g. Role: manager)
      • hidden directories or files (e.g. /admin, /mod, /backups)
      • switching to well known users (e.g. admin, backups, etc.)
  • ===User Registration===
    • Can anyone register for access?
    • Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
    • Can the same person or identity register multiple times?
    • Can users register for different roles or permissions?
    • What proof of identity is required for a registration to be successful?
    • Are registered identities verified?
  • ===Account Provisioning===
    • Is there any verification, vetting and authorization of provisioning requests?
    • Is there any verification, vetting and authorization of de-provisioning requests?
    • Can an administrator provision other administrators or just users?
    • Can an administrator or other user provision accounts with privileges greater than their own?
    • Can an administrator or user de-provision themselves?
    • How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?
  • ===Account Enumeration/Guessable User Account===
    • HTTP Response (Testing Valid/Invalid accounts)
      • Status
      • Text on webpage
      • Redirection (Page)
      • Web Titles
      • Response Time
      • Recovery options messages
  • ==Weak unenforced username policy===
    • 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

  • ===Un-encrypted traffic (Search for password, cookies (Secure attribute), reset codes)===
    • Try forcing HTTP to see if proper redirection to HTTPS occurs.
      • Test for this in functionalities such as:
        • Password Reset
        • Change Password
        • Other Account Manipulation
      • Specifically, test:
        • Forms that allow users to handle a forgotten password or other credentials.
        • Forms that allow users to edit credentials.
        • Forms that require the user to authenticate with another provider (e.g., payment processing).
      • Accessing Resources While Logged In
        • After logging in, access all features, including public ones, and attempt to force-browse the HTTP version to check for credential leaks.
  • ===Default credentials===
    • Testing most common usernames/passwords
  • ===Weak lock out mechanism=== - Lockout threshold - Block via IP or user? - Race Condition (Bypass lockout) - 2 wrong password/1 good password (your account) - See if it reset threshold - CAPTCHA - Assess CAPTCHA challenges and attempt automating solutions depending on difficulty. - Attempt to submit request without solving CAPTCHA via the normal UI mechanism(s). - Attempt to submit request with intentional CAPTCHA challenge failure. - Attempt to submit request without solving CAPTCHA (assuming some default values may be passed by client-side code, etc) while using a testing proxy (request submitted directly server-side). - Attempt to fuzz CAPTCHA data entry points (if present) with common injection payloads or special characters sequences. - Check if the solution to the CAPTCHA might be the alt-text of the image(s), filename(s), or a value in an associated hidden field. - Attempt to re-submit previously identified known good responses. - Check if clearing cookies causes the CAPTCHA to be bypassed (for example if the CAPTCHA is only shown after a number of failures). - If the CAPTCHA is part of a multi-step process, attempt to simply access or complete a step beyond the CAPTCHA (for example if CAPTCHA is the first step in a login process, try simply submitting the second step [username and password]). - Check for alternative methods that might not have CAPTCHA enforced, such as an API endpoint meant to facilitate mobile app access. - Unlock Mechanism - Typical unlock mechanisms may involve secret questions or an emailed unlock link. The unlock link should be a unique one-time link, to stop an attacker from guessing or replaying the link and performing brute force attacks in batches.
  • ===Bypassing Authentication===
  • ===Remember Password===
  • ===Browser Cache Weaknesses===
    • Browser History
      • The first and simplest test consists of entering sensitive information into the application and logging out. Then the tester clicks the Back button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated.
      • If by pressing the Back button the tester can access previous pages but not access new ones, then it is not an authentication issue, but a browser history issue. If these pages contain sensitive data, it means that the application did not forbid the browser from storing it.
      • Authentication does not necessarily need to be involved in the testing. For example, when a user enters their email address in order to sign up to a newsletter, this information could be retrievable if not properly handled.
      • The Back button can be stopped from showing sensitive data. This can be done by:
        • Delivering the page over HTTPS.
        • Setting Cache-Control: must-revalidate
    • Browser Cache
      • Web Cache Poisoning
      • Web cache deception
  • ===Weak Password Policy===
    • What characters are permitted and forbidden for use within a password
    • How often can a user change their password
    • When must a user change their password (regular password expiry ---> PCI DSS)
    • How often can a user reuse a password
    • How different must the next password be from the last password
    • Is the user prevented from using username/other account information in the password
    • What are the minimum and maximum password lengths that can be set
    • Is it possible set common passwords such as Password1 or 123456
  • ===Weak Security Question Answer===
    • The answers may be known to family members or close friends of the user
    • The answers may be easily guessable (The answers may be brute forcible)
    • The answers may be publicly discoverable
  • ===Weak Password Change or Reset Functionalities===
    • If the password change or reset process is vulnerable to CSRF (opens in a new tab)
    • If users, other than administrators, can change or reset passwords for accounts other than their own
    • If users can manipulate or subvert the password change or reset process to change or reset the password of another user or administrator.
    • Race Condition (Reset 2 person password (Same token?))
    • HOST header (Possible to change the host header?)
  • ===Weaker Authentication in Alternative Channel===
    • Standard website
    • Mobile, or specific device, optimized website
    • Accessibility optimized website
    • Alternative country and language websites
    • Parallel websites that utilize the same user accounts (e.g. another website offering different functionally of the same organization, a partner website with which user accounts are shared)
    • Development, test, UAT and staging versions of the standard website

Authorization

  • ===Directory Traversal File Include===
    • Are there request parameters which could be used for file-related operations?
    • Are there unusual file extensions?
    • Are there interesting variable names?
      • http://example.com/getUserProfile.jsp?item=ikki.html
      • http://example.com/index.php?file=content
      • http://example.com/main.cgi?home=index.htm
      • Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
      • Cookie: ID=d9ccd3f4f9f18cc1:TEMPLATE=flower
    • Testing Techniques
      • Check Path Traversal Documentation
  • ===Bypassing Authorization Schema===
    • Access resources and conduct operations horizontally.
    • Access resources and conduct operations vertically.
    • Is it possible to access resources that should be accessible to a user that holds a different identity with the same role or privilege?
    • Is it possible to operate functions on resources that should be accessible to a user that holds a different identity?
    • For each role:
        1. Register or generate two users with identical privileges.
        1. Establish and keep two different sessions active (one for each user).
        1. For every request, change the relevant parameters and the session identifier from token one to token two and diagnose the responses for each token.
        1. An application will be considered vulnerable if the responses are the same, contain same private data or indicate successful operation on other users’ resource or data.
      • TEST DIFF FUNCTIONALITY WITH DIFF PERMISION with DIFF ROLES
      • Testing for Special Request Header Handling
        • X-Original-URL ---> Trying to overriding the target URL
        • X-Rewrite-URL ---> Trying to overriding the target URL
        • Others ---> Try adding a local address (Localhost, 127.0.0.1, ... All other possibilities)
          • X-Forwarded-For
          • X-Forward-For
          • X-Remote-IP
          • X-Originating-IP
          • X-Remote-Addr
          • X-Client-IP
  • ===Privilege Escalation===
    • Manipulation of User Group
    • Manipulation of User Profile
    • Manipulation of Condition Value
    • Manipulation of IP Address
    • URL Traversal
    • Weak SessionID
  • ===Direct Object References (IDOR)===
    • The Value of a Parameter Is Used Directly to Retrieve a Database Record
      • http://foo.bar/somepage?invoice=12345
    • The Value of a Parameter Is Used Directly to Perform an Operation in the System
      • http://foo.bar/changepassword?user=someuser
    • The Value of a Parameter Is Used Directly to Retrieve a File System Resource
      • http://foo.bar/showImage?img=img00011
    • The Value of a Parameter Is Used Directly to Access Application Functionality
      • http://foo.bar/accessPage?menuitem=12

Session Management Testing

  • ===Session Management Schema===
    • Cookie collection ---> Sequencer
    • Cookie reverse engineering ---> Analysis of the cookie generation algorithm
    • Cookie manipulation ---> Forging of a valid cookie in order to perform the attack
    • Thing to take in consideration
      • Are all Set-Cookie directives tagged as Secure?
      • Do any Cookie operations take place over unencrypted transport?
      • Can the Cookie be forced over unencrypted transport?
      • If so, how does the application maintain security?
      • Are any Cookies persistent?
      • What Expires times are used on persistent cookies, and are they reasonable?
      • Are cookies that are expected to be transient configured as such?
      • What HTTP/1.1 Cache-Control settings are used to protect Cookies?
      • What HTTP/1.0 Cache-Control settings are used to protect Cookies?
  • ===Cookies Attributes===
    • Cookie Attributes can be used for:
      • Session management
      • Personalization
      • Tracking
    • Explain each part of a cookie (already know)
  • ===Session Fixation===
    • A session fixation vulnerability occurs when an attacker can set or control a user's session ID before they authenticate. If the application does not issue a new session ID after login, the attacker can hijack the session once the user logs in, gaining unauthorized access to their account. To mitigate this, ensure that a new session ID is generated upon authentication and critical actions, and use secure cookie attributes.
    • Essentially, the attacker tricks the user into visiting a URL containing a session token (in the URL), and once the user logs in, the attacker retrieves the token to gain access to the user's account.
  • ===Exposed Session Variables===
    • Testing for Encryption & Reuse of Session Tokens Vulnerabilities
      • Every time the authentication is successful, the user should expect to receive:
        • A different session token
        • A token sent via encrypted channel every time they make an HTTP Request
    • Testing for Proxies & Caching Vulnerabilities
      • Caching issues
        • Poison (See notes)
        • Deception (See notes)
    • Testing for GET & POST Vulnerabilities
      • Sending secure credential over GET request (Reflected in URL) ---> BAD
    • Testing for Transport Vulnerabilities
      • 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 HTTP to HTTPS?
      • 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?
  • ===Cross Site Request Forgery===
    • Check cookies (samesite)
    • Check if requests (POST) can be done with GET
      • Login
      • Change password, email
      • 2FA
      • ...
  • ===Logout Functionality===
    • Availability of user interface controls that allow the user to manually log out.
    • Session termination after a given amount of time without activity (session timeout).
    • Proper invalidation of server-side session state.
  • ===Session Timeout===
    • The log out function effectively destroys all session token, or at least renders them unusable,
    • The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
    • A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.
  • ===Session Puzzling==
    • Sequence of entry points and then examining exit points
  • ===Session Hijacking=== 1. Login to the website as the victim and reach any page offering a secure function requiring authentication. 2. Delete from the cookie jar all the cookies which satisfy any of the following conditions. - in case there is no HSTS adoption: the Secure attribute is set. - in case there is partial HSTS adoption: the Secure attribute is set or the Domain attribute is not set. 3. Save a snapshot of the cookie jar. 4. Trigger the secure function identified at step 1. 5. Observe whether the operation at step 4 has been performed successfully. If so, the attack was successful.
    1. Clear the cookie jar, login as the attacker and reach the page at step 1.
    2. Write in the cookie jar, one by one, the cookies saved at step 3.
    3. Trigger again the secure function identified at step 1.
    4. Clear the cookie jar and login again as the victim.
    5. Observe whether the operation at step 8 has been performed successfully in the victim’s account. If so, the attack was successful; otherwise, the site is secure against session hijacking.

Input Validation

  • ===Reflected Cross Site Scripting===

    • Detect Input Vectors
    • Analyze Input Vectors
    • Bypass XSS Filters
      • Encoding
        • HTML
        • URL
        • Unicode
        • Double encoded

  • ===Stored Cross Site Scripting===

    • Detect Input Vectors
    • Analyze Input Vectors
    • Analyze Output Vectors
    • Bypass XSS Filters
      • Encoding
        • HTML
        • URL
        • Unicode
        • Double encoded

  • ===HTTP Verb Tampering===

    • GET
    • POST
    • PUT
    • DELETE
    • OPTION
    • ...

  • ===HTTP Parameter Pollution===

  • ===SQL Injection=== TO CONTINUE

  • ===LDAP Injection===

    • The Lightweight Directory Access Protocol (LDAP) is used to store information about users, hosts, and many other objects. LDAP injection (opens in a new tab) is a server-side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.
    • Let’s suppose we have a web application using a search filter like the following one:

    searchfilter="(cn="+user+")"

    which is instantiated by an HTTP request like this:

    http://www.example.com/ldapsearch?user=John

    If the value John is replaced with a *, by sending the request:

    http://www.example.com/ldapsearch?user=*

    the filter will look like:

    searchfilter="(cn=*)"

  • ===XML Injection===

    • See notes

  • ===SSI Injection===

  • ===HTTP Splitting Smuggling===

    • Request smuggling
    • CRLF in user input inside headers

  • ===Host Header Injection===

    • dispatch requests to the first virtual host on the list
    • cause a redirect to an attacker-controlled domain
    • perform web cache poisoning
    • manipulate password reset functionality
    • TESTING
      • X-Forwarded Host Header Bypass
      • Web Cache Poisoning
      • Password Reset Poisoning

  • ===Server-side Template Injection===

    • Check notes

  • ===Server-Side Request Forgery===

Error Handling

  • ===Improper Error Handling
    • Errors are usually seen as benign as they provide diagnostics data and messages that could help the user understand the problem at hand, or for the developer to debug that error.
    • By trying to send unexpected data, or forcing the system into certain edge cases and scenarios, the system or application will most of the times give out a bit on what’s happening internally, unless the developers turned off all possible errors and return a certain custom message.
      • Search for random files and folders that will not be found (404s).
      • Try to request folders that exist and see the server behavior (403s, blank page, or directory listing).
      • Try sending a request that breaks the HTTP RFC (opens in a new tab). One example would be to send a very large path, break the headers format, or change the HTTP version.
        • Even if errors are handled on the application level, breaking the HTTP RFC may make the integrated web server show itself since it has to handle the request, and developers forget to override these errors.

Weak Cryptography

Business Logic Testing

  • ===Business Logic Data Validation===

    • Testing business logic (Like to create account you need step 1,2,3. What if you were doing only 1 and 3?)
    • ...

  • ===Forge Requests===

    • Using an intercepting proxy observe the HTTP POST/GET looking for some indication that values are incrementing at a regular interval or are easily guessable.
    • If it is found that some value is guessable this value may be changed and one may gain unexpected visibility.

  • ===Integrity Checks===

    • Testing Method: Proxy-Based Manipulation and Component Impact Assessment
    1. Capture HTTP Traffic Using a Proxy: Begin by using a proxy to capture HTTP traffic between the client and the server, focusing on identifying hidden fields or areas that are non-editable within the application.
    2. Inspect and Interrogate Hidden/Non-Editable Fields: If hidden fields or non-editable sections are identified, compare them with the corresponding values in the GUI application. Investigate the parameters to determine if they can be manipulated through the proxy by submitting different data values. The goal is to bypass intended business processes or gain unauthorized access to sensitive values or areas within the application.
    3. Evaluate System Impact: Identify and list components within the application or system that could be impacted by manipulation (e.g., log files, databases, user session data). For each component, attempt to read, edit, or remove its information. This includes trying to manipulate the data collected in logs or altering values stored in databases, ensuring no data or behavior is left untested for potential vulnerabilities.

  • ===Process Timing===

    • Attackers can exploit process timing vulnerabilities to gather information or disrupt business flows. By monitoring execution times, they might infer sensitive system behaviors or game processes. Examples include identifying usernames from login timing discrepancies, manipulating ticket reservations by stalling transactions, and exploiting price-lock mechanisms in e-commerce.

    Key Points:

    • Information Leakage: Timing variations reveal background operations, enabling attackers to predict outcomes or behaviors.
    • Disruption: Attackers can manipulate systems by stalling sessions, affecting availability or fairness.

    Examples:

    1. Slot machines taking longer before big payouts.
    2. Login forms revealing valid usernames through response times.
    3. Ticket reservations disrupted by holding seats indefinitely.
    4. E-commerce price exploitation via delayed transactions.

    Testing Objectives:

    • Identify processes vulnerable to timing-based abuse.
    • Develop misuse cases.
    • Automate or manually test timing manipulations to detect deviations.
    • Analyze process flow and misalignments with business logic.

  • ===Number of Times a Function Can Be Used Limits=== Applications often impose limits on how frequently certain functions can be used to prevent abuse and ensure fair compensation for owners. Attackers may exploit weaknesses in these controls to bypass limits and gain unauthorized benefits.

    Key Points:

    • Purpose: Prevent users from exceeding functional limits that could result in unfair advantages (e.g., discounts or downloads).
    • Vulnerabilities: Function limit flaws are application-specific and require tailored misuse cases to identify exploits.

    Example:
    An eCommerce site allows a single discount per transaction. An attacker might bypass this limit by revisiting the discount page after applying the discount, enabling multiple discounts per transaction.

    Testing Objectives:

    • Identify functions that should have execution limits.
    • Verify logical limits are properly set and validated.

    How to Test:

    • Review documentation and conduct exploratory testing to find features requiring execution limits.
    • Create misuse cases to test if limits can be bypassed (e.g., reapplying discounts or reloading shopping carts).
    • Analyze outcomes for violations of business logic.

  • ===Circumvention of Work Flows=== Testing Methods

    1. Transaction and Points System
      • Start a transaction and proceed past the points/credits trigger.
      • Cancel or reduce the transaction amount.
      • Verify that the points/credits system records the correct adjustments.
    2. Content Management Validation
      • Input valid initial data in a CMS or bulletin board system.
      • Attempt to append, edit, or delete data to leave it in an invalid state.
      • Ensure the system prevents saving invalid data, such as profanity or prohibited topics.

    Related Test Cases

    • Directory Traversal/File Inclusion
    • Bypassing Authorization Schema
    • Bypassing Session Management Schema
    • Business Logic Data Validation
    • Forging Requests
    • Integrity Checks
    • Process Timing
    • Function Usage Limits
    • Defenses Against Application Misuse
    • Uploading Unexpected File Types
    • Uploading Malicious Files

  • ===Defenses Against Application Misuse===

    • Detect misuse and in
    • valid use of valid functionality to identify attacks.
    • Ensure application-layer defenses protect against vulnerabilities and alert owners of potential attacks.

    Importance of Active Defenses

    • Without defenses, attackers can search for vulnerabilities undetected.
    • Defensive mechanisms ensure malicious actions are identified and mitigated promptly.

    Example Scenario
    An authenticated user performs the following malicious actions:

    1. Attempts unauthorized file access.
    2. Substitutes invalid input (e.g., ' instead of a file ID).
    3. Alters request methods (e.g., GET to POST).
    4. Adds extra parameters.
    5. Duplicates parameter values.

    Application Response:

    • High-confidence identification of malicious behavior by the 5th event.
    • Defensive actions could include:
      • Disabling critical functionality.
      • Requiring additional authentication steps.
      • Adding request-response delays.
      • Logging additional interaction data (e.g., sanitized HTTP headers, bodies).

    Failure Scenario
    If the application allows attackers to continue abusive actions without intervention, it fails the test. Most attackers use fuzzing tools to probe parameters systematically.

  • ===Unexpected File Types===

    • Study the applications logical requirements.
    • Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or HTML files containing script.
    • In the application navigate to the file submission or upload mechanism.
    • Submit the “not approved” file for upload and verify that they are properly prevented from uploading
    • Check if the website only do file type check in client-side JavaScript
    • Check if the website only check the file type by “Content-Type” in HTTP request.
    • Check if the website only check by the file extension.
    • Check if other uploaded files can be accessed directly by specified URL.
    • Check if the uploaded file can include code or script injection.
    • Check if there is any file path checking for uploaded files. Especially, hackers may compress files with specified path in ZIP so that the unzip files can be uploaded to intended path after uploading and unzip.
    • Check if you can render the page in HTTP/1 ---> Prone to injection

  • ===Upload of Malicious Files===

    • Identify the file upload functionality.
    • Review the project documentation to identify what file types are considered acceptable, and what types would be considered dangerous or malicious.
      • If documentation is not available then consider what would be appropriate based on the purpose of the application.
    • Determine how the uploaded files are processed.
    • Obtain or create a set of malicious files for testing.
    • Try to upload the malicious files to the application and determine whether it is accepted and processed.

Client-Side Testing

  • ===DOM-Based Cross Site Scripting===
    • Domlogger++ (Searching for sinks)
      • Searching for sinks
      • Searching for reflected parameters
      • Manual Searching for sinks
  • ===Javascript Execution===
    • Same has Dom-Base
  • ===HTML Injection===
    • Dangling markup, injection forms, ...
  • ===Client-side Testing===
    • Redirection to fishing page
    • Used for SSRF (Bypass technique)
  • ===CSS Injection===
    • Extracting Information
      • Attribute ---> <input value="abcdefghijkl...">
      • Text Node ---> <p>abcdefghijkl...</p>
  • ===Resource Manipulation===
    • blablabla
  • ===Cross Origin Resource Sharing===
    • XML HTTP Request
      • XHR API (Cross domain Backward)
    • ACAO (Origin & Access-Control-Allow-Origin) ---> * ---> domain able to fetch data
    • ACAC (Access-Control-Allow-Credentials) ---> Credential allowed or not (Cookies)
  • ===Cross Site Flashing===
    • Flash (ActionScript)
  • ===Clickjacking===
  • ===Websocket (Like web testing)===
    1. Identify that the application is using WebSockets.
      • Inspect the client-side source code for the ws:// or wss:// URI scheme.
      • Use Google Chrome’s Developer Tools to view the Network WebSocket communication.
      • Use ZAP’s (opens in a new tab) WebSocket tab.
    2. Origin.
      • Using a WebSocket client (one can be found in the Tools (opens in a new tab) section below) attempt to connect to the remote WebSocket server. If a connection is established the server may not be checking the origin header of the WebSocket handshake.
    3. Confidentiality and Integrity.
    4. Authentication.
    5. Authorization.
    6. Input Sanitization.
  • ===Web Messaging===
    • The messaging API introduced the postMessage() method (opens in a new tab), with which plain-text messages can be sent cross-origin. It consists of two parameters: message, and domain.
    • iframe1.contentWindow.postMessage("Hello world","http://www.example.com");
    • Testing
      • Test for domain validation
      • Test for message output
  • ===Browser Storage===
    • Determine whether the website is storing sensitive data in client-side storage.
    • The code handling of the storage objects should be examined for possibilities of injection attacks, such as utilizing unvalidated input or vulnerable libraries.
    • Testing
      • Local Storage
        • Entries to localStorage persist even when the browser window closes, with the exception of windows in Private/Incognito mode.
      • Session Storage
        • window.sessionStorage is a global property that implements the Web Storage API and provides ephemeral key-value storage in the browser.
      • Web SQL
      • Cookies
      • Global Window Object
  • ===Cross Site Script Inclusion===

    • Collect Data Using Authenticated and Unauthenticated User Sessions

    • Identify which endpoints are responsible for sending sensitive data, what parameters are required, and identify all relevant dynamically and statically generated JavaScript responses using authenticated user sessions. Pay special attention to sensitive data sent using JSONP (opens in a new tab). To find dynamically generated JavaScript responses, generate authenticated and unauthenticated requests, then compare them. If they’re different, it means the response is dynamic; otherwise it’s static. To simplify this task, a tool such as Veit Hailperin’s Burp proxy plugin (opens in a new tab) can be used. Make sure to check other file types in addition to JavaScript; XSSI is not limited to JavaScript files alone.

    • Determine Whether the Sensitive Data Can Be Leaked Using JavaScript

    • Testers should analyze code for the following vehicles for data leakage via XSSI vulnerabilities:

      1. Global variables
      2. Global function parameters
      3. CSV (Comma Separated Values) with quotations theft
      4. JavaScript runtime errors
      5. Prototype chaining using this

API Testing

  • ===GraphQL===
    • Tools
      • Burp GraphQL
      • GraphQL Voyager (opens in a new tab) (Does not show all possibilities)
        • This tool creates an Entity Relationship Diagram (ERD) representation of the GraphQL schema
        • GraphQL Voyager does not display everything that can be done with GraphQL. For example, the mutations available...
      • GraphiQL
      • GraphQL Playground
        • GraphQL Playground is a GraphQL client (like GraphQL but with UI)
        • Can use it locally pointing to the GraphQL URL
    • What to test
      • Authorization
      • Injection
      • SQL Injection
      • Cross-Site Scripting (XSS)
      • Denial of Service (DoS) Queries
      • Batching Attacks
      • Detailed Error Message
      • Exposure of Underlying API
    • Introspection Queries
      • Introspection queries are the method by which GraphQL lets you ask what queries are supported, which data types are available, and many more details you will need when approaching a test of a GraphQL deployment.
      • Testing Payload (opens in a new tab)
      • The result will usually be very long (and hence has been shortened here), and it will contain the entire schema of the GraphQL deployment.
Regular ExpressionRedteam Approach