> I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).

IIRC, this is the main reason GitHub moved Pages to github.io

▲

michaelt 2 days ago | parent [-]

The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.

This is why your gmail attachments should show up on googleusercontent.com instead of google.com

Many years ago, some naive websites would let users upload images, but wouldn't validate their content; and some browsers would ignore file content type headers if they had a better guess. So an attacker could rename a .html to a .jpg, upload it as your user profile image, then direct people to www.example.com/avatars/eviluser.jpg and they'd get a HTML page and run its javascript.

That's why, to this day, you sometimes see websites sending the header "X-Content-Type-Options: nosniff" which tells Internet Explorer 8 not to guess the content type.

▲

aaronmdjones 2 days ago | parent | next [-]

> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.

This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values.

Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com.

▲

michaelt a day ago | parent [-]

> This was solved a long time ago by marking such cookies as "HTTP only"

That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies.

Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options.

	▲	blincoln 10 hours ago \| parent [-]
		This is true, but additionally, the HttpOnly flag is now mostly a relic, because so much web app logic runs in JS in the browser and makes API calls. That code generally needs access to tbe cookies, or something equivalent, like a bearer token.

▲

EE84M3i 2 days ago | parent | prev [-]

SVGs are also images that can contain scripts if not validated.

It's also relevant that github.io is on the public suffic list, which impacts a bunch of downstream things and isolates the subdomains from each other.

▲

fc417fc802 2 days ago | parent [-]

> if not validated

I thought script tags were an official part of SVG? Meaning that a valid SVG can contain embedded JS.

	▲	bandie91 a day ago \| parent [-]
		he must have meant to 'sanitize' or 'filter'