I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.

That's "San Francisco Bay Area" for anyone else wondering

I do occasionally wonder how different things would be if JavaScript had come with a very robust standard library from early on.

You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs.

But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or something. Or maybe they vibe coded it and saw it worked and didn't bother to check. Perhaps it's a supply-chain attack on Discord et al to use Mintlify, if thats what you meant then I apologize.

I think you're right that I have an extreme aversion to SFBA-style software development, and partly because of how gen-ai is used there.

It's got nothing to do with DLLs or libraries or anything like that. This is a bug in their domain code. This is a simple, and bloody stupid, multi-tenant bug in a SaaS where they're not checking the tenant id before serving tenant content. Coupled with exploiting same domain cookies. Both of these have been problems that we have dealt with, and been vigilant against in SaaS apps. We had a lot of these type of attacks in the 00s when people first started deploying SaaSes and for a while we were all vigilant. The common vector for cookies back then was you'd have your main app "acmeforce.com" and you'd host customers under sub-domains like "arasaka.acmeforce.com" and cookie shenanigans would allow all sorts of attack vectors against the root site (I think github had one at one point, might be wrong!).

It's more that browser changes have allowed us to forget cookie problems, in a good way. And software developers seem to have a memory of a goldfish. The browsers have tried to build in all sort of protections against these attacks, but they only work against different domains, so we hit all the same problems as soon as some inexperienced developers starts making a multi-tenant app without proper testing.

You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).

The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.

It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.

But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.

Thanks for this comment tick_tock :)

After reading this, I did some research and learned a lot. I never really considered that, by including many things under the same domain, that you're increasing your blast radius w.r.t security vulernabilites. Thanks for that

This is what it really comes down to. Browsers are built around origins as the major security boundary. When you use a separate origin, safety comes for free.

Here's the other post:

https://news.ycombinator.com/item?id=46276313

Search indexing, etc.