Julia EvansFeb 4

something I don't think I've ever seen explained is whether there's any situation where it's safe to set "Access-Control-Allow-Origin: *" other than "if your site literally never serves any private data"

(I often hear "don't do it" which is fair I guess, but also like the Mastodon API intentionally sets Access-Control-Allow-Origin: * and that's extremely useful)

Show threadJulia EvansFeb 4

also is there any name for the attack(s) that setting "Access-Control-Allow-Origin: *" might expose you to? i feel like it's so much easier to talk about security stuff in terms of the specific threats we're trying to avoid, but I can't think of the name for it

(edit: I think it's CSRF)

Show threadJulia EvansFeb 5
huh I'm not sure if this is true but this post argues that it's generally fine to set Access-Control-Allow-Origin: * (as long as you don't set Access-Control-Allow-Credentials, and as long as the API is public and not on an intranet) https://advancedweb.hu/is-access-control-allow-origin-star-insecure/
Is Access-Control-Allow-Origin: * insecure?

Disabling a security feature is usually a bad thing. In this case, it's fine

Show threadRick OsborneFeb 5

@b0rk What that page misses is consideration of the question: is there any chance the content on my site could be used maliciously?

That is, if my site allows user-uploaded content, how sure am I that there's zero chance my site might end up hosting something malicious?

Which, of course, has nothing to do with credentials.

Or, I guess, put another way: yes, credential and identity exfiltration is one vulnerability addressed by CORS (and CSP), but it's not the only one.

One specific example here is a scenario where a site allows users to upload their own avatar image, say in PNG format. But instead of sending a PNG, the user uploads a JS file but sends its content-type: image/png. The site thinks "it's just an image" and doesn't bother to check that the content is actually valid.

If that site then has ACAO: *, it has just become a hosting service for malicious code.

Write-up for an SVG alternative to this attack: https://www.cloudflare.com/cloudforce-one/research/svgs-the-hackers-canvas/

SVGs: the hacker’s canvas

Cloudforce One research reveals a surge in phishing attacks using SVG files, exploiting their scriptable nature to bypass detection. Discover how this overlooked vector poses a growing threat to email security.

Show threadrobrykFeb 5
@ricko @b0rk

I assume that you mean that some other site might now include that malicious piece of js via <script src=foo> tag. If so, (a) doesn't that work in absence of A-C-A-O too? (b) in what scenarios an attacker can cause another site to embed that <script> tag, but neither an inline script tag, nor a <script src=bar> tag that points at any of the pastebin sites that exist on the web?
Show threadRick OsborneFeb 5

@robryk @b0rk

doesn't that work in absence of A-C-A-O?

As a script or img, yes. (Presuming poor CSP setup.) But we've also seen plenty of naive user agents which don't pay attention to the content-type and will instead content sniff. MSIE was a classic example. We're seeing similar vulnerabilities in AI agents.

in what scenarios an attacker can cause another site to embed that script tag, but neither an inline script tag, nor a script src=bar tag that points at any of the pastebin sites

I could see a scenario like this:

  • Someone creates a friends-of-mastodon.example
  • They set up the CSP to allow content from bad-cors.example because they want to use avatars or embedded toots.
  • They also allow users to submit content, such as their username.
  • They don't adequately sanitize one of the inputs, allowing script or img tags to slip through, like that username.
  • Now, simply viewing that username causes malicious JS to run, because it all looks "allowed".
    • Show threadrobrykFeb 5
    @ricko @b0rk Your reply got truncated, presumably on the `<` character.
    Show threadRick OsborneFeb 5

    @robryk @b0rk Updated. I brought it back.

    Amusingly, all the text I typed was still there. I'm now feeling very raised-eyebrow about the content sanitization in mastodon.

    Show threadrobrykFeb 5
    @ricko @b0rk I would wager that this is the typical behaviour of markdown renderers, where selected html tags are passed through and others are skipped in some way.

    IMO a worse issue around rendering in fediverse is that a post can contain its contents in multiple formats (e.g. plain text, markdown, html...) and it's not entirely obvious which one will be rendered (so it can look differently depending on what does the rendering).

    Edit: Ah, and re making toots that appear differently to different people: also the fallback for quote toots is a good way to cause toots to appear differently on instances without quote toot support, not even mentioning the possibility of an instance sending different contents of the same toot to different inboxes.
    Show threadRick OsborneFeb 5
    @robryk @b0rk Hahaha. Fair. All the pain of multi-part MIME. It's like we didn't learn the lesson the first time with HTML email.
    Show threadrobryk
    @ricko @b0rk And with mailing lists being able to sow confusion. (I am still surprised that I haven't seen sending-different-toots-to-different-instances used maliciously on fedi, only as part of "<your instance> is the best instance" jokes.)
    Feb 5 at 9:31pmWeb