1. Changing Sessions to Evade Restrictions
1.1. Problem
Some applications will prevent
attackers from frequently accessing a form or page. One of the ways to
bypass these protections is to frequently request new session
identifiers so that the attacker appears as many new users rather than a
single malicious user.
1.2. Solution
This recipe only applies if your application prevents an attacker
from attempting to guess or sequentially attempt passwords, identifiers,
or credentials.
Once you’ve identified an area where your application restricts
multiple requests, go ahead and initiate as many requests as you can.
Once you’re finished, you should now be locked out or otherwise
prevented from trying again. At this point, open up Edit Cookies, filter by your current domain, select at
least one cookie for your domain, and click the Delete button. Edit
Cookies, by default, will ask you if you’d like to Delete or Cancel—but
notice that there’s another option there, the Delete All option. Figure 1 shows the delete options. Click the
Delete All option to erase all cookies, and hopefully all sessions, for
your domain.
With the sessions gone, you should now be able to attempt the
previously blocked actions again. If you repeat them enough and get
blocked again, simply delete the cookies again to continue.
.3. Discussion
This ability to bypass detection and restrictions this way poses a
difficult problem—how can one prevent repeated attempts? It turns out
this is a very difficult problem. Tracking malicious attackers by IP
address is a start—except that some users share IP addresses (think
public wireless access points) and some attackers have access to many IP
addresses (via a botnet). Server-side sessions aren’t safe, as cookies
can be deleted at any time. Client-side sessions aren’t safe, as the
client is completely controlled by the attacker anyway. Unfortunately,
it appears that one can’t stop an attacker from trying, one can only
slow them down. On the plus side, done well, one can slow an attacker
down enough that cracking a password or credential should take a few
years!
2. Impersonating Another User
2.1. Problem
If at this point you’re wondering what tests to apply when your
application doesn’t use a session identifier, but instead relies on
keeping the username in cookies, then this is the recipe for you. If
your cookies contain any information about usernames and passwords, access permissions, or other authentication and
authorization details, this can lead to trouble.
2.2. Solution
Via Edit Cookies, identify the authentication or authorization
details being stored in cookies. We’ll go through the ramifications of each type of stored detail one by
one:
Username only
If once the user logs in, only the username is stored in
order to identify which user is which, then any user may
impersonate any other user. To do so, you would open up Edit
Cookies and modify the username cookie to contain another user’s
username. The next time you browse to the application, the
application will mis-identify you, allowing you to impersonate the
other user.
Username and password
When the username and password are stored and checked
together, an attacker can brute-force passwords at a rapid speed.
To break into an account, the attacker sets up the cookies to
contain the username and then rapidly iterates through new
password cookies. An attacker could
try many passwords without triggering any sort of account lockout.
Once the password is broken, the attacker can login as and
impersonate the user.
Access Controls or authorization details
If controls are defined in the cookies, try changing them
via Edit Cookies. For example, if an account has a cookie with the
name and contents ReadOnly and
True, what happens if you
change it to False, or rename
the entire cookie? In this example, if your application allowed a
ReadOnly user to make
modifications, you’d have a clear vulnerability. While these don’t
always allow one to impersonate another user, it does grant a user
more access than was intended.
2.3. Description
Now you see why there’s such a focus on session identifiers. By using a session identifier, one
essentially hides all the authentication and authorization details on
the server. The only thing an attacker can guess about a session
identifier is the session identifier itself—and if it’s random enough,
that could take some time.
3. Fixing Sessions
3.1. Problem
Guessing passwords or session identifiers is hard work for an attacker. It’s
much easier to trick a user into setting his own session identifier to
something the attacker already knows. This is referred to as session
fixation.
3.2. Solution
To set up this test, you’ll need to clear your browser’s cookies
for your web application (via Edit Cookies or just by clearing all
cookies via the Clear Private Data option in Firefox’s preferences).
Once that’s done, navigate until your application sets a session
identifier. You’ll have to check for the session identifier after each
new page; this can be accomplished by first using Edit Cookies to filter
for just your application’s domain and then refreshing the Edit Cookies
filter after each page load. Alternatively, you can view the raw HTTP
response from the server, waiting for it to send the set-cookie header or send the session
identifier via GET or POST. Record the session identifier name and value
as they appear, such as PHPSESSID=42656E2057616C74686572.
Clear your cookies for your site again. Issue a request to your
application that contains the session identifier as part of the GET
parameters. For instance, if you recorded the PHPSESSID mentioned above, you might enter:
http://www.example.com/myAccount.php?PHPSESSID=42656E2057616C74686572.
Click on a link within the returned page and then check your cookies
again. If the session identifier uses the exact same value as you
recorded earlier, then you have fixed your own session.
3.3. Description
Like other impersonation attacks, session fixation convinces the
web application that the attacker and the victim are the same person.
The key difference with session fixation is that session fixation
requires that the target click a link, whereas session prediction or
theft does not. However, given that grabbing session identifiers this
way can be automated, such links may be mailed, updated, or otherwise
distributed frequently enough that the chance of breaking in is not
greatly diminished.
