The J2EE application is configured to use an insufficient session ID length.
Extended Description
If an attacker can guess or steal a session ID, then he/she may be able to take over the user's session (called session hijacking). The number of possible session IDs increases with increased session ID length, making it more difficult to guess or steal a session ID.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Java
Common Consequences
Scope
Effect
Access Control
Technical Impact: Gain privileges / assume
identity
If an attacker can guess an authenticated user's session identifier,
they can take over the user's session.
Enabling Factors for Exploitation
If attackers use a botnet with hundreds or thousands of drone computers,
it is reasonable to assume that they could attempt tens of thousands of
guesses per second. If the web site in question is large and popular, a high
volume of guessing might go unnoticed for some time.
Demonstrative Examples
Example 1
The following XML example code is a deployment descriptor for a Java
web application deployed on a Sun Java Application Server. This deployment
descriptor includes a session configuration property for configuring the
session ID length.
(Bad Code)
Example
Language: XML
<sun-web-app>
...
<session-config>
<session-properties>
<property name="idLengthBytes" value="8">
<description>The number of bytes in this web
module's session ID.</description>
</property>
</session-properties>
</session-config>
...
</sun-web-app>
This deployment descriptor has set the session ID length for this Java
web application to 8 bytes (or 64 bits). The session ID length for Java
web applications should be set to 16 bytes (128 bits) to prevent
attackers from guessing and/or stealing a session ID and taking over a
user's session.
Note for most application servers including the Sun Java Application
Server the session ID length is by default set to 128 bits and should
not be changed. And for many application servers the session ID length
cannot be changed from this default setting. Check your application
server documentation for the session ID length default setting and
configuration options to ensure that the session ID length is set to 128
bits.
Potential Mitigations
Session identifiers should be at least 128 bits long to prevent
brute-force session guessing. A shorter session identifier leaves the
application open to brute-force session guessing attacks.
Phase: Implementation
A lower bound on the number of valid session identifiers that are
available to be guessed is the number of users that are active on a site
at any given moment. However, any users that abandon their sessions
without logging out will increase this number. (This is one of many good
reasons to have a short inactive session timeout.) With a 64 bit session
identifier, assume 32 bits of entropy. For a large web site, assume that
the attacker can try 1,000 guesses per second and that there are 10,000
valid session identifiers at any given moment. Given these assumptions,
the expected time for an attacker to successfully guess a valid session
identifier is less than 4 minutes. Now assume a 128 bit session
identifier that provides 64 bits of entropy. With a very large web site,
an attacker might try 10,000 guesses per second with 100,000 valid
session identifiers available to be guessed. Given these assumptions,
the expected time for an attacker to successfully guess a valid session
identifier is greater than 292 years.
Background Details
Session ID's can be used to identify communicating parties in a web
environment.
The expected number of seconds required to guess a valid session
identifier is given by the equation: (2^B+1)/(2*A*S) Where: - B is the
number of bits of entropy in the session identifier. - A is the number of
guesses an attacker can try each second. - S is the number of valid session
identifiers that are valid and available to be guessed at any given time.
The number of bits of entropy in the session identifier is always less than
the total number of bits in the session identifier. For example, if session
identifiers were provided in ascending order, there would be close to zero
bits of entropy in the session identifier no matter the identifier's length.
Assuming that the session identifiers are being generated using a good
source of random numbers, we will estimate the number of bits of entropy in
a session identifier to be half the total number of bits in the session
identifier. For realistic identifier lengths this is possible, though
perhaps optimistic.
Description
