Hacker News new | past | comments | ask | show | jobs | submit login

I think it is because they use `googleusercontent.com` for content uploaded by users - that makes sense for security reasons, never ever let users upload content to your main domain.



Can you elaborate on this? What's special about the domain here for security?


It's a defense in depth mechanism: when you allow user-generated content uploaded on your main domain, somebody will find a way to break your security system and make that content executable on the user's browser.

When doing so, an attacker can steal cookies, and/or invoke APIs for the user.

Now, there are of course ways to avoid that, but in the end, if every other system fails, being on a domain without any API and without any sensitive content allows reducing the blast of the impact.

Real-world example: https://gitlab.com/gitlab-org/gitlab/-/issues/200094

GitLab has APIs under their main domain. Due to a misconfiguration, it was possible to render in the browser user-generated `.svg` files. Thus, a malicious crafted SVG file could bring to a XSS, and accessing a lot of personal user data on the main domain.

There are technical reasons for the shared domain, but if that particular API call was on another domain, the impact of the vulnerability would have been way smaller.


Similarly, long time ago you could have a personal/project website on <username>.github.com. A few years ago they moved all personal/project websites to <username>.github.io instead.


Is this also another case for hosting your main site on www.example.com instead of example.com? This way you could have cookies only on www.example.com while hosting user generated content on assets.example.com or whatever sub-domain you want that's not www?


Yes and no: one thing I totally forgot to mention is phishing. You don't want to give any semblance of endorsement to user-generated contents: many viewers will check only the main domain, due to how browsers' URL bars hide stuff.

Having a total different domain help highlighting that it is not official content.


Makes sense.

There's probably some benefits around blacklists too.

For example if a user uploaded questionable content to assets.example.com/uploads, such as pirated content then someone could submit that to search engines and other lists to get your domain blacklisted. It's quite possible these blacklists could be related to the apex domain, not necessarily the sub-domain. A separate domain guarantees your apex domain won't get penalized.


How does the configuration look like (very broadly)? Is already a domain redirect helpful here?


Yes, as long as the content is downloaded from another domain, everything is good.

The point is: if for any reason (0-day, misconfiguration, bug, whatever) the content uploaded from the user is executed by the browser, instead of being "just" rendered or downloaded, it must execute in a different domain. Given domains are sandboxed by the browser, a vulnerability on domain A cannot affect domain B.

Of course, there are still way to shoot you in the foot (e.g., having the same access token in the cookies for both domains), but it's one measure more. This is why security should be layered, and you shouldn't rely on just one defense: https://en.wikipedia.org/wiki/Defense_in_depth_(computing)


Also, malware detection algorithms decrease their rating for the google.com domain when they encounter malicious content on this domain. Probably not an issue for google specifically, as they themselves control this list for Chrome, but for other companies this might be relevant too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: