www.invicti.com Open in urlscan Pro
2606:4700::6812:818  Public Scan

Form analysis
3 forms found in the DOM

GET https://www.invicti.com/

<form role="search" method="get" class="sub-nav-search-form" action="https://www.invicti.com/" __bizdiag="115" __biza="W___">
  <input type="text" placeholder="Type here to search..." name="s">
</form>

POST https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&id=c41662cd70

<form action="https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&amp;id=c41662cd70" method="post" target="_blank" class="maillist-subscribe" __bizdiag="66081660" __biza="W___">
  <input class="form-control" name="EMAIL" placeholder="Enter your email to signup for the latest posts" type="email" required="" value="">
  <button type="submit" class="btn btn--primary">Subscribe</button>
</form>

POST https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&id=c41662cd70

<form action="https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&amp;id=c41662cd70" method="post" target="_blank" class="maillist-subscribe" __bizdiag="66081660" __biza="W___">
  <input class="form-control" name="EMAIL" placeholder="Email" type="email" required="" value="">
  <button type="submit" class="btn btn--primary">SUBSCRIBE</button>
</form>

Text Content

Netsparker is now Invicti
Get a demo
AppSec with Zero Noise Get a demo
Get a demo
 * Product
   * Overview
   * Features
 * Why Us?
   * Solutions
     * Industries
       * IT & Telecom
       * Government
       * Financial Services
       * Education
       * Healthcare
     * Roles
       * CTO & CISO
       * Engineering Manager
       * Security Engineer
       * DevSecOps
   * Comparison
   * Case studies
   * Customers
   * Testimonials
 * Plans
 * About Us
   * Our Story
   * In the news
   * Careers
   * Contact us
 * Resources
   * Blog
   * White Papers
   * Webinars
   * Resource Library
   * Invicti Learn
   * Partners
     * Channel
     * MSSP
   * Support


Web Security Blog
 * Web Security
 * News
 * Product Releases
 * Product Docs & FAQs


Search Close search bar


USING THE SAME-SITE COOKIE ATTRIBUTE TO PREVENT CSRF ATTACKS

This article looks into the details of how the Same-Site cookie attribute works
and how it can be used to help prevent malicious cross-site request forgery
(CSRF) attacks.

Subscribe

Your Information will be kept private.

Stay up to date on web security trends
SUBSCRIBE

Your Information will be kept private.


INTRODUCTION TO WEB COOKIES

Because HTTP is a stateless protocol, it cannot internally distinguish one user
from another. To address this issue, cookie technology was invented in 1994. By
using cookies, servers instruct browsers to save a unique key and then send it
back with each request made to the server.

When a request is sent from a browser to a website, the browser checks if it has
a stored cookie that belongs to that website. While carrying out this process,
it checks to see whether the properties and flags of the cookies (domain, path,
secure), match the website’s data which has been requested. If they match, the
browser sends the relevant cookies along with the request.


COOKIES MISUSE CAN LEAD TO CROSS-SITE REQUEST FORGERY

This behavior is also repeated in the same way for requests made by third
parties through the browser. By “third parties” we mean other websites that we
don’t visit directly. The critical point from a web application security
perspective is that when you visit website A, all cookies kept in the browser
for site B will be added to the request initiated toward site B by site A. So, a
session that belongs to B on the browser can be used and even abused in this
way.

In security terminology, abusing this behavior of browsers is known as
Cross-site Request Forgery (CSRF).  It is carried out by misusing a session
belonging to an authorized user by using this browser behavior.

This browser behavior can also be misused for other purposes like tracking users
or advertising. When you enter a site, for instance example.com, your browser
may make a few requests to different sites because of the HTML elements placed
on the page of example.com, for example Facebook Like buttons, Google Analytics
code, etc. Along with these requests, the cookies in the browser that belong to
these other sites will also be sent. Therefore those third parties can track and
log your activity by using Cookie and Referrer information.


SHOULD YOU BLOCK CROSS-SITE REQUESTS TO PREVENT CSRF?

Normally, it is possible to avoid tracking like this in Firefox and Chrome
browsers.  However, when these browsers block tracking, they prevent the sending
of cookies along with the request made by any third party website. But by doing
so your browsing experience will be very poor. So by blocking cookies, you can
totally prevent CSRF, but is it worth the consequences?


INTRODUCING THE SAME-SITE COOKIE ATTRIBUTE TO PREVENT CSRF ATTACKS

Thanks to a new cookie security flag, that Google Chrome started supporting on
the 29th of March, and other the popular browsers followed, there is now a
solution. It is called the Same-Site cookie attribute. Developers can now
instruct browsers to control whether cookies are sent along with the request
initiated by third party websites – by using the SameSite cookie attribute,
which is a more practical solution than denying the sending of cookies.

Setting a Same-Site attribute to a cookie is quite simple. It consists of adding
just one instruction to the cookie.  Simply adding ‘SameSite=Lax’ or
‘SameSite=Strict’ is enough!

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;


DIFFERENCES BETWEEN THE STRICT AND LAX SAMESITE COOKIE ATTRIBUTES

Strict: As the name suggests, this is the option in which the Same-Site rule is
applied strictly.  When the SameSite attribute is set as Strict, the cookie will
not be sent along with requests initiated by third party websites.

