I went about researching web security recently as I was writing — I wanted to make sure my recommendations were secure and I'm not doing any of my students a disservice with my recommendations. Understanding Asynchronous JavaScript Unfortunately, articles in the security space were pretty hard to understand. There were many words that triggered lots of fear, uncertainty, and doubt in the articles. I get emotionally panicky when I read these articles — and I worry I may end up doing something wrong — even though the intention of these articles was good! Many articles also don't disclose full details about CSRF, how to set up a CSRF Attack, and how to prevent a CSRF Attack, which leaves me doubtful about what I learned. I end up having to figure things out on my own. I want to make it easier for you to understand CSRF, so I took a stab at writing an article with complete (and step-by-step) information about CSRF attacks. I hope this article gives you the clarity and confidence you need to build secure web applications. Two Kinds of CSRF Attacks There are two kinds of CSRF Attacks: Normal CSRF Attack Login CSRF We'll discuss the Normal CSRF Attack first, followed by the Login CSRF. What is a CSRF Attack — a request they did not intend to make — (logged in). A CSRF attack is one that tricks a victim into submitting a malicious request to a website where they are authenticated The request must originate from another website, which gives in the name "Cross-Site". This request also impersonates an authenticated user, which gives it the name "Request Forgery". — which means the attacker doesn't see what happens after the victim submits the request. CSRF attacks often target a state change on the server. CSRF Attacks are blind What is a state change? Basically, anything that modifies the database is a state change. Examples of state changes include: Change username and password Sending money to an account Sending fake messages from the user's account Sharing inappropriate images or videos from the user's account CSRF Attacks take advantage of the fact that browsers automatically send cookies to the server in each request. Without any CSRF protection, the server may assume that a request is valid when an authentication cookie is present. Authentication cookies may be anything as long as the server uses them to check whether a user is valid. It can be an access token. It can also be a session ID. It depends on how the server handles authentication. Prerequisites for CSRF Attacks to work There are four prerequisites needed for a CSRF attack to succeed. A request for any method is sent to the server. The user must be authenticated. The server must store authentication information in cookies. The server does not implement CSRF prevention techniques (which will be discussed below). How CSRF attacks work Before an attacker can launch a CSRF attack, they need to find a consistent request they can target. They would know what the request does. This can be any request — GET, POST, PUT, or DELETE. Once they select the request to target, they must generate a fake request to trick the user. Finally, they must trick the user into sending the request. Most of the time, this means: Find a way to send the request automatically without the user knowing. The most common approaches are through image tags and submitting a JavaScript form automatically. Misrepresenting a link (or button), which tricks a user into clicking it. (AKA ). Social Engineering Attacks via a GET request CSRF Attacks with a GET request only work if the server allows a user to change state with GET requests. You don't have to worry about this type of CSRF Attack if your GET requests are read-only. But let's say we have a server that doesn't follow programming best practices and allows state changes via a GET request. If they do this, they will be in trouble — huge trouble. For example, say there is a bank that allows you to transfer money with the following endpoint. You just have to enter and in the GET request to send money to a person as follows: account amount https://bank.com/transfer?account=Mary&amount=100 The attacker can generate a link that sends the money to their account. # Sends 9999 to the Attacker's account
https://bank.com/transfer?account=Attacker&amount=9999 At this point, the attacker can find a way to trigger the link automatically without the user knowing. One way is to include the link in a 0x0 image in a webpage or an email. If the user visits this webpage or email, the GET request gets triggered automatically since browsers and emails are configured to fetch images automatically. (Now I understand why email providers disable images from loading as a safety precaution). 
<img
  src="https://bank.com/transfer?account=Attacker&amount=9999"
  width="0"
  height="0"
  border="0"
/> Another way is to misrepresent what a link does. This works because people don't check links before clicking on them. If the person clicks the link, they would have sent the GET request for the attacker without knowing. 
<a href="https://bank.com/transfer?account=Attacker&amount=9999"
  >View my Pictures</a
> If the user is authenticated, the server will receive an authentication cookie which makes it believe the request is valid. If the server did not use any CSRF protection mechanisms, the money will be sent to the attacker. Examples of GET CSRF Attacks: uTorrent suffered a CSRF Attack back in and it allowed state changes with GET requests. 2008 YouTube used to have a security vulnerability in that allowed the attacker to perform almost all actions possible for a user, including sending messages, adding to a friends list, etc. 2008 If you click on the links above. You'll be able to find examples of real GET requests that create such a CSRF attack. (Don't worry, no weird links over here 😜). CSRF Attacks with POST requests CSRF Attacks with POST requests follow the same pattern — but they cannot be sent through links or image tags. They need to be sent through a form or through JavaScript. Let's assume we have the same vulnerable endpoint and the attacker simply needs to enter the and information to trigger the request. account amount POST https://bank.com/transfer?account=Attacker&amount=9999 The attacker can create a form and hide the and values from the user. People who click on this misrepresented form will send a POST request without them knowing. account amount 
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="acct" value="Attacker" />
  <input type="hidden" name="amount" value="9999" />
  <button>View my pictures</button>
