PART II
Chapter 7: Security Concerns 323
the AjaxBank, you do not invalidate the cookie by pressing some logout button nor close
your browser to end the active session. It may even turn out that you have some permanent
cookie as the site supports a “remember me” feature—either way, your credentials at the
protected site are still good and your session may even still be active. In other tabs, other
windows, or even the same window, you do subsequent work, you eventually visit a site
that has been compromised or is evil. A hacker with a script on this insecure site may be
interested in attacking AjaxBank so they first use the history detection script from the
previous section to see if the visiting user had been there. Once finding a potential victim
they would then add a <script>, <iframe>, or <img> tag to invoke a request to the target
site, in this case AjaxBank, and attempt to perform some desired action like changing a
password or transferring funds. Because the user is still authenticated, the previously issued
cookie(s) are sent with the request made by the hacker and it gets in. This attack even works
with an SSL connection in play! If you still aren’t clear on the scenario, a general overview
of how CSRF might be used is shown in Figure 7-13.
Understand that the same-origin policy does protect you a bit here. The response from
the CSRF request is done blindly by the hacker. They cannot see the result because the page
making the request is different than the one responding. However, that isn’t completely true
and it may not matter anyway as the hacker may have triggered some known action that
they can go and verify elsewhere.
What a hacker will do with CSRF varies. If they want to cause some mischief, they
might trigger bogus requests to be made to click advertisements or perform other small
“click” tasks they will make money from. They might look to cause trouble by issuing a
request that raises authorities to take notice of a site or individual. For example, imagine ifFIGURE 7-13 CSRF in action