4.0

87
Web Application Penetration Testing
16 bit chunk is incrementing at a regular rate, it may indicate a
sequential or even time-based element to the token generation.
See examples.
If static elements to the Tokens are identified, further samples
should be gathered, varying one potential input element at a time.
For example, log in attempts through a different user account or
from a different IP address may yield a variance in the previously
static portion of the session token.
The following areas should be addressed during the single and
multiple Session ID structure testing:
• What parts of the Session ID are static?
• What clear-text confidential information is stored in the Session
D? E.g. usernames/UID, IP addresses
• What easily decoded confidential information is stored?
• What information can be deduced from the structure of the
Session ID?
• What portions of the Session ID are static for the same log in
conditions?
• What obvious patterns are present in the Session ID as a whole,
or individual portions?
Session ID Predictability and Randomness
Analysis of the variable areas (if any) of the Session ID should be
undertaken to establish the existence of any recognizable or predictable
patterns. These analyses may be performed manually and
with bespoke or OTS statistical or cryptanalytic tools to deduce
any patterns in the Session ID content. Manual checks should include
comparisons of Session IDs issued for the same login conditions
– e.g., the same username, password, and IP address.
Time is an important factor which must also be controlled. High
numbers of simultaneous connections should be made in order to
gather samples in the same time window and keep that variable
constant. Even a quantization of 50ms or less may be too coarse
and a sample taken in this way may reveal time-based components
that would otherwise be missed.
Variable elements should be analyzed over time to determine
whether they are incremental in nature. Where they are incremental,
patterns relating to absolute or elapsed time should be investigated.
Many systems use time as a seed for their pseudo-random
elements. Where the patterns are seemingly random, one-way
hashes of time or other environmental variations should be considered
as a possibility. Typically, the result of a cryptographic
hash is a decimal or hexadecimal number so should be identifiable.
In analyzing Session ID sequences, patterns or cycles, static elements
and client dependencies should all be considered as possible
contributing elements to the structure and function of the
application.
• Are the Session IDs provably random in nature? Can the resulting
values be reproduced?
• Do the same input conditions produce the same ID on a
subsequent run?
• Are the Session IDs provably resistant to statistical or
cryptanalysis?
• What elements of the Session IDs are time-linked?
• What portions of the Session IDs are predictable?
• Can the next ID be deduced, given full knowledge of the
generation algorithm and previous IDs?
Cookie reverse engineering
Now that the tester has enumerated the cookies and has a general
idea of their use, it is time to have a deeper look at cookies
that seem interesting. Which cookies is the tester interested in?
A cookie, in order to provide a secure method of session management,
must combine several characteristics, each of which is
aimed at protecting the cookie from a different class of attacks.
These characteristics are summarized below:
[1] Unpredictability: a cookie must contain some amount of hardto-guess
data. The harder it is to forge a valid cookie, the harder is
to break into legitimate user’s session. If an attacker can guess the
cookie used in an active session of a legitimate user, they will be
able to fully impersonate that user (session hijacking). In order to
make a cookie unpredictable, random values and/or cryptography
can be used.
[2] Tamper resistance: a cookie must resist malicious attempts
of modification. If the tester receives a cookie like IsAdmin=No,
it is trivial to modify it to get administrative rights, unless the application
performs a double check (for instance, appending to the
cookie an encrypted hash of its value)
[3] Expiration: a critical cookie must be valid only for an appropriate
period of time and must be deleted from the disk or memory
afterwards to avoid the risk of being replayed. This does not apply
to cookies that store non-critical data that needs to be remembered
across sessions (e.g., site look-and-feel).
[4] “Secure” flag: a cookie whose value is critical for the integrity
of the session should have this flag enabled in order to allow its
transmission only in an encrypted channel to deter eavesdropping.
The approach here is to collect a sufficient number of instances
of a cookie and start looking for patterns in their value. The exact
meaning of “sufficient” can vary from a handful of samples,
if the cookie generation method is very easy to break, to several
thousands, if the tester needs to proceed with some mathematical
analysis (e.g., chi-squares, attractors. See later for more information).
It is important to pay particular attention to the workflow of the
application, as the state of a session can have a heavy impact on
collected cookies. A cookie collected before being authenticated
can be very different from a cookie obtained after the authentication.
Another aspect to keep into consideration is time. Always record
the exact time when a cookie has been obtained, when there is
the possibility that time plays a role in the value of the cookie (the
server could use a time stamp as part of the cookie value). The
time recorded could be the local time or the server’s time stamp
included in the HTTP response (or both).
When analyzing the collected values, the tester should try to figure
out all variables that could have influenced the cookie value and
try to vary them one at the time. Passing to the server modified
versions of the same cookie can be very helpful in understanding
how the application reads and processes the cookie.