How can XSRF Attacks be used outside of img tags?

Question

So I'm currently working on a web application and I've chosen to use JWT's as the access token to my api.

I have tried reading all I can about XSRF attacks and when I try to dive deeper into how they are performed, the only answer I seem to get is that an attackers creates a site and tricks the user into loading it. The attacker's site contains an img tag which sends a GET request to my URI which works due to the javascript automatically adding the user's cookie with the call to my URI.

1st question: Does anybody really allow data server side to be altered from a GET? Or is this just how an attacker retrieves user data?

2nd question: How can a XSRF attack be performed using a POST/PUT? I can not seem to find a clear example of this anywhere. Can the trick website just run an AJAX call to my URI and the user's cookie would be sent with it? If so why bother with the whole img tag thing? Common users will not check the source code.

Answer 1

GET requests across domains are easiest to make (using images or iframes) as you mentioned. POST requests are surprisingly easy, too and CORS isn't always protecting you either.

Let's say the user is logged in to email.com via cookie and email.com allows to send an email via a simple HTTP form in their interface, say like this:

<form action="https://email.com/sendMsg" method="post">
  <label>To: <input name="to" /></label>
  <label>Your message: <textarea name="msg"></textarea></label>
  <button type="submit">Send</button>
</form>

But forms can be sent across domains - that's always been like that and is often desired, too. The form will be sent with cookies, too.

But wait, how can we exploit that in XSRF? Well, an attacker, evil.com, could have a hidden form like this:

<form id="xsrf" action="https://email.com/sendMsg" method="post">
  <label>To: <input name="to" value="[email protected]" /></label>
  <label>Your message: <textarea name="msg">Did you see this? :-D http://evil.com/you-should-not-go-there</textarea></label>
</form>
<script>document.getElementById('xsrf').submit()<script>

Guess what? The form has just been submitted and for email.com it looks legit, because the session cookie will be sent as well.

The downside here is that a form submission navigates away from the current page, but if the attacker puts the form inside an invisible iframe this won't be a problem.

A pure javascript XSRF post

Say we have the same "API" for email.com as before - a POST request with to and msg to send an email to somebody.

You might think the following code on evil.com won't cause a problem due to CORS:

fetch('https://email.com/sendMsg', {method: 'POST', body: '[email protected]&msg=Hello+World', credentials: 'include' })

This is in fact an XSRF vector, too. CORS throws an error and does not make the network response available if CORS headers are missing, but the request is made nonetheless.

Normally this is pretty useless, but in our case there is no XSRF protection and thus our POST request is made and the email is sent!