Comment 19 for bug 44062

> 1) http://example.ltd.uk/ is identified for attack. It uses the "sid"
> cookie to hold the session ID.
> 2) Attacker obtains attacker.ltd.uk domain
> 3) User is enticed to click link to http://attacker.ltd.uk/
> 4) This site sets the "sid" cookie with domain=.ltd.uk
> 5) When user logs into example.ltd.uk, they are using a sesion ID known
> to the attacker.
> 6) Attacker now has a logged-in session ID and has compromised the
> user's account.

What I don't see is how the session ID saved by http://example.ltd.uk/ to the
"sid" cookie can be read by the attacker. Hasn't the user to visit the attackers
page again while the "sid" cookie contains the session ID and it's still valid?

Besides from this, if a user/page/server sets a cookie to ".ltd.uk" and thus
make it readable to any page/server visited in .ltd.uk, why should the browser
prevent this?
In case an attacker sets this cookie, how can it happen the session ID of
http://example.ltd.uk/ goes into the ".ltd.uk" cookie? Or if examples session ID
goes into the regular cookie saved with correct (means intended by
http://example.ltd.uk/) domain, how can it happen it's read by anyone else in
.ltd.uk?
I tried but didn't get it managed to create such a scenario.

So it's nice to be sure cookies only get set for real servers not for (second
level) TLD's even if the server/page wants to do so. But a real security problem
is only if a cookie gets saved with a domain other than intended.