CSRF attack and surrounding issues

Tram Ho

A little introduction to Web Cookies

Because HTTP is a stateless protocol, previous and subsequent requests are not related to each other. HTTP cannot distinguish one user from another. To solve this problem, cookies were created to distinguish users from each other. The server will set the cookie for the browser to save, then every time the request is sent, the browser will add this cookie code and send it to the server.

When a request is sent from the browser to a website, the browser checks to see if the cookie value the browser stores on that server. While doing this, it checks to see if the cookie’s attributes, flags (domain, URL, httponly, secure, etc.) match the data stored in that website. If they match, the browser will send the relevant cookies along with the request.

So what is CSRF (Cross-site Request Forgery)

CSRF or XSRF is a type of attack that relies on authenticating requests on websites through the use of cookies. To put it plainly, when you visit an Attacker website, Attacker automatically makes a request to the target page that all cookies are stored in the user’s browser with the target page added automatically. In other words, a session on one page may be used by another. This is the crux of the CSRF attack.

In industry jargon, this type of browser abuse is called CSRF (Cross-site Request Forgery). It is a web security hole that allows Attacker to force users to perform actions they are not intending to perform. This bug can be exploited by Attacker to track users or ads.

Example of CSRF

We have a simple web page that shows the username abc .

Inside this website, there is a function called Change Your username to change the username, and I used this function, wrote a code like the following and pushed it to another website. When the user enters the web page containing this code, the target page’s username will be changed to pwned .

So how to prevent CSRF

  • Normally you can avoid tracking like this in Firefox and Chrome. However, when blocked like that, they will prevent sending cookies along with the request of any 3rd party websites. So your browsing experience will be very bad. So, by blocking cookies, you can completely block CSRF, but in exchange for your experience on the internet I bet it is not fun.


  • Having a new cookie attribute, Chrome began supporting support on March 29 and was followed by other popular browsers. That is called the Same-Site Cookie property. Developer teams can instruct the browser to control whether cookies are sent along with requests made by third-party websites, using the Same-Site cookie attribute. This is a more practical solution than refusing to send cookies.
  • Setting the Same-Site property is quite simple, it only needs to add the sameSite value to the cookie, for example:

Try resetting SameSite = Lax and try the example above again

SameSite has performed its role well, it has prevented CSRF attack. But why are there two types of SameSite: Lax and Strict here, it was born to prevent CSRF only. So we can continue to learn about comparing the 2 types of SameSite

Differences between Lax and Strict SameSite


  • As the name suggests, this is an option where the Same-Site rule is strictly enforced. When the SameSite property is set to Strict, cookies will not be sent along with requests initiated by 3rd party websites.
  • Setting cookies to Strict can negatively affect the browsing experience. For example, if you click on a link that leads to Facebook’s profile page, and Facebook.com sets its cookie to SameSite=Strict then you cannot continue redirecting on Facebook unless you log back into Facebook. The reason is because Facebook’s Cookies are not included with this request.


  • When you set the SameSite property of the cookie to Lax, the cookie will be sent with the GET request generated by the 3rd party.
  • Why only accept GET requests, actually it accepts other request methods like GET, HEAD, OPTIONS, TRACE. Because these are supposed to be “Safe” requests defined in section 4.2.1 of RFC 7321. But here we are only interested in GET requests.
  • For the above example, since the POST method is of an “insecure” HTTP type, Cookies are not sent when SameSite=Lax .

Are we going to say goodbye to CSRF

  • It looks like the SameSite cookie attribute is an effective security measure against CSRF attacks.
  • The popularity of CSRF is going down, proving that CSRF is in the 5th position of OWASP’s Top 10 list published in 2010, but it is down to 8th position in 2013. And now We don’t see it in OWASP’s Top 10 list anymore.
  • The most popular browser currently, Google Chrome, has also had SameSite updates

Sept 26, 2019

Starting in Chrome 80, cookies that do not specify a SameSite attribute will be treated as if they were SameSite = Lax with the additional behavior that they will still be included in POST requests to ease the transition for existing sites. Cookies that still need to be delivered in a cross-site context can explicitly request SameSite = None, and must also be marked Secure and delivered over HTTPS. We will provide policies if you need to configure Chrome Browser to temporarily revert to legacy SameSite behavior.

Cookies default to SameSite = Lax

Treat cookies as SameSite = Lax by default if no SameSite attribute is specified. Developers are still able to opt-in to the status quo of unrestricted use by explicitly asserting SameSite = None.

The Stable version of Chrome 80 is targeted for enabling this feature by default. This feature is available as of Chrome 76 by enabling the same-site-by-default-cookies flag. See https://www.chromium.org/updates/same-site for full timeline.

  • Besides, Firefox has also updated the Same-Site in FireFox version 69.

  • So we can hope that one day CSRF will not be there anymore.


Share the news now

Source : Viblo