The One-Click attack aka Cross-Site Request Forgery
Cross site request forgery, which we often refer as CSRF is simply a vulnerability that a web application might be having. Vulnerability is a fancy word i used and it implies the “Risk of getting attacked” not physically but virtually through a web application.
It is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
let’s Break this down
if someone executes unwanted actions like, follow your ex bf/gf in facebook , block your crush, unfollow the Gossip group you just joined it will cause a mini heart attack.. isn’t it?
A talented intruder can go up-to transferring all your money to an account in Chicago Citibank.
Through CSRF attackers can’t steal our data but make us do involuntary actions
It’s time to explain using some demonstration

Simpler way of reducing the risk
- Check standard headers to verify the request is same origin
- Check CSRF token
This is not rocket science. It’s simply examining an HTTP request header value
To identify the source origin, it is recommended to use one of these two standard headers that almost all requests include one or both of:
- Origin Header
- Referer Header
More Legit way of controlling CSRF
- Synchronizer Token Pattern
- Double Submit Cookies Pattern
We all know about cookies. A cookie is a baked or cooked food that is small, flat and sweet. It usually contains flour, sugar and some type of oil or fat. It may include other ingredients such as raisins, oats, chocolate chips, nuts, etc
just kidding…
Cookies are small files which are stored on a user’s computer. They are designed to hold a modest amount of data specific to a particular browser.
and the Synchronizer Token Pattern & Double Submit Cookies Pattern uses cookies
- Synchronizer Token Pattern (STP)
It’s a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side.
Let’s translate Greek to English
We have 2 sides in here, server side and client side . Server side is the website we visit and client side is the browser we use
In STP we need to extract a unique token generated by the server and send it with every request. This token is the CSRF token .So the server will validate the CSRF token against the session ID and allow requests to run on the server.
In here server always remembers the token. Client doesn’t have to do anything

the CSRF token is sent in each and every request
2. Double Submit cookies Pattern
If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. It is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

So if the attacker wants to run a java script on broccoli.com it won’t work
if it’s not chocolate.com the cookies will not be sent.
