the-web-application-hackers-handbook

Chapter 7 n Attacking Session Management 229
Figure 7-6: Configuring Burp Intruder to modify an encrypted session token
Figure 7-7 shows the required payload configuration. It tells Burp to operate
on the token’s original value, treating it as ASCII-encoded hex, and to flip
each bit at each character position. This approach is ideal because it requires a
relatively small number of requests (eight requests per byte of data in the token)
and almost always identifies whether the application is vulnerable. This allows
you to use a more focused attack to perform actual exploitation.
When the attack is executed, the initial requests do not cause any noticeable
change in the application’s responses, and the user’s session is still intact. This
is interesting in itself, because it indicates that the first part of the token is not
being used to identify the logged-in user. Many of the requests later in the attack
cause a redirection to the login page, indicating that modification has invalidated
the token in some way. Crucially, there is also a run of requests where
the response appears to be part of a valid session but is not associated with the
original user identity. This corresponds to the block of the token that contains
the uid value. In some cases, the application simply displays “unknown user,”
indicating that the modified uid did not correspond to an actual user, and so the
attack failed. In other cases, it shows the name of a different registered user of
the application, proving conclusively that the attack has succeeded. Figure 7-8
shows the results of the attack. Here we have defined an extract grep column
to display the identity of the logged-in user and have set a filter to hide the
responses that are redirections to the login page.