Tải bản đầy đủ - 0trang
4 Analyzing Session ID Expiration
Figure 11-7. Checking the expiration date of your cookies
If there is no session cookie, you’re guaranteed that the session will expire when you
leave the site or close your browser. In such cases, all session information resides within
the page requests and responses. The session depends on each request and response
following each other in direct sequence without interruptions.
If there is a session cookie set, examine the Expires entry via Edit Cookies. If it reads
“at end of session,” then you know the session will expire when you close your browser.
However, if it gives a date, the session will expire automatically on that date, provided
that you not use the application until then. Figure 11-7 shows how to check the expiration date of a cookie from example.com.
The expiration may depend on how you use the application. Try navigating to another
page within your web application and refreshing the cookie expiration date again. Has
it changed? If so, this means your session expiration is updated based on application
The primary security concern for each case is that the session identifier will be stolen,
thus allowing someone to impersonate the user and act on his behalf. Sessions can be
stolen via attacks listed in this book, other attacks that take over a user’s computer, or
simply by using a public computer after someone else left her web browser open. To
reduce the probability that a stolen session will be used while it is still valid, sessions
are made to expire.
222 | Chapter 11: Manipulating Sessions
There are several common ways that sessions expire, after which the user will be forced
to log in again, obtaining a new session. Once the new session has been initiated, an
attacker who had stolen the old one would be out of luck. For each expiration method,
we’ll discuss the mechanism and security implications:
Fixed time after login
If a user logs in at 10:00 a.m., with a fixed expiration time of 1 hour, then any
connection made from the user’s browser to the application server will authenticate
as the user who logged in until 11 a.m. Any attempts after 11 a.m. will request that
the user sign in again, which will reset the timer.
The security risk with a fixed time-out like this depends heavily on the length of
time set. If a user is forced to log in every five minutes, it is unlikely an attacker will
have the time to steal the session and use it before it expires. However, few users
would put up with logging in every few minutes. Many applications have much,
much longer fixed expiration timers—Gmail, for instance, expires after two weeks.
Two weeks is plenty enough time for a stolen session to be abused. A two week
timeout is a concession to usability, in this case.
Fixed time after new request
If a user logs in at 10:00 a.m., with a timeout 1 hour after the last page requested,
and requests a page at 10:30 a.m., the user will be logged out at 11:30 a.m. Any
single HTTP request between 10:00 a.m. and 10:30 a.m. will have reset the timer,
so the cutoff time could have been 11:05 a.m., 11:15 a.m., 11:25 a.m., until the
last page request, setting it to 11:30 a.m. If no new requests were made before 11:30
a.m., the user would be forced to log in again.
The same risks that apply to the fixed-time-after-login method apply here. The
benefit to updating the time-out after every page request is that expiration time
period may be reduced significantly, as it won’t interrupt users continually. If a
user were to use an application for three hours even though the time-out was set
to 30 minutes, as long as the user made a new request at least once every 30 minutes
for those three hours, the user would not be interrupted and required to log in
again. Most online banking applications, such as (at the time of this writing) Bank
of America Online, use this method. It ensures users may complete whatever actions they wish without being interrupted, yet protects against stolen sessions by
keeping time-outs short.
An additional risk to refreshing expiration times after every page request is that
many AJAX applications continually poll the server—thus allowing the session to
stay valid indefinitely. Closing the browser will stop the AJAX from refreshing the
time-out in this way, but this defeats the point of having a refresh-based time-out,
instead this is functionally equivalent to the browser-close method.
If a user logs in at 10:00 a.m. and leaves the browser open until 3:30 p.m., then
the session will last until 3:30 p.m. If the user closes the browser at any point, even
for just a moment, the user will be forced to log in and obtain a new session.
11.4 Analyzing Session ID Expiration | 223
This method allows the user to control session state to a much finer degree. The
user controls when he or she logs out simply by closing the browser. However,
users are likely to leave the browser open, not out of forgetfulness, but just because
session security is not on the top of their mind. Considering how much work is
done via the web, some users may only close their browser when shutting down
the computer. This allows a stolen session to persist for an indefinite amount of
If a user logs in at 10:00 a.m., turns the computer off, travels the world for three
years, returns to the computer, and loads up the application—he or she will still
be logged in. This method does not reduce the likelihood that a stolen session will
expire before being used. Bloglines.com, a popular RSS aggregator, uses this
Authentication on action
If a user logs in at 10:00 a.m., and is about to commit a high-risk action (transferring
money between accounts, buying something with a credit card, shutting down a
nuclear reactor, etc.), the user is requested to authenticate again. If the second
authentication fails, the user’s session is immediately expired and the user is logged
out of the application.
This is by far the most secure method discussed here. It prevents a stolen session
from being used for the high risk actions. There is no time-out window where an
attacker has the full ability to use the application. Essentially, an attacker who steals
a session, but doesn’t know the password, will be unable to use that stolen session
for the actions that require re-authentication. Statefarm.com uses this method.
Such a mechanism is not foolproof. For instance, a balance transfer might be on
the re-authentication protected actions, but an address change might not. A patient
attacker would change the listed address of the bank account and then use mailed
bank statements to obtain the bank account number, routing number, and name
and address details sufficient to write a fraudulent check for the original user.
The above methods and mechanisms may be mixed. For instance, a user may remain
logged in until either a fixed time after a new request or the user closes the browser.
This essentially combines the preventative powers of both methods, rather than weakening them. Perhaps the best protection combines the authentication-on-action, fixedtime-after-new-request, and browser-close methods of session expiration. This may or
may not be tolerable from a usability perspective.
All of the above mechanisms rely on getting one important technical detail correct. This
detail is that a user should always receive a new session identifier when a new session
is issued. If, instead, a user is given the same session identifier every time he or she logs
in, then essentially the session is never expired. An attacker who stole that session
would have periodic access to use it—essentially able to impersonate the original user
224 | Chapter 11: Manipulating Sessions
whenever the original user was also using the application. More details on this vulnerability can be found in Recipe 8.6.
Old grizzled system administrators and support technicians use an acronym PEBKAC
(Problem Exists Between Keyboard and Chair). This is a humorous way of indicating
that the user is a moron. It also describes the problem with session expiration rather
well. To the computer, especially your web application server (which is likely miles
away from the user’s chair), there is no way to tell who is sitting in the chair. It may
not be the real user at all.
11.5 Analyzing Session Identifiers with Burp
If the session identifier can be predicted, an attacker can steal the next user’s session
and thus impersonate the user. Random, unpredictable session identifiers are crucial
to the security of a web application. Analyzing randomness can be a difficult statistical
procedure. Fortunately there is a handy tool, the Burp suite, that can aid in this test.
Fire up the Burp suite and configure the proxy for use with Firefox (as described in
Recipe 2.13). Turn the automatic intercept option off. Then, navigate to your web
application. Once Burp has recorded a request and response from your web application
in the proxy history, right-click on the request and select “send to sequencer,” as shown
in Figure 11-8.
The Sequencer tab will light up red; go ahead and click on it. Sometimes the Burp
sequencer can identify the session identifier (it refers to it as the “token”) on its own;
if not, you’ll have to highlight the session identifier yourself within the server response.
Burp will pick it up from there.
If you’re unable to find a session identifier, it’s likely because the server didn’t set one
via that response. Navigate to wherever in your site session cookies are first set. If you
don’t know where that is, open the Edit Cookies extension, set the filter to your site,
and delete all known cookies. Then, after browsing to each new page, refresh Edit
Cookies to display cookies for your site again—if one shows up, you know it was set
on this particular page response.
Once you have a session identifier located within Burp sequencer, press the Start Capture button on the lower right. This will send repeated requests to your application,
retrieving a new session identifier each time. Capture a statistically viable number of
session identifiers (we recommend 10,000—but 100 will work for a demonstration).
Once a sizable enough sample has been collected, pause the collection and select the
Analyze Now button.
11.5 Analyzing Session Identifiers with Burp | 225
Figure 11-8. Sending a request to the Burp sequencer
The results will contain a great deal of statistics, but the general summary is contained
within the first page, shown in Figure 11-9. In fact, the first line will tell you mostly
what you need to know. It will read that “The overall quality of randomness within the
sample is estimated to be:” very good, good, reasonable, poor, or very poor. The rest
of the statistics are there if you need them.
The Burp sequencer can’t provide 100% assurance that your session IDs are truly random. That would take an advanced degree relating to statistics and information theory,
towards the beginning of which you’d learn that 100% assurance is impossible. Meanwhile, if you don’t have time for an advanced degree, the Burp sequencer provides
extremely comprehensive analysis. It shouldn’t be trusted absolutely, but given the
choice between no statistical analysis and Burp, you should at least try Burp.
Ensuring session-identifier randomness can be difficult. The randomness will usually
be determined by the framework. Fortunately, this test can be performed as soon as a
session is set, even if not a single page of the application is working. If the developers
build a “Hello World” page that sets a session ID, you can run this test—long before
any problems relating to sessions start to become important. Because it can be done so
early, this recipe makes an excellent test to evaluate a framework.
226 | Chapter 11: Manipulating Sessions