- [Narrator] Another danger facing web applications
is the threat of cross-site request forgery.
These attacks are similar to cross-site scripting attacks
but even more nefarious. First, one quick note
on terminology for the exam. Cross-site request forgery
also goes by two acronyms. Some people call it CSRF
while others use the XSRF acronym.
Others even pronounce the acronym and call it "sea surf."
All of these terms refer to the same attack.
As you may recall, cross-site scripting attacks occur
when an attacker exploits a third-party website to
include scripts written by the attacker in input
shown to other users. The user's web browser then executes
that code when it visits the site.
Cross-site request forgery attacks go a step further
and prey upon the fact that users often have
multiple sites open at the same time and may be logged in
to many different sites in different browser tabs.
As you may have noticed, authenticated sessions
cross over between those browser tabs.
Cross-site request forgery attacks leverage this
by using one site to trick a user's browser into
sending illegitimate requests to another site
without the user's knowledge.
Let's take at another example of how this
authentication works. As you can see here,
I'm logged into LinkedIn in this browser tab.
I also have other tabs open: ESPN. If I go ahead
and open a fourth tab and type in the LinkedIn.com URL,
I get to the LinkedIn site and as you can see,
I'm already logged in. My browser has an
authentication cookie from LinkedIn that works
across all of these tabs. In fact, I could actually close
this window completely, open a new window,
and my authentication cookie would still allow me
to get into LinkedIn without typing in my
user name and password again.
This is a great convenience for users because it prevents
them from having to log into sites multiple times.
Cross-site request forgery attacks prey upon these
persistent authentication sessions in a manner
similar to a cross-site scripting attack.
Let's assume that we have an online payment service
that accepts account transfers using web requests
like the one you see here. The transfer funds page
takes several arguments. The amount of transfer,
the source account number, and the destination
account number where the funds should be deposited.
Now an attacker that knows this can try to exploit it
using a cross-site request forgery attack by attempting to
trick users into sending this command
without their knowledge. One of the easiest ways to do this
is to include a fake image tag in a web page
that actually executes the desired command.
Let's return to the example of an online auction site
that we used in the video on cross-site scripting
and try to use it for cross-site request forgery.
Here's our input, but I've added in another image tag
down at the bottom of the screen. This image tag attempts
to transfer funds from the user's checking account
to the attacker's checking account.
When the user loads the page, the boat sales listing
looks completely normal, but the invisible image
added to the page actually executes
the unauthorized bank transfer.
That's cross-site request forgery.
Defending against cross-site request forgery is
very difficult and often requires rearchitecting
web applications to use cryptographically strong tokens
in each exchange between authenticated users
and a website. Other measures include preventing the use
of HTTP GET requests to make cross-site request forgery
attacks more difficult, advising users to log out when
they're finished using a site and because they
probably won't follow that advice, automatically
logging users out after a short idle period.
This is an inconvenience to end users, but it reduces
the likelihood that those users will fall victim
to a cross-site request forgery attack.