What if an attacker could forge HTTP requests to your site, they could trick your users into stealing information or performing many unintended actions of the user, like ‘stealing’ the discount code for example, losing a discount code thought it was angry )). Obviously this is very bad news for users, this article will give you the concept, risks, how to operate, how to prevent this attack.

Concept

I will go from the previous example When creating a website, we tend to code client-side and server-side together. We build the page and the form so that the user can interact on the client-side , then build server-side URLs return data when the user submits. However, requests can be deceived to server-side from any source, not just from the client-side we create. This is one of the parts where the internet was designed: “It allows linking between sites”. But it is also a common source of Cross-site request forgery (CSRF) .

CSRF occurs when users are deceived when interacting with a third-party page or script containing malicious request to your site. Your server will be deceived that HTTP request are sent from authenticated users. However, the attacker has taken control of the form of the submitted data.

Imagine running a micro-blogging service that lets users tweep their opinions every 140-character-sized chunks . As with every example in the series, Mal is still the villain, he’s a hacker and he warned that posts on your service could be generated by GET requests . This means all information will be displayed in the URL bar. Mal modified the post-creation URL to assign additional payload containing malicious code www.tweeper.com/post?message=This+horse+know+karate!+www%2Cbit.ly%2F60138Wawd .

Now he can find some ways to trick victims into accessing the url in their browser. Vic – a young, gullible, and even darker user in the system where your CSRF flaw exists. Mal can guess Vic’s email and send Vic an email with an attractive link with the text ‘This horse knows karate!’ , so curious , who has seen any horse knows where karate ever, click to see stars. Vic has no doubt, clicked on the link, and then your server started translating the request as Vic wrote this article, and created it on Vic’s timeline, obviously this is not an action of Vic intended, but Vic may not have been warned about what just happened (sounds serious

Posts with attractive content enough for others to click, when they click, they continue to be fooled the same way Vic encountered. And now, your site has a big worm filled with posts with the same content, but what if it’s propaganda support for Tran Dan? You don’t want to get in trouble like this.

content

Risky

Hackers can be used as a means to:

• Steal confidential data.
• distribute worms on social networks.
• Install malware on phones.
• Online survey.

It is difficult to estimate the prevalence of a CSRF attack. CSRF is often described as one of OWASP’s top ten security vulnerabilities.

Protect

The site includes a combination of server-side and client-side . The client side, including HTML and JS, is rendered and executed by the browser. It allows users to navigate to another url on your page, sending the HTML form to the server via an AJAX request – JS. Server-side will intercept data from HTTP Request .

server-side actions can be deceived by fake HTTP request , unless you explicitly provide protection.

For protection, two things are required:

• Make sure GET request is side-effect free .
• Make sure GET request are originated from your client-side .

REST

You can learn about REST as a series of design principles . Following REST-ful designs will keep your code cleaner and help your site scale. Moreover, REST asserts that GET request will only be used to view resource , keeping your GET requests of side effects, limiting risks, and that attackers will have to work harder to attack with. POST requests .

Anti-Forgery Tokens

Even if corrective actions are restricted to non-GET requests , you are still not completely protected. POST request still sent to your site from scripts and from sites hosted on different domains. To ensure that you only handle valid requests, we should add a unique and secret token with each HTTP response , the server will authenticate the token and return it in subsequent requests using the POST method (or with All methods except GET).

This is called an anti-forgery token. Every time your server displays a page performing sensitive actions, it will write out an anti-forgery token in the hidden field. This token must be included in form submissions or AJAX calls. The server authenticates the token when it is returned in subsequent requests and rejects any calls with missing or invalid tokens.

Anti-forgery tokens usually strong (random) numbers stored in cookies or on the server when they are written to a hidden field. The server compares the Anti-forgery tokens attached to the incoming request with the value stored in the cookie. If the values ​​are identical, the server will accept valid HTTP requests.

Most modern frameworks include functions to add Anti-forgery tokens quite simply.

Make sure that the Cookie is sent with the SameSite attribute

Google Chrome aadx adds a new attribute to the Set-Cookie header to help prevent CSRF , and it is quickly supported by other browsers. Same-Site cookie attribute allows the dev set the browser to control whether cookies are sent by 3rd party domains.

Setting Same-Site for cookies is quite simple:

Includes additional authentication for sensitive actions

Many sites require 2-step authentication or password re-entry when performing ‘sensitive’ actions, which greatly reduces the likelihood of CSRF attacks.

Code Samples

With Laravel you can refer here

For pure PHP, you can refer here .

summary

Above is the content to help you have a basic understanding of CSRF , hoping to help readers. Happy coding!