5 ms·

“Don't host any customer generated data in your main domains. ” This is extremely important for multiple reasons. One reason is the blacklisting as mentioned i

“Don't host any customer generated data in your main domains. ” This is extremely important for multiple reasons. One reason is the blacklisting as mentioned in the article, the other reason is security: browser typically implement security policies around domains as well, such as cookie scoping and whatnot. Putting all user generated content under a completely separate domain avoids a whole category of potential issues.

jefftk 6y ago
For example, if someone manages to upload HTML and trick your system into serving it with a content type that browsers will interpret as HTML, then they can modify or exfiltrate your user's cookies. This could allow impersonation attacks, XSS, etc. (Disclosure: I work for Google, speaking only for myself)
CodeWriter23 6y ago
Avoids the issue until your ugcweb.com is blacklisted and users who uploaded clean ugc are blocked from the portal.
- Marazan 6y ago
  You upload action is hosted on a different domain from the domain that serves the content.
  - londons_explore 6y ago
    Yes, but when Google blocks either domain, your webapp will still be broken...
    - mattmanser 6y ago
      And in 10 minutes you grab a new domain and it's back up. You change the config setting in your app to use the new domain and, boom, done. That's the point, it's a sacrificial domain. If you lose it you don't care, it's not your brand.
erikpukinskis 6y ago
How do you do this in practice though? Let's say my marketing site is at turtlepics.com and then the pics, captions, feeds, etc are served off of turtlepicscontent.com. So I can serve my app off of turtlepics.com, that's fine. But it can't load any content directly. I'd have to have a separate <script src="https://turtlepicscontent.com/feeds/erik https://turtlepicscontent.com/feeds/erik"> or whatever that loads a user's feed. But that needs to be authenticated too, so I have to then authenticate the user on that domain (https://turtlepicscontent.com/feeds/erik?onetimekey=a9e79c5829 https://turtlepicscontent.com/feeds/erik?onetimekey=a9e79c58...) as well, at which point the credentials are present in the unsafe domain's cookies as well, and the jig is up. Or do you continually generate fresh one time keys in the safe app, so that you don't need cookies on the content domain? Even then, someone can still bring down the entire turtlepicscontent.com domain with malicious content. Which... well, at least your marketing site and your login still works. But the site is still fully down at that point. I guess that's better than nothing, but still pretty annoying. Or is the idea just to wall off uploads specifically, but continue serving text off the main domain, presuming you're sanitizing text correctly? I guess you could have some fallback to a safe-ish domain with an older read-only backup of the content database? Still not ideal. I guess sharding your users onto multiple domains based on account age might help a bit too.
- Ayesh 6y ago
  You don't necessarily need to authenticate users on that domain with a cookie. An HMAC token would be ideal, because you don't have to maintain state. Don't hardcore the content domain. In case the content domain gets flagged, it should be easy to change to a new domain. The assets themselves (such as images, scripts, etc) can have any browser cache expiration time. HTML documents cache duration will matter, and once that has elapsed, browsers should start to use the new content domain.
  - canadaduane 6y ago
    *hardcode

jefftk 6y ago

For example, if someone manages to upload HTML and trick your system into serving it with a content type that browsers will interpret as HTML, then they can modify or exfiltrate your user's cookies. This could allow impersonation attacks, XSS, etc. (Disclosure: I work for Google, speaking only for myself)

CodeWriter23 6y ago

Avoids the issue until your ugcweb.com is blacklisted and users who uploaded clean ugc are blocked from the portal.

Marazan 6y ago
You upload action is hosted on a different domain from the domain that serves the content.
- londons_explore 6y ago
  Yes, but when Google blocks either domain, your webapp will still be broken...
  - mattmanser 6y ago
    And in 10 minutes you grab a new domain and it's back up. You change the config setting in your app to use the new domain and, boom, done. That's the point, it's a sacrificial domain. If you lose it you don't care, it's not your brand.

erikpukinskis 6y ago

How do you do this in practice though? Let's say my marketing site is at turtlepics.com and then the pics, captions, feeds, etc are served off of turtlepicscontent.com. So I can serve my app off of turtlepics.com, that's fine. But it can't load any content directly. I'd have to have a separate <script src="https://turtlepicscontent.com/feeds/erik https://turtlepicscontent.com/feeds/erik"> or whatever that loads a user's feed. But that needs to be authenticated too, so I have to then authenticate the user on that domain (https://turtlepicscontent.com/feeds/erik?onetimekey=a9e79c5829 https://turtlepicscontent.com/feeds/erik?onetimekey=a9e79c58...) as well, at which point the credentials are present in the unsafe domain's cookies as well, and the jig is up. Or do you continually generate fresh one time keys in the safe app, so that you don't need cookies on the content domain? Even then, someone can still bring down the entire turtlepicscontent.com domain with malicious content. Which... well, at least your marketing site and your login still works. But the site is still fully down at that point. I guess that's better than nothing, but still pretty annoying. Or is the idea just to wall off uploads specifically, but continue serving text off the main domain, presuming you're sanitizing text correctly? I guess you could have some fallback to a safe-ish domain with an older read-only backup of the content database? Still not ideal. I guess sharding your users onto multiple domains based on account age might help a bit too.

Ayesh 6y ago
You don't necessarily need to authenticate users on that domain with a cookie. An HMAC token would be ideal, because you don't have to maintain state. Don't hardcore the content domain. In case the content domain gets flagged, it should be easy to change to a new domain. The assets themselves (such as images, scripts, etc) can have any browser cache expiration time. HTML documents cache duration will matter, and once that has elapsed, browsers should start to use the new content domain.
- canadaduane 6y ago
  *hardcode