8 CVE-2025-29928

An attacker creates a false but functional session credential in order to gain or usurp access to a service. Session credentials allow users to identify themselves to a service after an initial authentication without needing to resend the authentication information (usually a username and password) with every message. If an attacker is able to forge valid session credentials they may be able to bypass authentication or piggy-back off some other authenticated user's session. This attack differs from Reuse of Session IDs and Session Sidejacking attacks in that in the latter attacks an attacker uses a previous or existing credential without modification while, in a forging attack, the attacker must create their own credential, although it may be based on previously observed credentials. [Analyze and Understand Session IDs] The attacker finds that the targeted application use session credentials to identify legitimate users. [Create Session IDs.] Attackers craft messages containing their forged credentials in GET, POST request, HTTP headers or cookies. [Abuse the Victim's Session Credentials] The attacker fixates falsified session ID to the victim when victim access the system. Once the victim has achieved a higher level of privilege, possibly by logging into the application, the attacker can now take over the session using the forged session identifier.

[Survey the application for Indicators of Susceptibility] Using a variety of methods, until one is found that applies to the target, the adversary probes for cookies, session tokens, or entry points that bypass identifiers altogether. [Fetch samples] The adversary fetches many samples of identifiers. This may be through legitimate access (logging in, legitimate connections, etc.) or via systematic probing. [Impersonate] An adversary can use successful experiments or authentications to impersonate an authorized user or system or to laterally move within a system or application [Spoofing] Malicious data can be injected into the target system or into a victim user's system by an adversary. The adversary can also pose as a legitimate user to perform social engineering attacks. [Data Exfiltration] The adversary can obtain sensitive data contained within the system or application.

This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information. [Obtain copy of cookie] The adversary first needs to obtain a copy of the cookie. The adversary may be a legitimate end user wanting to escalate privilege, or could be somebody sniffing on a network to get a copy of HTTP cookies. [Obtain sensitive information from cookie] The adversary may be able to get sensitive information from the cookie. The web application developers may have assumed that cookies are not accessible by end users, and thus, may have put potentially sensitive information in them. [Modify cookie to subvert security controls.] The adversary may be able to modify or replace cookies to bypass security controls in the application.

In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation. [Enumerate information passed to client side] The attacker identifies the parameters used as part of tokens to take business or security decisions [Determine protection mechanism for opaque token] The attacker determines the protection mechanism used to protect the confidentiality and integrity of these data tokens. They may be obfuscated or a full blown encryption may be used. [Modify parameter/token values] Trying each parameter in turn, the attacker modifies the values [Cycle through values for each parameter.] Depending on the nature of the application, the attacker now cycles through values of each parameter and observes the effects of this modification in the data returned by the server

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking. [Find Session IDs] The attacker interacts with the target host and finds that session IDs are used to authenticate users. [Characterize IDs] The attacker studies the characteristics of the session ID (size, format, etc.). As a results the attacker finds that legitimate session IDs are predictable. [Match issued IDs] The attacker brute forces different values of session ID and manages to predict a valid session ID. [Use matched Session ID] The attacker uses the falsified session ID to access the target system.

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay. The attacker interacts with the target host and finds that session IDs are used to authenticate users. The attacker steals a session ID from a valid user. The attacker tries to use the stolen session ID to gain access to the system with the privileges of the session ID's original owner.

The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation. [Setup the Attack] Setup a session: The attacker has to setup a trap session that provides a valid session identifier, or select an arbitrary identifier, depending on the mechanism employed by the application. A trap session is a dummy session established with the application by the attacker and is used solely for the purpose of obtaining valid session identifiers. The attacker may also be required to periodically refresh the trap session in order to obtain valid session identifiers. [Attract a Victim] Fixate the session: The attacker now needs to transfer the session identifier from the trap session to the victim by introducing the session identifier into the victim's browser. This is known as fixating the session. The session identifier can be introduced into the victim's browser by leveraging cross site scripting vulnerability, using META tags or setting HTTP response headers in a variety of ways. [Abuse the Victim's Session] Takeover the fixated session: Once the victim has achieved a higher level of privilege, possibly by logging into the application, the attacker can now take over the session using the fixated session identifier.