Even though modern Web technologies use the complete domain name as a the one security boundaries, HTTP cookies is an old technology that isn't rooting in RFC but in history and evolved from a world with poor isolation.
Cookies can be segregated by exact domain name match, or by super-domain: on that very Web page, my browser informs me that it has a bunch of cookies for the domain stackexchange.com which is a super domain of that of the page (https://security.stackexchange.com/questions/227598/ideas-for-subdomains-isolation).
The sharing of these cookies is the problematic issue with hosting user provided, arbitrary and totally non-secure HTTP content
- content provided with an HTTP content-type header that either means HTML content (or generic XML/SGML that is seen as HTML),
- or content with a content-type that is plain text but which may be "sniffed" as HTML by the browser (as historically HTML HTTP browsers are known to have such "quirks")
in your super-domain.
It isn't the only issue: not only existing cookies could be read (which could be prevented by the HttpOnly flag), but even if you have none of these cookies, the active HTML content could set new cookies that are shared on the super-domain. These cookies will be associated with the super-domain.
The extreme weakness of the HTTP protocol means that only the HTTP server tells a browser the scope of the cookie when it is set, the browser never repeats back that information. It means that the HTTP server has no way to determine the origin of a cookie: which complete domain name set a cookie, and what is its scope. The browser has that information, the end user can access it (f.ex. with the page inspector, you can see a list of all cookies set or sent during that page load), but the server won't have it.
[Note:
Google set up the googleusercontent.com for a reason: any complete (whole Web pages, not HTML fragments) user content is provided from a completely different domain (webcache.googleusercontent.com) from the one domain trusted by the browser (google.com): there is zero chance the Web client can confuse these domains. Only the end user can navigate to (non existing) https://webcache.googleusercontent.com/zfzefzef
and see that the domain certificate is attributed to
CN = *.googleusercontent.com
O = Google LLC
L = Mountain View
S = California
C = US
(Another hint is the list of altNames in the certificate, many of which are very recognizable as Google's.)
That's the kind of effort it takes for an end user to identify that a domain is owned by the same entity as another.
end note]
Because the client doesn't inform the browser which entity was the source of any particular cookie, the server can be confused by a cookie with the same name set by a subdomain; if more than one domain has a cookie with the same name, the behavior of browsers is unpredictable, with either multiple Cookie header, in some browser dependent order, or the concatenation of all cookies in one header. Making some part of cookie names unpredictable by any adversary (like cookie_name_RANDOM_SEQUENCE) at least avoids the concatenation of multiple cookies issue, but it doesn't authentify the origin of a cookie.
Conclusion: to be safe, do not allow any potentially active HTML content (one with working Javascript) anywhere inside (in a subdomain of) your trusted domain.
