The cross-site
request forgery attack
is sometimes called a one-click
attack or session riding.
And you may see it
abbreviated as XSRF or CSRF
we often refer to
this as sea surf.
What's interesting
about this attack
is it takes advantage
of the trust
that a web browser and a web
site have with each other.
When you authenticate
to a website,
you log in everything
now between that browser
and that website is
trusted to be you.
In a cross-site
request forgery attack,
the bad guy takes
advantage of that trust
to perform functions
for themselves.
This is the type of
attack that should never
happen if the applications
on the web site
are developed properly.
The application should have
anti-forgery techniques.
Often cryptography
and encryption
is involved to make sure
that other users can't send
a request using your browser.
Here's how a cross-site
request forgery works.
There are three devices
that are operating.
Here we have first our bad guy.
Then we have a visitor
to the bank site.
This is someone who's logging
in to their normal bank account.
And then we have the
bank web server itself.
In the first step
the bad guy is going
to create a funds
transfer request.
This is not a request that's
going to come from his account.
It's going to come from
someone else's account,
but of course he needs
someone else to perform
this transfer for him.
So he's going to send this
hyperlink to a third party
user.
This might be in a message,
it might be an email.
But he's going to somehow
get that URL to a bank site
visitor, who's already logged
in to their bank site account.
They're going to see this link.
They're going to
click on that link.
Which is then going to send a
request to the bank web server
to perform the web transfer.
The bank site's visitor is
going to click on this link.
Which is going to send a message
to the bank web server telling
the web server, please perform
a transfer from my account,
and send that transfer
off to the bad guys.
That transfer is
validated by the bank.
It sends that transfer.
And just like that, you've
now transferred money
from your account to
the bad guy's account
without even realizing
you've done it.
You can see now why it's so
important that the application
developer create their
applications to really
validate, that all of the
requests coming from a bank
site visitor originated
on that device.
You don't want a third party
sending those messages in
and having all of
these funds transferred
without some type of validation.
