cross-site request forgery also known as csrf consists of multiple words of them are cross and sight meaning the attack is happening across multiple websites where one is legitimate and one is malicious usually that is happening in your browser requests means that the website is going to request some data from the server or tell the latter to perform a certain operation request forgery means that the attacker can use some data from the original website and craft a request to a server that looks exactly the same as the legitimate one the web server will not be able to differentiate between the legitimate and force requests as they are coming from the same place hence it's going to approve both actions even the biggest platforms aren't immune to this attack in 2020 Tick Tock suffered that exact vulnerability which allowed attackers to perform a one-click account takeover by changing user passwords in 2008 a CSR vulnerability on YouTube allowed attackers to perform actions on behalf of any users such as sending messages commenting videos and so on and so forth the same year the most classical of them all ING Direct it's a Dutch bank had a csrf vulnerability that allowed attackers to transfer money from users accounts even though those vulnerabilities were fixed there can be many more stayed undiscovered but how that type of attack is possible in the first place that's what I'm going to be covering in this video foreign what's happening we need to have some basic idea of how their browser Works under the hood and how it interacts with the server when we open our browser we enter a URL inside the address bar What's Happening Here is that our browser makes what's known a get request to a banking web server to retrieve a web page two things here to clarify get type of request intend to retrieve the data in fact we send get request every time when we navigate to URL in the browser it goes to a banking web server rather than other web servers because well we told it so in the URL as in my example I used bank.com Bank server will generate a sender response with a login form which is what we're going to see in our browser to prove to the server that I actually who I say I am and can authorize transfers from my bank account I'm going to enter my username and password into the corresponding Fields once I hit enter my username and password are going to be sent to the server and that's where the most interesting part happens once the credential is validated the server is going to generate a random string that is going to be associated with my identity so I don't have to log in each time you probably experienced it in your daily life you only log in once and then do payments transfers or simply celebrating your latest paycheck until the banking website logs you out after some time that random string that is generated is called session ID we are not going to dive deeper into internal mechanisms and for our example it's an app to understand that the session ID would substitute our username and password and will prove to the server that I actually the account owner in would associate this session an ID with my identity where the interesting part you ask well the server is going to send response back and will instruct the browser to store the session ID inside something called cookie the cookie is like internal storage for the browser yes it's exact same thing that you accept every time you visit a website you can have many cookies for different websites and all of them are stored in the browser the key part here that is important to remember is that corresponding cookies are sent in every request to a web server for example Google's cookie are sent to Google Facebook cookies are sent to Facebook banking cookies sent to banking web server and so on and so forth that's to be expected because otherwise how would server know that I actually who say I am okay now let's say we're ready to pay the bill by transferring our funds we're going to get a form on the banking website and click button that would send the instruction to a banking web server if we have sufficient funds the operation will be successful it was possible in the first place without entering login password because our session ID cookie was automatically sent to a server these automatic send cookie behavior is actually what makes the attack possible what happens is that the attacker creates a website with code that runs a malicious request for example transfer funds change password Etc usually that code is represented by hidden form but it may be image some advertisement or any other means usually its exact same copy of the genuine form of the banking website with a couple of values changed it's very possible to get the code of any form if you just inspect the website in the browser once you click desired link a hidden form would send a request to a banking website because cookies are sent on every request the browser would automatically grab the session ID and attach it to that very unintended request the server would have no idea because the only thing it would see is the session ID since the session ID is valid the server would say hey sure yeah the transfer is approved resulting in the bank transfer account takeover you name it that is a csrf vulnerability in its most simplest form there are other attack variations but they all about the same scenario performing unintended actions on behalf of the user without him knowing it so how do we protect against it this what I'm going to be covering in my next video stay tuned