</form> This form can also be executed with JavaScript automatically without people knowing — real users don't even need to click the button but they are already in trouble. <form>...</form>
<script>
  const form = document.querySelector('form')
  form.submit()
</script> POST CSRF Attacks are scary, but there are ways to prevent them. We'll discuss the techniques in the prevention section below. CSRF Attacks with PUT and DELETE requests CSRF Attacks be executed with or requests because the technology we use doesn't allow them to. cannot PUT DELETE Yup. You read that right. CSRF Attacks cannot be executed via HTML forms because forms don't support and requests. It only supports and . If you use any other method (except for and ), browsers will automatically convert them into a GET request. PUT DELETE GET POST GET POST 
<form action="https://bank.com/transfer" method="PUT"></form> You can never execute a CSRF Attack via HTML. Now here's a fun aside: How do people send and request through a form if HTML doesn't allow it? After some research, I discovered most frameworks let you send a request with a parameter. PUT DELETE POST _method 
<form method="post" ...>
  <input type="hidden" name="_method" value="put" />
</form> You can execute a CSRF Attack via JavaScript, but the default prevention mechanism in browsers and servers today makes it really hard for these attacks to happen — you have to deliberately let down the defenses for it to happen. Here's why. PUT To execute a CSRF Attack, you need to send a Fetch request with the method. You also need to include the option. PUT put credentials const form = document.querySelector('form')

// Sends the request automatically
form.submit()

// Intercepts the form submission and use Fetch to send an AJAX request instead.
form.addEventListener('submit', event => {
  event.preventDefault()
  fetch(/*...*/, {
    method: 'put'
  credentiials: 'include' // Includes cookies in the request
 })
    .then(/*...*/)
    .catch(/*...*/)
}) This wouldn't work because of three reasons. automatically because of CORS. Unless — of course — the server creates a vulnerability by allowing requests from anyone with the following header: First, this request will NOT be executed by browsers Access-Control-Allow-Origin: * Second, even if you allow all origins to access your server, you still need a option for browsers to send cookies to the server. Access-Control-Allow-Credentials Access-Control-Allow-Credentials: true Third, even if you allow cookies to be sent to the server, browsers will only send cookies that have the attribute set to . (These are also called third-party cookies). sameSite none If you have no idea what I'm talking about regarding the third point, you're safe — you really have to be a malicious developer who wants to screw your server up if you send authentication cookies as third-party cookies. This section is huge to take in. I've created a few more articles to help you understand exactly what's going on — and why it's so frigging impossibly hard to expose yourself to a CSRF Attack: PUT Understanding sameSite cookies Understanding Fetch credentials In short — you only have to worry about CSRF Attacks unless you really screwed up your server. POST CSRF Prevention methods The most common CSRF prevention methods today are: Double Submit Cookie pattern Cookies header method Both methods follow the same formula. When the user visits your website, your server must create a CSRF token and place them in the browser's cookies. Common names for this token are: CSRF-TOKEN X-SRF-TOKEN X-XSRF-TOKEN X-CSRF-TOKEN Use whatever token name you prefer. They all work. What's important is that the CSRF Token must be a randomly generated, cryptographically strong string. If you use Node, you can generate the string with . crypto import crypto from 'crypto'

