Hello and welcome to the cyber very secure coding course. My name is anywhere, and this is Boa's top 10 for 2013 a eight cross site request. Forgery Now. First, our definition
cross. I request forgery, by the way, is usually turned to see surf. Or you can also see it shone with an ex so C S R f or X s r f refer to the same thing.
So a sea surf attack forces a logged on victims browser to send a forged http request, including the victim's session cookie and any other automatically included authentication and from information
too vulnerable Web application.
This allows the attacker to force the victim's browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
We're gonna talk about the nuances of sea surf attacks. But the difference between sea surf attack
and the broken authentication type attacks that we saw earlier
is that in the case of Caesar,
very little by way of authentication that's needed to be done.
And so jet. Generally speaking, it's really relying on the victim being logged into the targeted application
ah, and then piggybacking on that authenticated session. So if we take a look at the OAS charts, we can see that the
attack vector of exploit ability is average.
The technical impacts are moderate, but the weakness itself is very widespread.
Fortunately for secure code developers, it is easy to detect.
Now See Surf, as it mentions here, takes advantage of a Web application
that allows Attackers to predict all the details of a particular action.
Since browsers SIM credentials like session cookies automatically, Attackers can create malicious Web pages, which generate forged requests that are indistinguishable from legitimate ones.
So if we think about this, what the focus is here for a sea surf attack
is the actions that are done inside of a Web application.
So when we talked about
the session fixation and things like that, we were more focused on the cookie, whereas here were more focused on the operations of the Web application and the attacker is essentially
unintended operations made by the victim unbeknownst to them, and we can illustrate the scenario in the following way, starting at the top number one, our victim signs into their stock trade account,
and they leave their browser open to that site they don't sign off of their account and they don't close their browser.
Then step number two. The victim decides to open another tab in that browser and just happens to go to either a compromised, very well known new site, like CNN or or some other site
that may have some sort of injected I'm frame or malicious script on the page. And then the details of the request that are for the stock trade application are actually
from the compromised news website. This is because the operations of the ABC trade website
our pre known by the attacker
and, of course, the ABC trade website doesn't have any kind of protection against sea surf attacks.
And so what happens is there's an auto load of the evil script in the background, this job script
that request some transfer of funds that are taken from the victim's stock trading account to the attacker own stock treaty account.
that script is at step number three, automatically executed by the browser and goes to the trade website on the Attackers Behalf
for the sample attack code for performing C sir attack.
Basically, you're going to see where an attacker would create a forged request
piggybacking on that logged in victim. And, of course, the request is going to match
the operation format that the targeted website is expecting.
But basically whatever is injected into the legitimate session
will allow or perform unintended requests
that are then sent to that targeted Web server by the victim, using the victim's legitimate session
without the victim's knowledge or consent.
Now our case study is Pei Pao.
Basically pay Pal had put in an anti see serve token to combat see surf attacks.
The problem was that the token could be easily acquired even before logging in. This particular researcher actually discovered this was able to create
a successful request with an actual forged see serve token that he had gotten from a response prior to even logging in, and he was able to prove that he could bypass
there. There ain t C serve token mechanism and perform operations in papal without being the legitimate user.
And so there were actually several design flaws in this particular implementation of
in anti See serve token,
but it's a good example how, even if you implement
some anti Caesar of tokens, you do have to ensure that they are done properly,
that they're done securely. That password resets are taken into account,
that tokens air changed upon log in
and that these different scenarios that are looked at and tested on prior to go into production.
So now we're gonna move into the demo portion of our module.