I immediately thought this is a great way to ship malicious payloads to an unexpected party. A good WAF would block it as sus, but a few tricks could probably get around that as well

How is it different from any webpage in that regard?

The difference is that the contents of this website can be crafted by the attacker directly via the URL without having to do anything to the host.

How is that a meaningful attack vector, unique from webpages in general?

In this exact context it's likely not a problem, but essentially this is a ready to go XSS attack. As far as I can tell there is no CORS or domain level protections, so an "attacker" here could easily do anything else with any client-side data being used by any other "site" on the domain.

Let's say I make a little chat app that stores some history or some other data in local browser storage or cookies. Any other site can just as easily access all of that information. An "attacker" could link you to a modified version of the chat site that relays all of your messages to their server while still making it otherwise look like it's just the normal chat. It would also retain any client side information you had previously entered like your nick name or chat history, since it's stored in local storage.

Most of the time sanitizing input, like ensuring users don't have HTML in their names or comments, combined with domain-level separation and CORS policies ensures that one site can't do things that "leak" into another. It's the reason most of the time no matter how bad people mess things up Facebook getting hacked in your browser doesn't compromise your Google account.

Intrepid web developers reading this comment, please note that CORS is not, in fact, a protection mechanism. It's a way to relax the Same Origin Policy which is actually the protection relevant here. You don't need a CORS policy to protect a site from cross-site attacks, you need no CORS policy. Go ahead and make your little chat app, you're not at risk of having your messages stolen because of a lack of CORS headers.

Perhaps they meant CSP

I did say it wrong, but my point was that the site doesn't segment off each "site" into a different subdomain or any other ruleset that would allow the same origin policy to restrict access.

As it is with this site, the messages can get "stolen" by any other site on the same domain, which can be anything since anyone can upload one and direct a victim to them.

But then the attacker URL will be different.

That doesn't look like a new attack vector, this is called phishing, isn't it?

XSS means you can inject and persist code in a webpage maintaining the same URL accessed by other users.

If you create a bigbank-fake.com and copy a manipulated version of bigbank.com's HTML, this is not XSS.

Correct, except that in this case ALL the sites use "bigbank.com"

1. Find existing smol being shared around

2. Modify the parameters to hijack any relevant content

3. Reshare the smol site with your changes under the guise it’s the original link

That’s not novel. You could say the same thing for a GitHub Pages page, or a Code Sandbox, or an S3 static site, or really anything.

The only reason that would be a threat is if you implicitly trusted smolsite.zip, which would be an odd thing to do.

Github pages uses a unique domain per page to prevent sites from loading each others' cookies, localstorage, service workers, etc.

The difference is that if GitHub is found distributing malware on GitHub pages, you can notify them, they verify it, take it down, and open a process to eventually ban the offender.

They expend enough effort in this as to ensure the vast majority of content on GitHub pages is not malware, and avoid getting blankedly flagged as such.

It's not clear if smolsite.zip can successfully set up a similar process, given that they'll serve just any zip that's in the URL, and they won't have the manpower to verify takedown requests.

If your security model relies on arbitrary hosts on the internet proactively taking down malicious URLs, you're in for a bad time.

My security model is not going to do smolsite.zip any good when quad9, 1.1.1.2, et al. decide to outright block the domain.

Also, cookies.

That's a known attack vector called phishing, no? Any website can be phished, not just smolsites