Page History

...

There is no systemic mitigation for these risks other than encouraging the use of virtual domains.  They should be treated as application security issues.  Note that cookie injection is not a problem unique to applications running within the same domain; any attacker controlling content on a foo.mit.edu host can inject cookies into all .mit.edu hosts if the victim applications do not check cookie domains.

3d.

...

Browser security

Browsers treat the protocol, host, and port of a URL as a protection domain, allowing a variety of attacks between multiple content owners within the same domain.  As one example: 

Basic auth is a rudimentary password protection system built into HTTP.  Most web applications do their own password management, but static content is sometimes protected with Basic auth.  Once a user enters a password for a given resource, the browser caches the password, so that the user does not have to reenter it each time the resource is accessed.  A Basic auth resource is identified by the domain part of the URL and a server-provided realm.  In a shared hosting environment, the normal Apache httpd mechanisms for doing Basic auth allow each content owner to pick the realm used for each resource.  An attacker can steal passwords from users of another content owner's resource by choosing the same realm name as the other content owner.

 Mitigation options include:

• Deny users the ability to use Basic auth; make them use Digest auth instead.  Digest auth does not provide the server with the user's password.
• Allow users to use Basic auth, but force the realm to include the username as a prefix.
• Allow Basic auth, but only in the context of a virtual domain.

More research is required to determine which of these options is most feasible.  Note that disabling or restricting the normal Apache auth mechanisms may not be sufficient; it may be possible to circumvent them with CGI scriptsMore generally, Javascript code can be used to attack content owned by someone else using the same domain.  To mitigate these attacks, we should use a separate domain for each content owner.  This can be easily achieved with a wildcard DNS record, so that user sites look like http://mv.ezproxy.com.ezproxy.canberra.edu.au/^{Image Added} instead of http://mv.ezproxy.com.ezproxy.canberra.edu.au/~username^{Image Added}.

3e. PHP session hijacking

...