We'll start with another topic in the U.S. The cross site request forgery also called as SRF crosschecked
request forgery, also known as serious.
Ariff is an attack whereby an attacker tricked the victim and performing actions on their behalf.
The impact of the attack depends on the level of permissions that the victim has.
Such attacks take advantage of the fact that the website completely trusts the user.
Once it can confirm that user is indeed who they say they are on your screen, you can see that the
attacker has crafted his own Yodle and when the user clicks under the URL, the email gets directly
changed without even the user knowing what has happened, actually.
So how are CSIR attacks executer?
There are two parts to executing a charoset request forgery attack.
The first one is tricking the victim to clicking a link or loading a page.
This is normally done through social engineering and malicious link.
The second part is sending a crafted, legitimate looking request from the user's browser to the website.
The request is sent with values chosen by the attacker, including any cookies that the victim has associated
with that website.
This way, the website knows that this victim can perform certain actions on the website.
Any requests and with these HTP credentials or cookies will be considered a legitimate request, even
though the victim would be sending the request of the attackers or on the attackers command.
Consider this example that I walk into a bank and I tell them that I'm you.
I withdraw all of your money.
I've just committed an act of gross human request forgery, and therefore I have your money.
In other words, I pretended to be you and performed an unwanted action on Germany Crossette because
forgery is a type of attack that occurs when a malicious website, email, blog, instant message or
program causes a user's web browser to perform an unwanted action on trustor site for which the user
is currently authenticated to it.
Also pretending to be you or more correctly, doing something with your credentials while you are completely
unaware it.
So let's move ahead to see a side of countermeasures.
The first one is use building or existing a of implementations for self protection.
The synchronizer token defenses have been built into many frameworks we strongly recommended to reset.
The framework you are using has an option to achieve a set of protection by default before trying to
build your custom token.
The rating system, for example, dot net has built in protection that adds a token to seize upon real
resources.
You are responsible for proper configuration, such as key management and token management for using
this building.
See a set of protections that generate tokens to guard, see a set of vulnerable resources.
The next is Synchronizer token pattern.
See yourself.
Tokens should be generated on server side.
They can be generated once per user session or for each request per request.
Tokens are more secure than pulsations.
For example, the back button browser capability is often hindered as the previous page may contain
a token that is no longer valid.
Interaction with this previous page will result in a C srf false positive security even at the server
side implementation token implementation of the initial generation of the token.
The value is stored in the station and is used for each subsequent request until the station expires.
The next, you see a set of tokens should not be transmitted using cookies the CSF have, Copelands
can be added to hidden fields headers and can be used with forms and AJAX calls.
Make sure that the token is not leaked in the server logs or in the user.
The next is encryption, based on the encrypted token Padam leverages and encryption rather than comparison
of the token validation.
It is most suitable for applications that do not want to maintain any state, the server side.
And last, it seems that attribute seems like it is a cookie attribute similar to its GDP, only secure
and minimal, which aims to mitigate severe sort of attacks it has defined in our F.C. six to six forbids.
This attribute helps the browser to decide whether to send cookies along with Charoset requests.
It is important to note that this attribute should be implemented as an additional layer defense.
In concept, this attribute protects the user to the browser supporting it, and it contains as well
two ways to bypass the attribute should not replace having a series of token.
Instead, it should coexist with that token in order to put the user in a more robust way.
I know this is a little bit hard to understand, but if you are really keen to understand what is serious
and how to protect yourself, you can go to the books attached with this course.
See you in the next lecture.