Setting a cookie as Strict can affect browsing experience negatively. For
example, if you click on a link that points to a Facebook profile page, and if
Facebook.com has set its cookie as SameSite=Strict, you cannot continue
navigation on Facebook (view the Facebook page) unless you log in to Facebook
again. The reason for this is because Facebook`s cookie was not sent by this
request.

Lax: When you set a cookie’ SameSite attribute to Lax, the cookie will be sent
along with the GET request initiated by third party website.

The important point here is that, to send a cookie with a GET request, GET
request being made must cause a top level navigation. Only in this way, the
cookie set as LAX will be sent. Let me explain more.

Resources can be loaded by iframe, img tags, and script tags. These requests can
also operate as GET requests, but none of them cause TOP LEVEL navigation.
Basically, they don’t change the URL in your address bar. Because these GET
requests do not cause a TOP LEVEL navigation, thus cookies set to Lax won’t be
sent with them.

See the table below for more clarification:

Request TypeExample CodeCookies sentLink<a href=”…”></a>Normal, LaxPerender<link
rel=”prerender” href=”..”/>Normal, LaxForm GET<form method=”GET”
action=”…”>Normal, LaxForm POST<form method=”POST”
action=”…”>Normaliframe<iframe
src=”…”></iframe>NormalAJAX$.get(“…”)NormalImage<img src=”…”>Normal


DOES THIS REALLY MEAN “GOODBYE” TO CSRF?

Yes, it looks like the SameSite cookie attribute is an effective security
measure against CSRF attacks. You can avoid sending your cookies with the
request initiated by third parties by using this feature.  Let me clarify with
an example:

Let’s say you are logged in to the website www.badbank.com.  Using a phishing
attack, an attacker can trick you into entering www.attacker.com in another
browser tab. Using a code on www.attacker.com, the attacker tries to transfer
money from your account by posting a FORM to www.badbank.com. Your browser sends
the cookie belonging to www.badbank.com with this request. If the form on
www.badbank.com lacks CSRF tokens to prevent a CSRF attack, your session can be
exploited by the attacker.

If the cookie of www.badbank.com had been set to SameSite=Lax, the cookie in the
browser would not have been sent with the POST request and the attack would not
be successful.


CSRF POPULARITY IS GOING DOWN

CSRF attacks were at number 5 in the OWASP Top 10 list published in 2010, but
they declined to number 8 in the OWASP Top Ten in 2013. People suggested that
the reason for this was increased awareness of CSRF and the common use of
Anti-CSRF tokens by frameworks.

Source : https://www.owasp.org/index.php/Top_10_2013-Release_Notes


PREVENTING CSRF VULNERABILITIES

Although we’re now using the SameSite Cookie attribute, we should still be
cautious! We should make the whole changes with POST request instead of GET.

GET is designed for navigational purposes, not for state changes, so using GET
requests is generally considered a safe method.  However, when we are performing
actions (such as ordering a product, changing a password, or editing profile
information), using POST requests is much safer.

There are 3 important reasons for this:

 * When the parameters are carried by GET, they stay in the browser history.
   They also will be placed in server logs and the Referrer header in the
   request made toward third parties.
 * Another reason for not using GET requests is that cookies set to Lax are
   still sent along with GET requests, giving attackers another opportunity to
   exploit users.
 * Lastly, exploiting a CSRF vulnerability by using GET is much easier. To
   exploit a CSRF vulnerability in a form using GET, an attacker does not have
   to own a site. He can inject this payload into a forum message, post comment
   or image tag.

How Does Netsparker report this?

At Netsparker, we are constantly paying attention to the latest security
developments and adding new features and security checks into our engine. In
fact just a few weeks after the technical details of the Same-Site cookie
attribute were released, we implemented the check for it in both Netsparker
Desktop and Netsparker Enterprise, therefore the web vulnerability scanner will
alert you if cookies do not have such attribute.


RELATED ARTICLES


HOW TO PROTECT YOUR WEBSITES AND WEB APPS WITH ANTI-CSRF TOKENS


WHAT IS CROSS-SITE REQUEST FORGERY?


THE IMPORTANCE OF THE CONTENT-TYPE HEADER IN HTTP REQUESTS


XSS, CSRF & OTHER VULNERABILITIES IN CUBECART WEB APPLICATION

This article explains in details the various vulnerabilities Netsparker’s
security researchers identified in CubeCart, an open source ecommerce solution.


MOST POPULAR ARTICLES


SQL INJECTION CHEAT SHEET


HTTP SECURITY HEADERS: AN EASY WAY TO HARDEN YOUR WEB APPLICATIONS


HOW YOU CAN DISABLE DIRECTORY LISTING ON YOUR WEB SERVER – AND WHY YOU SHOULD


JSON INJECTION

Invicti Security Corp
1000 N Lamar Blvd Suite 300
Austin, TX 78703, US

© Invicti 2023

 * RESOURCES
   * Features
   * Integrations
   * Plans
   * Case Studies
   * Advisories
   * Invicti Learn
 * USE CASES
   * Penetration Testing Software
   * Website Security Scanner
   * Ethical Hacking Software
   * Web Vulnerability Scanner
   * Comparisons
   * Online Application Scanner
 * WEB SECURITY
   * The Problem with False Positives
   * Why Pay for Web Scanners
   * SQL Injection Cheat Sheet
   * Getting Started with Web Security
   * Vulnerability Index
   * Using Content Security Policy to Secure Web Applications
 * COMPANY
   * About Us
   * Contact Us
   * Support
   * Careers
   * Resources
   * Partners

© Invicti 2023
 * Legal
 * Privacy Policy
 * California Privacy Rights
 * Terms of Use
 * Accessibility
 * Sitemap

By using this website you agree with our use of cookies to improve its
performance and enhance your experience. More information in our Privacy Policy.

OK