2

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?

  • Where did you get the terms cookie tossing and cookie overflow? – atk Jun 6 '14 at 1:11
  • 1
    @atk I have updated my question with the github post where these terms were used: github.com/blog/1466-yummy-cookies-across-domains – F21 Jun 6 '14 at 1:14
  • 1
    From the GitHub blog post, it sounds like they concluded that no, it is not possible to protect against this attack without giving every customer their own separate domain. – Ajedi32 Dec 23 '15 at 17:34
  • Basically, if untrusted JavaScript code can run on a sub or sibling domain of your domain, you are vulnerable to session fixation attacks, period. So... yeah. Thanks a lot browser vendors. – Ajedi32 Dec 23 '15 at 17:50
  • @F21 thanks for the links, though i dont know your answer but i could find answers for my questions in provided links ;) thanks man – Mohammad Siavashi Aug 28 '16 at 4:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.