I won't really go into details of how cookie tossing and cookie overflow attacks work, because this answer explains it perfectly. This post on github explains some mitigation strategies, but does not talk about the case where a.domain.com can do malicious things to b.domain.com.
The proposed solution is to host untrusted content on a second domain. For example, if we run mycompany.com, we should store user content on a second domain like mycompany-users.com.
Let's say we have this scenario: Our company provides a SaaS service for our customers. Each customer will be given their own URL to login and use the service. Customers are allowed to customize the look and feel of their instance by modifying the HTML, css and javascript of their pages.
In this case, we have company1.mycompany-users.com and company2.mycompany-users.com.
Let's say a malicious employee called Mallory at company1 implements some javascript that uses a cookie tossing attack or a cookie jar overflow attack to set or replace the cookies on .mycompany-users.com.
An employee at company2 is then tricked to visit that page on company1.mycompany-users.com and have their cookies on .mycompany-users.com replaced or modified.
Since the server does not receive the domain of the cookie, we cannot filter out cookies by their domains. Provided that the app is secure, the attacker cannot read or write to information on company1.mycompany-users.com. In addition, session ids are regenerated on login. However, it still annoys people because the session data is damaged and if the user is logged into company2.mycompany-users.com he would be logged out because the session id is invalid.
Besides forcing customers to buy their own domains, is there anyway to prevent malicious people at company1.mycompany-users.com to cause users at company2.mycompany-users.com to logout due to cookie attacks?
