Cross-Site Request Forgery
Have you ever seen articles about how hackers stole data from Facebook using external applications?
How can these applications steal data from users? Well, when you access an application, such as a social network, you just enter your credentials once; after that, the applications create identifications, such as sessions, to track the users. These sessions and other data need to be stored somewhere, and usually, the best place to store them is in cookies.
Cookies are files in your computer that are stored temporarily so that they can be accessed by applications. This means that you do not need to enter your username and password each time you access Facebook, you just need to do it once, and then when you access Facebook, Facebook will ask to your browser for a cookie; if the browser has it, Facebook reads the session stored in the cookie, and automatically enters your account. Great!
You can access the cookie's information directly in your web browser, as shown in the following screenshot:
The main problem is that cookies are not controlled by the application; if a user, or even a third-party application, modifies the cookie, Facebook cannot know whether the information stored in the cookie is real. Facebook can only determine whether it is valid, depending on the data structure, and confirm it using the internal registers in its databases.
So, if a user has access to your session stored in a cookie, they do not need your username or password to access your account. This model is also extended in all kinds of applications.
Cross-Site Request Forgery (CSRF) is a type of vulnerability focused on attacking the user, and performing actions on an application, using a fake origin. To do that, CSRF takes advantage of all the possible information stored in the browser that could be used to perform the action without more user interaction.
We will be covering the following topics in this chapter:
- Protecting cookies
- Why CSRF exists
- Detecting and exploiting CSRF
- Cross-domain policies