Compound Element ID: 384 (Compound Element Base: Composite)
Status: Incomplete
Description
Description Summary
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Extended Description
Such a scenario is commonly observed when: 1. A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user 2. An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session 3. The application or container uses predictable session identifiers. In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Access Control
Technical Impact: Gain privileges / assume
identity
Demonstrative Examples
Example 1
The following example shows a snippet of code from a J2EE web
application where the application authenticates users with
LoginContext.login() without first calling
HttpSession.invalidate().
In order to exploit the code above, an attacker could first create a
session (perhaps by logging into the application) from a public
terminal, record the session identifier assigned by the application, and
reset the browser to the login page. Next, a victim sits down at the
same public terminal, notices the browser open to the login page of the
site, and enters credentials to authenticate against the application.
The code responsible for authenticating the victim continues to use the
pre-existing session identifier, now the attacker simply uses the
session identifier recorded earlier to access the victim's active
session, providing nearly unrestricted access to the victim's account
for the lifetime of the session. Even given a vulnerable application,
the success of the specific attack described here is dependent on
several factors working in the favor of the attacker: access to an
unmonitored public terminal, the ability to keep the compromised session
active and a victim interested in logging into the vulnerable
application on the public terminal.
In most circumstances, the first two challenges are surmountable given
a sufficient investment of time. Finding a victim who is both using a
public terminal and interested in logging into the vulnerable
application is possible as well, so long as the site is reasonably
popular. The less well known the site is, the lower the odds of an
interested victim using the public terminal and the lower the chance of
success for the attack vector described above. The biggest challenge an
attacker faces in exploiting session fixation vulnerabilities is
inducing victims to authenticate against the vulnerable application
using a session identifier known to the attacker.
In the example above, the attacker did this through a direct method
that is not subtle and does not scale suitably for attacks involving
less well-known web sites. However, do not be lulled into complacency;
attackers have many tools in their belts that help bypass the
limitations of this attack vector. The most common technique employed by
attackers involves taking advantage of cross-site scripting or HTTP
response splitting vulnerabilities in the target site [12]. By tricking
the victim into submitting a malicious request to a vulnerable
application that reflects JavaScript or other code back to the victim's
browser, an attacker can create a cookie that will cause the victim to
reuse a session identifier controlled by the attacker. It is worth
noting that cookies are often tied to the top level domain associated
with a given URL. If multiple applications reside on the same top level
domain, such as bank.example.com and recipes.example.com, a
vulnerability in one application can allow an attacker to set a cookie
with a fixed session identifier that will be used in all interactions
with any application on the domain example.com [29].
Example 2
The following example shows a snippet of code from a J2EE web
application where the application authenticates users with a direct post to
the <code>j_security_check</code>, which typically does not
invalidate the existing session before processing the login
request.
(Bad Code)
Example
Language: HTML
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>
Potential Mitigations
Invalidate any existing session identifiers prior to authorizing a new
user session
For platforms such as ASP that do not generate new values for
sessionid cookies, utilize a secondary cookie. In this approach, set a
secondary cookie on the user's browser to a random value and set a
session variable to the same value. If the session variable and the
cookie value ever don't match, invalidate the session, and force the
user to log on again.
Other Notes
Other attack vectors include DNS poisoning and related network based
attacks where an attacker causes the user to visit a malicious site by
redirecting a request for a valid site. Network based attacks typically
involve a physical presence on the victim's network or control of a
compromised machine on the network, which makes them harder to exploit
remotely, but their significance should not be overlooked. Less secure
session management mechanisms, such as the default implementation in Apache
Tomcat, allow session identifiers normally expected in a cookie to be
specified on the URL as well, which enables an attacker to cause a victim to
use a fixed session identifier simply by emailing a malicious URL.
External Control of Assumed-Immutable Web Parameter
Definition in a New Window
Weakness ID: 472 (Weakness Base)
Status: Draft
Description
Description Summary
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
Extended Description
If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.
For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improperreliance on the value of the client-provided cookie by the server side application.
Alternate Terms
Assumed-Immutable Parameter Tampering
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Technical Impact: Modify application
data
Without appropriate protection mechanisms, the client can easily
tamper with cookies and similar web data. Reliance on the cookies
without detailed validation can lead to problems such as SQL injection.
If you use cookie values for security related decisions on the server
side, manipulating the cookies might lead to violations of security
policies such as authentication bypassing, user impersonation and
privilege escalation. In addition, storing sensitive data in the cookie
without appropriate protection can also lead to disclosure of sensitive
user data, especially data stored in persistent cookies.
Demonstrative Examples
Example 1
Here, a web application uses the value of a hidden form field
(accountID) without having done any input validation because it was assumed
to be immutable.
User user = getUserFromID(Long.parseLong(accountID));
Example 2
Hidden fields should not be trusted as secure parameters. An attacker
can intercept and alter hidden fields in a post to the server as easily
as user input fields. An attacker can simply parse the HTML for the
substring:
< input type "hidden"
or even just "hidden". Hidden field values displayed later in the
session, such as on the following page, can open a site up to cross-site
scripting attacks.
Modification of message number parameter allows
attackers to read other people's messages.
Potential Mitigations
Phase: Implementation
Strategy: Input Validation
Assume all input is malicious. Use an "accept known good" input
validation strategy, i.e., use a whitelist of acceptable inputs that
strictly conform to specifications. Reject any input that does not
strictly conform to specifications, or transform it into something that
does.
When performing input validation, consider all potentially relevant
properties, including length, type of input, the full range of
acceptable values, missing or extra inputs, syntax, consistency across
related fields, and conformance to business rules. As an example of
business rule logic, "boat" may be syntactically valid because it only
contains alphanumeric characters, but it is not valid if the input is
only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs
(i.e., do not rely on a blacklist). A blacklist is likely to miss at
least one undesirable input, especially if the code's environment
changes. This can give attackers enough room to bypass the intended
validation. However, blacklists can be useful for detecting potential
attacks or determining which inputs are so malformed that they should be
rejected outright.
Phase: Implementation
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.
product does not sufficiently distinguish external
HTML from internal, potentially dangerous HTML, allowing bypass using
special strings in the page title. Overlaps special
elements.
A product can be used as an intermediary or proxy between an attacker and the ultimate target, so that the attacker can either bypass access controls or hide activities.
Time of Introduction
Architecture and Design
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Non-Repudiation
Access Control
Technical Impact: Gain privileges / assume
identity; Hide activities
FTP bounce attack. Protocol allows attacker to
modify the PORT command to cause the FTP server to connect to other machines
besides the attacker's. Similar to proxied trusted
channel.
Potential Mitigations
Enforce the use of strong mutual authentication mechanism between the
two parties.
This entry is currently a child of CWE-610 under view 1000, however there is also a relationship with CWE-668 because the resulting proxy effectively exposes the victims control sphere to the attacker. This should possibly be considered as an emergent resource.
Description
