Comment by 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.
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.
*hardcode