I'm surprised that isn't blocked by cross-site scripting prevention or something along those lines. Shouldn't forcing logout require that you have the cookie that proves that you're logged in in the first place?

Any site that has a GET route to /logout that does not check the referrer is vulnerable to this iframe/img attack.

Please don't rely on the Referer being present (ever). It's an optional header to send in a request and you can configure your browser — at least Firefox — to not send it for privacy reasons.

Logout (or anything else that triggers changes of any kind) shouldn't be a GET request.

Not true. Using samesite cookie attribute prevents CSRF through IMG tags. (On browsers that support samesite, i.e. most browsers.)

It really shouldn't be GET anyways; that's asking for trouble.

Some of the pages that are exploited do use POST though. If it accepts authorization through a cookie and doesn't require an XSRF token or JSON content type, it is probably vulnerable.

But yes in general making actions happen in response to a GET request is generally a bad idea, since these are often cached and considered "safe" to retry.

This is tricky - it's up to the site basically. For single site websites (hacker news, let's say) then yeah - samesite should be enabled to prevent this.

For a large IDP like Google, Facebook, Microsoft, etc, you start to want* logout via cross-site requests, but it needs to be protected against DoS attacks like the link provided. So you need some other proof that the requesting site has a session - a session ID, an ID token, a unique identifier for one of the users in session (this is the least bulletproof one).

* well, standards wise at least. Google doesn't document a logout url anymore.

Which raises a question of how many services out there do have links that would delete your account without confirmation (or confirmation that could be somehow spoofed by client side JS).

How could you even implement an easy account deletion flow with un-spoofable confirmation if the whole client is considered untrusted?

Usually this is done by sending an nonce that must be sent back with the request to delete the account. The attacking site won't have the nonce, so it cannot delete the account.

Currently, you can also get a similar protection by requiring headers such as "Content-Type: application/json", since other sites will not be able to make that request.

Referer does work in some cases, but it is fairly common for users to disable the Referer, so relying on it for site functionality is not ideal.

How's the resource containing the nonce any more secure than just a plain "delete-account" endpoint?

Thinking about it, you could probably use CORS and some methods like X-Frame-Options to protect your nonce. But then you could just use that on the whole deletion page and avoid the nonce, I guess?

The nonce would only be available if you scrape the page while logged in and extract the logout URL, which is impossible with iframes.

Could you not still scrape the HTTP response for the page containing the nonce?

Not with a browser, no.

I think checking referrers is the normal way to solve this. As long as your site doesn't have XSS vulnerabilities on other pages, I think you're fine, but I'm not an expert though.

EDIT: Nonces are better, ignore this reply.

Why would they make it on initial load and not have a confirmation step + a list of supported sites first? Is it for trolling?

Yes.

Oh god, I can just imagine getting the phone call from my dad.