function csrfToken (req, res, next) {
  return crypto.randomBytes(32).toString('base64')
} If you use Express, you can place this CSRF token in your cookies like this. While doing so, I recommend using the strict option as well. (We'll talk about in a bit). sameSite sameSite import cookieParser from 'cookie-parser'

// Use this to read cookies
app.use(cookieParser())

// Setting CSRF Token for all endpoints
app.use(*, (req, res) => {
  const { CSRF_TOKEN } = req.cookies

 // Sets the token if the user visits this page for the first time in this session
 if (!CSRF_TOKEN) {
  res.cookie('CSRF_TOKEN', csrfToken(), { sameSite: 'strict' })
 }
}) How you use the CSRF Token changes depending on whether you support the Double cookie submission pattern or the Cookie to header method (or both). Double Submit Cookie pattern This pattern's name is a bit misleading — because it seems to mean sending a cookie twice with "Double Submit Cookie". What this means is: You can send the CSRF token in a cookie You render the with a CSRF Token — which would be included in the form's submission. <form> (Hence double submission). If you use Express, you can pass the CSRF Token into HTML like this: app.get('/some-url', (req, res) => {
  const { CSRF_TOKEN } = req.cookies

  // Render with Nunjucks.
  // Replace Nunjucks with any other Template Engine you use
  res.render('page.nunjucks', {
    CSRF_TOKEN: CSRF_TOKEN
  })
}) You can then use form like this: CSRF_TOKEN <form>
  <input type="hidden" name="csrf" value="{{CSRF_TOKEN}}" />
  
</form> The server can then check the validity of the session by comparing two CSRF Tokens. If they match, it means the request is not forged — because there is no way for an attacker to guess the CSRF token value on another website. // Checks the validity of the CSRF Token
app.post('/login', (req, res) => {
  const { CSRF_TOKEN } = req.cookies
  const { csrf } = req.body

  // Abort the request
  // You can also throw an error if you wish to
  if (CSRF_TOKEN !== csrf) return

  // ...
}) Cookie to Header method The cookie to header method is similar — except this is executed with JavaScript. In this case, the CSRF Token must be included in both the cookie and the request header. In this case, we need to: Set to or to include cookies credentials include same-origin Grab the CSRF token from and add it as a request header. document.cookies Here's an example request: // Gets the value of a named cookie
function getCookie () {
  const match = document.cookie.match(new RegExp('(^| )' + name + '=([^;]+)'))
  if (match) return match[2]
}

// Sends the request
fetch('/login', (req, res) => {
  credentials: 'include',
  headers: {
    'CSRF_TOKEN': getCookie('CSRF_TOKEN')
 }
}) The server can check the validity of the CSRF Token like this: // Checks the validity of the CSRF Token
app.post('/login', (req, res) => {
  const { CSRF_TOKEN } = req.cookies
  const { CSRF_TOKEN: csrf } = req.headers

  // Abort the request
  // You can also throw an error if you wish to
  if (CSRF_TOKEN !== csrf) return

  // ...
}) Make all this easier with a library I showed you how to manually create and test CSRF Tokens because I wanted to give you an understanding of the process. This process has already been solved many times so we shouldn't do it manually (unless you're learning, like what I did here). If you use Express, I recommend using the library since it's more robust and flexible compared to what I could show in this example above. csurf SameSite Cookie attribute Setting to the above example ensures that the CSRF Token cookie is only sent to the server if the request originates from the same website. This ensures that the CSRF Token will never be leaked to external pages. sameSite strict You can — optionally but recommended — set the attribute to as you set the authentication cookie. This ensures that no CSRF Attacks can be conducted since the authentication cookies will no longer be included in cross-site requests. sameSite strict Do you need CSRF Token protection if you used set to for your authentication cookie? sameSite strict I would say no, in most cases — because already protects the server from cross-site requests. We still need the CSRF token to protect against one particular type of CSRF: Login CSRF. sameSite You can read more about sameSite cookies in . this article Login CSRF Login CSRF is completely different from Normal CSRF Attacks in terms of intent. . Once the attack succeeds, the user will continue to use the attacker's account if they're not paying attention. In the Login CSRF, the attacker tricks the user into logging in with the attacker's credentials <form action="http://target/login" method="post">
  <input name="user" value="Attacker" />
  <input name="pass" type="password" value="AttackerPassword" />
  <button>Submit</button>
</form> They can also trigger the form automatically with JavaScript. const form = document.querySelector('form')

// Sends the request automatically
form.submit() If the user doesn't realize they have been logged into the attacker's account, they may add personal data — like credit card information or search history — to the account. Attackers can then log back into their accounts to view this data. Google has been vulnerable to Login CSRF Attacks . in the past We can prevent Login CSRF with the Double Submit Cookie pattern mentioned above — attackers will not be able to guess the CSRF Token, which means they cannot launch a CSRF Login Attack. Wrapping up CSRF stands for across Site Request Forgery. There are two kinds of CSRF Attacks: Normal CSRF Login CSRF In Normal CSRF, the attacker aims to create a state change through a request. In Login CSRF, the attacker aims to trick the user into logging into the attacker's account — and hopefully benefit from the user's actions if they are unaware. You can prevent both kinds of CSRF Attacks with the Double Submit Cookie pattern and the Cookie to header method. Setting to prevents normal CSRF but not Login CSRF. sameSite strict That's it! Thanks for reading. Sign up for if you want more articles to help you become a better front-end developer. my newsletter Also published . here

Fetch

Google

Target

YouTube

Blind Attacks: Understanding CSRF (Cross Site Request Forgery)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Quick CSS Guide: Crafting Neon Buttons with Glow Effects & Animations

Cybersecurity Essentials: Practical Web App Security Testing Tips for QA Engineers

An introduction to CSRF Attacks: Who Is Riding With You?

Consume REST Services with AJAX and CSRF protection in Django

Cross-Site Request Forgery (CSRF) Attacks: An Emerging Threat to Browser Security

Why Webhook Security Matters

A Quick CSS Guide: Crafting Neon Buttons with Glow Effects & Animations

Cybersecurity Essentials: Practical Web App Security Testing Tips for QA Engineers

An introduction to CSRF Attacks: Who Is Riding With You?

Consume REST Services with AJAX and CSRF protection in Django

Cross-Site Request Forgery (CSRF) Attacks: An Emerging Threat to Browser Security

Why Webhook Security Matters

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps