Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

61

High

Session identifiers that remain unchanged when the privilege levels change.

Permissive session management mechanism that accepts random user-generated session identifiers

Predicatable session identifiers

Medium

• Time and State
• Injection

Low: Only basic skills are required to determine and fixate session identifiers in a user's browser. Subsequent attacks may require greater skill levels depending on the attacker's motives.

None

Determining whether the target application server accepts preset session identifiers is relatively easy. The attacker may try setting session identifiers in the URL or hidden form fields or in cookies, depending upon application design. Having access to an account or by utilizing a dummy account, the attacker can determine whether the preset session identifiers are accepted or not.

With code or design in hand, the attacker can readily verify whether preset session identifiers are accepted and whether identifiers are regenerated, and possible destroyed, when privilege levels change.

There are no indicators for the server since a fixated session identifier is similar to an ordinarily generated one. However, too many invalid sessions due to invalid session identifiers is a potential warning.

A client can be suspicious if a received link contains preset session identifiers. However, this depends on the client's knowledge of such an issue. Also, fixation through Cross Site Scripting or hidden form fields is usually difficult to detect.

Use a strict session management mechanism that only accepts locally generated session identifiers: This prevents attackers from fixating session identifiers of their own choice.

Regenerate and destroy session identifiers when there is a change in the level of privilege: This ensures that even though a potential victim may have followed a link with a fixated identifier, a new one is issued when the level of privilege changes.

Use session identifiers that are difficult to guess or brute-force: One way for the attackers to obtain valid session identifiers is by brute-forcing or guessing them. By choosing session identifiers that are sufficiently random, brute-forcing or guessing becomes very difficult.

• Privilege Escalation

Session fixation takes place primarily due to the application trusting user-supplied session identifiers and using the same identifiers across multiple levels of privilege. There are two types of session management mechanisms:
1. Permissive: The application accepts any user-provided session identifier. This allows an attacker to easily fixate an identifier since the application trusts all identifiers provided to it.
2. Strict: The application trusts only those session identifiers that were generated locally.Although this is a far stronger mechanism, it does not make applications immune to session fixation. With a strict mechanism, the attacker needs to setup a trap session to obtain a valid identifier, trick the victim into using the identifier and leverage session fixation. Also, the attacker may now be required to periodically refresh the the trap session in order to maintain a valid session identifier.

Session identifiers can be fixated:
1. In the URL: The attacker needs to have the victim click on a hyperlink such as http://targetserver.com/login.jsp?jsessionid=176k36kk92adnn0lajeq91
2. In hidden form fields: The attacker needs to trick the victim into clicking on a look-alike form that contains the fixated session identifier.
3. In the cookie: This is relatively the most difficult location to fixate an identifier. The attacker has to resort to another mechanism such as Cross-Site Scripting to introduce a cookie with a fixated session identifier. This can be achieved by either using a client-side script to introduce the cookie (document.cookie="sessionid=abc1234") or injecting cookies using the META tag (<meta http-equiv=Set-Cookie content="sessionid=abc1234">).

GET or POST data, Hidden form fields and session cookies

Preset session identifier

Target application's session management mechanism

The payload activation impact is that a session identifier of the attacker's choice is considered valid and trust decisions by the application will be based on such a fixated identifier.

Regenerate session identifiers upon each new request. This ensures that fixated session identifiers are rendered obsolete.

Regenerate a session identifier everytime a user enters an authenticated session and destroy the identifier when the user logs out of an authenticated session.

Set appropriate expiry times on cookies that contain session identifiers. This helps limit the window of opportunity for an attacker to use the identifier.

Do not use session identifiers as part of URLs or hidden form fields. It becomes easy for an attacker to trick a user into a fixated session when session identifiers are easily accessible.

Authenticate every transaction by requesting credentials. This ensures that only a legitimate user of the application can proceed with the transaction. If an attacker seeks to perform any such authenticated transaction, valid credentials will be required even though session fixation may have been successful earlier.

• Complete Mediation
• Reluctance to Trust
• Defense in Depth

• Never Use Unvalidated Input as Part of a Directive to any Internal Component

Penetration

G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.

CWE - Session Fixation

CWE - Time and State