the-web-application-hackers-handbook

Chapter 13 n Attacking Users: Other Techniques 537
if the targeted application uses only HTTPS and its cookies are flagged as
secure. This kind of attack is described in more detail later in this chapter.
If an attacker can set an arbitrary cookie, this can be leveraged in various
ways to compromise the targeted user:
n Depending on the application, setting a specific cookie may interfere
with the application’s logic to the user’s disadvantage (for example,
UseHttps=false).
n Since cookies usually are set only by the application itself, they may be
trusted by client-side code. This code may process cookie values in ways
that are dangerous for attacker-controllable data, leading to DOM-based
XSS or JavaScript injection.
n Instead of tying anti-CSRF tokens to a user’s session, some applications
work by placing the token into both a cookie and a request parameter and
then comparing these values to prevent CSRF attacks. If the attacker controls
both the cookie and the parameter value, this defense can be bypassed.
n As was described earlier in this chapter, some same-user persistent XSS
can be exploited via a CSRF attack against the login function to log the user
in to the attacker’s account and therefore access the XSS payload. If the
login page is robustly protected against CSRF, this attack fails. However,
if the attacker can set an arbitrary cookie in the user’s browser, he can
perform the same attack by passing his own session token directly to the
user, bypassing the need for a CSRF attack against the login function.
n Setting arbitrary cookies can allow session fixation vulnerabilities to be
exploited, as described in the next section.
Session Fixation
Session fixation vulnerabilities typically arise when an application creates an
anonymous session for each user when she first accesses the application. If the
application contains a login function, this anonymous session is created prior
to login and then is upgraded to an authenticated session after the user logs in.
The same token that initially confers no special access later allows privileged
access within the security context of the authenticated user.
In a standard session hijacking attack, the attacker must use some means to
capture the session token of an application user. In a session fixation attack, on
the other hand, the attacker first obtains an anonymous token directly from
the application and then uses some means to fix this token within a victim’s
browser. After the user has logged in, the attacker can use the token to hijack
the user’s session.
Figure 13-4 shows the steps involved in a successful session fixation attack.