Tải bản đầy đủ - 0 (trang)
4  Analyzing Session ID Expiration

4  Analyzing Session ID Expiration

Tải bản đầy đủ - 0trang

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.

Browser close

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

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

4  Analyzing Session ID Expiration

Tải bản đầy đủ ngay(0 tr)