Use unguessable UUID pipeline ids to prevent spoofing

[Manishearth]

See also: http://logs.glob.uno/?c=mozilla%23servo#c404439

A compromised iframe process can pretend to be any iframe/pipeline when talking to the constellation, since the constellation channels are shared. This could be used to escalate access out of the sandboxed iframe.

This can either be fixed by separating out the constellation channels (would require selecting over a ton of channels and probably is inefficient), or by making the pipeline id unguessable (currently a u64 counter). A 128-bit uuid should be enough.

[Manishearth]

This should also prevent spoofing when talking to the resource thread, so that cookies can't be stolen. (The resource thread in turn should not rely on messages sent to it to know the origin, it should instead rely on a mapping of secure pipeline ids and origins that is stored somewhere in the chrome process.)

Edit: This can't happen, the resource task won't attach origins to the wrong request.

[Manishearth]

<ajeffrey> ManishCloud: we may wish to separate the notion of pipeline_id from pipeline_authenticating_super_secret

[Manishearth]

Edit: This can't happen, the resource task won't attach origins to the wrong request.

Actually, yes it can happen, because anyone can send a GetCookiesForUrl message and get whatever cookie they want. Forgot about that message.

[asajeffrey]

Ah, oops. So if an attacker can work out how to send a GetCookiesForUrl message, then they can get access to arbitrary cookies. Not good.

[Manishearth]

Also, currently script handles CORS, so a compromised script thread can bypass CORS and read/make arbitrary http requests on behalf of the user with cookies. Given that they can anyway get the cookies through GetCookiesForUrl, this is just an additional attack vector for the same vulnerability.

When we switch to fetch CORS should be handled by the resource task, so that vector should get fixed.