In the previous video, we looked into an error which is resulted from Crosseyed request for the issue,
which is famously called as Casares in the industry.
So CSR will come in any Web application whenever someone tries to make a board or delete such kind of
operations, which will result in data change on the database by default, CSR issue will block your
operations.
It's nothing related to the cross origin, even if you are trying to perform the operations like your
UI and back in the stay on the same post on board and domain still will get in to CSR issues.
The reason is a typical cross site request forgery, which is CSR of attack, aims to perform an operation
in a Web application on behalf of Lobban user without the explicit consent that many with the hackers
can attack other users.
Maybe you have taken enough measures not to steal their credentials, but CSR is one of the smartest
approach where the attackers can exploit.
If you don't handle it properly.
So consider the scenario where we have it to website Netflix dot com and attack US websites and travel
black dot com.
So as a Netflix user, I can turn my credentials and I logged in.
Now, in a hypothetical scenario, let's think about a scenario where Netflix is maintaining a cookie
inside my browser.
So as long as I'm inside the same browser and making any request for the request to the Netflix, it
won't ask my credentials.
It will just rely on the cookie to perform any operations on the back.
So now I have a valid cookie present on the browser and now I'm navigating to the travel black dot com
where attackers have a link which will change my password on Netflix dot com.
So when attack attempt to click on the link.
As soon as you click on the link, it will send a legal request to Netflix dot com to change the password.
And since you already have a cookie inside your browser, Netflix dot com will accept and treat it as
a valid cookie and change the password, which is a security exploit here to avoid the sort of attacks.
There are many ways, but first of all, you can see here in the diagram, firstly, the user logged
on into a proper website like Netflix dot com, and he has an active social networking site.
His browser, not the same user, clicked on some malicious link, which is built by Hacker.
And as soon as users click on the link, it will take the cookie inside your browser related to Netflix
dot com and send a request to Netflix dot com to change the password and Netflix dot com.
Treat it as a genuine request because the cookie value, the water token that you stored inside the
cookie is given by Netflix itself during the first login.
That's why even Netflix dot com also cannot identify whether the request is coming really from a valid
user or from attack.
You may say this may not be a possible if the user will not click on the link, but we can't control
all those user activities.
But what we can do to avoid this sort of attack inside our application is by maintaining its CSR.
So CSR is a token which is issued by your backend application when the first communication happens from
the user to Netflix dot com, like during the login of the user.
So that token will never be stored into the browser.
Share our browser cookies, but it will be given to the WHO are calling us application or browser.
They have to make sure that they are passing the same token value whenever they try to want a communication
with the back.
So now my back end, though, I'm passing a valid security token letter to my login mechanism.
But still it will expect me to pass it CSIR.
If I don't have a sort of token valid one which pass, then it will block the communication using it
for zero three for an error.
So that means on top of your authentication token, which you are maintaining inside your cookie, we
are also maintaining a sort of token that is tied to user session, but it is not submitted automatically
like cookies.
And you have to make major.
To send that token every time when we are making a request to them back and so so now we have a clear
idea of what sort of attack, let's try to see different ways of handling this or resolve this error
in spring security.
Thank you by.