← Back to context

Comment by stingraycharles

5 years ago

“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.

8 comments

stingraycharles

Reply
erikpukinskis  5 years 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"> 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=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  5 years 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.

jefftk  5 years 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)