Tải bản đầy đủ - 0trang
6 Analyzing Session Randomness with WebScarab
Figure 11-10. Finding Set-Cookie headers with WebScarab
Select the Summary pane in WebScarab and look in the Set-Cookie column. Figure 11-10 shows this summary pane. Request ID 9 is highlighted because it is one of
many that have cookies. We will use this request as our request to analyze.
Select WebScarab’s “SessionID Analysis” pane and look at the “Collection” tab within
that pane. Click the drop down next to “Previous Requests” and select the request that
will set the session ID. Figure 11-11 shows the list, with request 9 selected. Once you’ve
selected an appropriate request, press the Test button. This will bring up a message
indicating all the session IDs WebScarab was able to find automatically within that
request. Figure 11-12 shows the result of such a test. Two cookies are visible in this
Set-Cookie header: phpMyAdmin and pma_fontsize. The fact that the contents of phpMyAd
min are opaque strings like z316wV-lrq0w%2C-8lPF6-uvObKdf and the fact that the other
parameter’s name suggests that it controls font size leads us to focus on phpMyAdmin.
Once you’ve found an appropriate session ID to model, enter a sample size. We recommend at least 500 or more for a smooth graph. It’s better to do 1,000 or 2,000 if you
can. Then click the Fetch button to initiate the requests. Each will receive a different
To see the graph, you must first go to the Analysis tab and select the session identifier
you’d like to visualize. Figure 11-13 shows the Analysis tab, with our phpMyAdmin cookie
selected. Select that from the drop down options. There may be only one session identifier available; that’s fine. With your session identifier set, click on the Visualization
tab. If WebScarab is still fetching session identifiers, you’ll see them show up in real
time on this graph—a powerful demonstration in itself. Furthermore, there should be
no obvious pattern in the visualization graph. If there is, it’s likely the session identifiers
are easily predictable.
228 | Chapter 11: Manipulating Sessions
Figure 11-11. Selecting the request to test for session IDs
Figure 11-12. Testing a request for session IDs
WebScarab’s analysis of session identifiers, while statistically weaker than Burp’s, provides a much more convincing diagram. Some patterns are readily apparent in the graph
of session identifiers over time. Figure 11-14 shows a real web server that has relatively
predictable identifiers. They’re not as bad as sequentially issued integers, but with some
effort a hacker could develop a program to predict them. This sort of graph can provide
the extra step you need to demonstrate predictability. A clearly visible pattern makes
a stronger impression than statistical confidence intervals.
11.6 Analyzing Session Randomness with WebScarab | 229
Figure 11-13. Choosing the session ID to plot
Figure 11-14. WebScarab visualization: relatively predictable
Consider the ten session IDs shown in Example 11-2. Visually inspecting them, you
might think they were pretty random. Aside from the LL6H at the beginning of each,
they are very long and they appear to have lots of randomness. They are from the same
site that produced the graph in Figure 11-14, however, which shows how a little visualization can go a long way towards making the pattern clear.
Example 11-2. Session IDs from WebScarab
230 | Chapter 11: Manipulating Sessions
Clear lines or shapes within the graph indicate poor randomization. When testing an
application, it’s easy to get pseudorandom results and not see an obvious pattern. Laying out the results in such a graph reveals some (but not all) patterns immediately. Truly
comprehensive analysis requires statistical analysis, such as the methods used by Burp.
Note that WebScarab will find all sorts of identifiers inside cookies, not just session
identifiers. It may also find non-random identifiers that record visitor details. Not every
cookie value needs to be random. Don’t be alarmed if one of the identifiers you select
for visualization is a flat, completely predictable line. It may just be a non-unique token,
rather than a session identifier.
That said, some applications will implement multiple session identifiers to track different behaviors. If you do find an alternate pseudosession identifier, such as “visitor
number,” go ahead and examine the predictability. It may be that by tampering with
some other identifier, one is able to trick the application into doing something nonsession related, but still just as problematic.
Figure 11-15 shows an example of a session identifier that does not appear, visually, to
be predictable. Remember that your application can fail this test, but cannot pass it.
That is, just because your session IDs are not obviously predictable from visual inspection doesn’t mean they’re random. If you are very concerned about them, perform
statistical analysis such as we discuss in Recipe 11.5.
Figure 11-15. WebScarab visualization: unpredictable
11.6 Analyzing Session Randomness with WebScarab | 231
Figure 11-16. Deleting cookies
11.7 Changing Sessions to Evade Restrictions
As discussed in Recipes 9.8 and 9.10, 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.
This recipe only applies if your application prevents an attacker from attempting to
guess or sequentially attempt passwords, identifiers, or credentials. Determine whether
or not your application meets these criteria via Recipe 9.8.
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 11-16 shows the delete options. Click the Delete All option to erase all cookies, and
hopefully all sessions, for your domain.
232 | Chapter 11: Manipulating Sessions
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.
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!
11.8 Impersonating Another User
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.
Via Edit Cookies, identify the authentication or authorization details being stored in
cookies. You may need to decode these details, using techniques found in Chapter 4.
We’ll go through the ramifications of each type of stored detail one by one:
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. Using some of the Perl techniques described in Chapter 8, an
11.8 Impersonating Another User | 233