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
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)
HTML
<form method="POST"
action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>
Potential Mitigations
Phase
Description
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. Failure to validate portions 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 improper reliance 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
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
Description
Architecture and Design
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be displayed or stored. Use an
"accept known good" validation strategy. Input (specifically, unexpected
CRLFs) that is not appropriate should not be processed into HTTP
headers.
Use and specify a strong input/output encoding (such as ISO 8859-1 or
UTF 8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist 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.
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
Phase
Description
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.
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Potential Mitigations,
Time of Introduction
2008-09-08
CWE Content Team
MITRE
Internal
updated Relationships, Observed Example, Other Notes,
Taxonomy Mappings
2008-11-24
CWE Content Team
MITRE
Internal
updated Maintenance Notes, Relationships,
Taxonomy Mappings, Time of Introduction
Description
