Subdomains as a weapon in the hands of hackers: what is it, Cookie Tossing

Internet security is an issue that has recently become increasingly relevant for a wide segment of the consumer market. The risks and threats when working online are constantly increasing, hackers' actions are becoming more sophisticated, complex, affecting more and more new areas. And it is extremely difficult for both ordinary users and business representatives to withstand all these conditions. Risks and dangers are constantly growing, because Internet attackers have learned to identify the smallest vulnerabilities in security systems and use them in their own illegal actions.

DNS interception, credential substitution, DDoS attacks - these are only the most common and popular technologies that hackers actively use to gain access to user devices and confidential information. But along with them, there are many, many other types of targeted actions that, in the hands of skilled craftsmen, turn into an extremely formidable weapon, fraught with serious consequences for individual users and businesses as a whole.

We will dwell on one of these little-known, but very dangerous hacker attacks in more detail today. In particular, today's review will focus on Cookie Tossing or, as it is often called, Cookie Dropping. Its essence lies in the fact that Internet attackers initially gain access to one of your subdomains, say, to a blog. Initially, you might think that the damage from such an attack will not be too serious, because everything is limited to gaining access to pages with informational materials. But this opinion is wrong. The fact is that hackers understand perfectly well how cookies work in browsers. And if they gain access to the substitution, then through them they will be able to affect the main domain of your site. And this is not something from the realm of fantasy, but a clearly thought-out and proven technique based on a deep understanding of the work of web technology in general.

So how does Cookie Tossing work and how does a hacker manage to deceive browsers with their multi-level protection system with its help? What technical aspects underlie such an attack? What actions can hackers do with your cookies? What factors increase such vulnerability? Is the situation the same in all browsers? What strategies for protection against such attacks exist today? How to build a truly secure system and what tools and frameworks will help with this? Now we will try to find answers to all these questions. The information provided will allow you to take a different look at ensuring the security of your own site, assess its vulnerabilities to a Cookie Tossing attack and take a number of measures aimed at increasing resistance.

What is Cookie Tossing: How Hackers Manage to Trick Browsers

Cookie Tossing is a fairly modern tool at the disposal of Internet attackers, which uses a basic and one might even say fundamental feature of the browser's processing of cookies. In the event that a subdomain creates cookies, it will necessarily indicate the parent domain in its attribute - Domain. And here the browser has no choice but to simply accept these files, and subsequently these cookies will be applied to the entire parent domain. But what happens if you already have several similar files with the same names for the same domain? And here serious confusion arises and one might even say a problem, which becomes the very weak link that the actions of the Internet attacker will be directed at.

If you do not delve too deeply into the technical nuances of such an attack, but look directly at its essence, you can see that the mechanism of such an impact is quite simple. Let's assume that you have a site "site.com", as well as cookies for it called "session". In parallel to this, there is also a subdomain, let's say "eval.site.com", which also sets its own cookies with the same name, but for the domain ".site.com".

How will the browser react to such actions? Obviously, it will listen to your command and send both cookie versions to your server. And here we have a natural question: which of these requests will the hardware process first? It's impossible to say definitively, as this depends on a wide range of diverse factors. For example, it could be the installation order, the internal logic of your browser, or even how the server application is a priori able to resolve the conflict. And this is the key factor that hackers exploit.

The particular danger and difficulty here is that most online applications are simply unable to handle duplicate cookies. Even developers themselves don't always consider this. They assume that a session cookie will always be unique. For them, this is a kind of axiom that requires no proof. So what do they do in such a situation? They simply use the first value they encounter. What if these aren't real cookies coming from your site, but fake ones—ones sent by an online attacker? What consequences could this have for your resource? It's certainly not good. It's important to understand that if your PHP application requests "$_COOKIE[session_id]", it could very well receive several HTTP headers and take the first one it finds. And there's a very high probability that it could be fake.

The Technical Side of Cookie Tossing

The technical implementation of a cookie tossing attack is based on gaining complete control over a subdomain of your site. This can be accomplished by hacking the server hosting the subdomain, using DNS hijacking or an XSS vulnerability. After that, the attacker carefully examines the subdomain, specifically which cookies your main domain uses. The relevant information can be obtained directly in the browser using the built-in Developer Tools. If necessary, any other specialized programs capable of intercepting traffic can also be connected. Based on the obtained information, custom fake cookies are created. The names remain exactly the same as on your site, but their meaning changes. Clearly, this will pose a certain risk to your site.

Next, the hacker moves on to the crucial step: installing a malicious cookie with the correct Domain attribute. As a result, the JavaScript code on the compromised subdomain might look like this: "document.cookie = "sessionid=malicious_attacker_session_id; Domain=.site.com; Path=/; Secure; HttpOnly; SameSite=Lax"" To make their cookies as identical to the real ones as possible, an internet attacker can add the "Secure" and "HttpOnly" flags. Incidentally, if your original cookies are marked "HttpOnly," JavaScript won't be able to read their value even if it wanted to. However, setting a new cookie with the exact same name won't be a problem.

In practice, if the hacker doesn't know the real value of your real cookies, they simply use the session identifier they created earlier. The end result: the browser on the device being attacked by a cookie tossing attack will send both versions of the cookie—your real one and the fake one—every time it makes a request to the primary domain. It's impossible to predict how the server will handle multiple cookies with the same name received simultaneously. It may choose the first version or the last one received, whichever it deems more correct. This means that in this case, there's a 50% chance that the attacker's cookies will be processed, not your real ones. This is the loophole hackers exploit in practice when carrying out such an attack.

Possible Uses of Cookies

Currently, Internet security is more of a myth than a reality. In particular, the same Cookie Tossing opens up a lot of opportunities for hackers to deploy their illegal activities. In practice, the most common scenario involves the substitution of session cookies. In this case, an Internet attacker creates his own session within your system, which allows him to find out its identifier. Then he just needs to create a fake cookie and throw it at you using Cookie Tossing. As a result, the "victim's" device unknowingly begins to use the hacker's session, which will automatically lead to Session Hijacking, that is, account hijacking.

Another possible option, and a rather dangerous one, is related to authentication cookies. Currently, quite a large number of online applications use special tokens, such as JWT. They are placed inside cookies to ensure your connection status to the system. And if in reality such files are substituted, then at the output you get an absolute compromise of your account, and the Internet attacker takes control of access to absolutely all functions, services, information.

Increased vulnerability will be observed in those systems where cookies are used to store key security settings or collect user preferences. Let's assume that the application will store information in such files about whether you need or do not need multi-factor authentication. As a result, a hacker can manually disable it for you by simply planting fake cookies containing information that additional security measures are not needed in this case, or by resetting the verification status.

Cookie Tossing Example

To better understand how a Cookie Tossing attack works, let's consider a hypothetical example. Let's assume that an Internet attacker decided to attack an online banking system. This company has an official online representative office "bank.com", as well as its version adapted for work on mobile devices "mobile.bank.com", as well as a separate section intended for partners "https://www.google.com/search?q=partners.bank.com". In this case, a cookie file called «auth_token» is used to log in.

To gain access to the target resource, the Internet attacker initially targets less secure versions of the site, namely the mobile version, as well as the one intended for the banking institution's partners. He identifies an XSS vulnerability, albeit in the feedback form, where insufficient attention was paid to cleaning the entered information. Now he has the opportunity to write malicious JavaScript code using fake «auth_token» cookies and then use it for the entire «.bank.com» domain. In this case, the value of such a file will contain a pre-created token belonging to the account of the Internet attacker himself.

Now about what will happen when you go to the official website of the bank «bank.com». Your browser sends both the real and the fake cookie to the server. If it happens that the banking system, due to its internal settings, initially processes the fake file, then you, as a user who does not suspect a trick, will enter your login and password directly into the account of the Internet attacker. Thanks to this, absolutely all your actions in the online banking system will become visible to the hacker. That is, he will be able to view your balance, track transfers and even enter payment information.

Just think how a minor problem, which many would not pay attention to at all, can lead to such serious and unforeseen consequences. This is the key danger of the Cookie Tossing attack: using the smallest vulnerabilities, hackers manage to gain access to extremely important and sensitive user information.

Several real examples of Cookie Tossing attacks

Above, we examined a hypothetical situation using online banking as an example, but unfortunately, today we can find numerous real-world examples of cookie tossing, clearly demonstrating that we are not dealing with theory, but with real vulnerabilities that can have an extremely negative impact on businesses and individual users. Now, let's look at two real-world examples that demonstrate the seriousness of the consequences of cookie tossing attacks:

1. A hack of the main account of the Swiss telecommunications company Swisscom, which was accompanied by a direct transition to two-factor authentication. This attack was based on a fairly common dependency. Specifically, the login function relied on a state cookie (session), which allowed for tracking user progress. The hackers injected their own state cookie and were able to bypass the login and password entry step during authentication. It turns out that anyone attempting to connect to this telecom company's platform would immediately proceed to the two-factor authentication request (assuming they had it activated), or even directly to the setup process if the user hadn't used two-factor authentication at all. In the latter case, a hacker could easily install any data recovery method and obtain their victim's current session token, automatically granting them full access to the account. This problem proved extremely serious in practice. It also turned out to be extremely difficult to detect, so much so that the company was unable to resolve the issue on its own. Specifically, a reward of 4,000 Swiss francs was offered to anyone who could find it.
2. "Poisoning" of a search engine powered by Perplexity.ai. This case demonstrated how cookie tossing attacks can be used to deliberately discredit user activity. At its core, Perplexity.ai is a kind of search engine that uses artificial intelligence to provide concise answers to user questions. In this case, the attack consisted of hackers injecting their own cookie sessions targeting endpoints directly related to the chat function. In other words, it was a kind of websocket connection. Users who started using this tool were unaware they were inside the hacker's session. As a result, all their confidential requests went directly to the attacker's internet account. The attacker then inspected these requests, literally "poisoning" people's actions without any trace of malicious activity.

These are just two examples demonstrating the seriousness and stealth of all attacks based on cookie tossing. But a more detailed analysis reveals many more such attacks that have proven extremely successful in practice. But there's no point in examining them in more detail now. It's far more important to consider why this happens and how to counter it.

Factors Increasing Vulnerability to Cookie Tossing

Experience shows that the effectiveness of cookie tossing attacks directly depends on a number of specific factors. The main problem here is that such "weaknesses" are present in most modern online applications. In particular, we're talking about the following factors:

1. Application architecture. The difficulty here is that the system's functionality doesn't include cookie integrity checking. Furthermore, it doesn't use additional validation mechanisms, such as cryptographic signatures. This presents a rather serious vulnerability. It turns out that we're opening the door to online attackers, literally inviting them to exploit existing attack opportunities.
2. Using a large number of subdomains for various services. The greater the number, the larger the attack surface. This increases the likelihood of a subdomain being compromised, which opens up more opportunities for hackers to carry out their plans. Subdomains where users can upload their own content or those that allow users to create their own pages, including blogs, are particularly dangerous.
3. The order in which the server processes cookies. This is a truly important aspect. It turns out that if your hardware processes cookies in the order they arrive from the browser, which often depends on the sequence in the HTTP Cookie header (i.e., takes the first value encountered), this opens up additional opportunities for a hacker. Specifically, an online attacker can forcefully change this order by setting cookie timings or exploiting browser specifics. Today, there are servers or frameworks that process files randomly, but this is also unsafe.

Susceptibility to cookie tossing attacks also largely depends on the type of browser used.

Specifics of Chrome and Firefox: Why do these browsers behave differently?

Analyzing the behavior of different browsers, you can see that some solutions use their own algorithms for processing repeated cookies. This adds a certain element of unpredictability for online attackers. For example, Chrome and Firefox can manage cookies in different sequences. This means that hackers need to adapt their methods to the browser being used.

Some internet browsers also use heuristics to determine the priority of cookie processing. This means that newer files or those with a more specific path automatically receive priority over common files or those processed earlier. This, in turn, opens up new opportunities for hackers who have a thorough understanding of the specifics of the attack and the intricacies of the mechanism, in particular.

Cookie Tossing Attack Detection Methods

One of the most effective and efficient ways to detect cookie tossing is to identify online attackers' activity as quickly as possible, before their actions spread to your main domain and cause serious damage. However, such identification is a complex task that can only be accomplished through a comprehensive approach. It is necessary to develop a consistent action plan that will allow you to identify even the slightest traces of hacker activity. At this stage, the following recommendations can be of significant assistance:

• Monitor multiple cookies on a regular basis. One of the most obvious signs of a cookie tossing attack is the appearance of multiple cookies in requests to your server, each with a different value but the same name. To detect this, you will need to use a good Web Application Firewall, configuring it to detect such anomalies and automatically block all suspicious requests.
• Monitor each subdomain on your website. This is truly critical to preventing hacker attacks in general. You must respond to any unexpected changes in DNS records, suspicious activity on existing subdomains, and the appearance of new ones. You must constantly monitor all of these factors and respond to them as quickly as possible. It's important to understand that such behavior often indicates hacker activity, specifically the compromise of a subdomain.
• Regular analysis of server logs. We recommend constantly and carefully examining your server logs to identify suspicious activity. You should be alerted to suspicious activity, sudden changes in session behavior, such as a rapid and unexpected change in the session ID for one user, unusual switching between different users, anomalous access patterns for your system, such as requests from different sessions coming from the same IP-address, and so on. These are all factors that could also indicate a cookie tossing attack.
• Integration with Security Information and Event Management (SIEM) systems. This will allow you to connect information security-related events coming from various sources. Alternatively, the system might detect that one of your subdomains is compromised, followed immediately by the installation of suspicious cookies. A good SIEM system will immediately identify the pattern and generate a high-priority alert. This means your information security team will immediately receive relevant information and be able to prevent negative consequences as quickly as possible.
• Using automated systems, including those based on artificial intelligence. These technologies have already taken a prominent place in the field of information security. Machine learning is already possible here, including for identifying cookie tossing attacks. Neural network algorithms automatically analyze cookie installation patterns, determine session duration, and identify unusual user behavior. For example, it can detect if a user enters authentication data from one device, and then their session unexpectedly switches to another.

In practice, it is advisable to combine all of these methods, as this is the only way to create a truly comprehensive and integrated monitoring system, which will form the basis for subsequently protecting your resources from cookie tossing attacks.

Modern Methods of Protection against Cookie Tossing Attacks

As with detection, protection against cookie tossing attacks also requires a comprehensive approach. Here, you'll need to implement several layers, carefully considering all the solutions that will be used in practice. Ultimately, you should have three so-called lines of defense:

1. Correctly configuring cookies.
2. Architectural solutions.
3. Validation in the application.

Let's look at each of these steps in more detail, which will allow you to understand their specifics and implement everything as correctly as possible in practice.

Correctly configuring cookies

In today's review, we already mentioned the concept of flags in cookies. This is something that can significantly complicate a hacker's work, and in some cases, even discourage them from implementing their plan. In particular, in practice, you can use the following attribute options:

• Secure. Adding this flag will indicate that cookies can only be transmitted over the HTTPS protocol, which in itself will significantly complicate the work of hackers, namely, intercepting and analyzing them. This means you must use this flag every time for absolutely all authentication and session cookies. This rule should be a foundation and should never be omitted.
• SameSite. This flag allows you to add an additional layer of protection, limiting the sending of cookies in cross-site requests. You can use several attribute formats here. Alternatively, "SameSite=Strict" can maximally restrict the use of these cookies. It will only be sent in the case of a direct link to the site, but if a user accesses your site via a link from an email or uses other connection methods, the operation of some applications may still be disrupted. In practice, it is used for the most critical session cookies, but only if it does not impair functionality. The second possible option is "SameSite=Lax". In this case, cookies will be sent only when top-level navigation requests are made, such as when clicking a link. However, if such a request is initiated by a third-party site, it will be automatically blocked. This solution is rightfully considered optimal in terms of security and stability and can be used by default for most cookies. Another option is "SameSite=None; Secure". It is useful when working with cookies that will be sent in a cross-site context, which is typical when working with third-party widgets.
• HttpOnly. Using this flag ensures that access to cookies via JavaScript is blocked. This significantly reduces the likelihood of cookie tossing attacks, which exploit XSS vulnerabilities. This means that even if an internet attacker manages to inject a malicious script, they won't be able to read or subsequently replace your files. Unfortunately, this method remains inactive if the hacker decides to exploit server vulnerabilities on your subdomains to carry out their plan.

You can combine these flags in practice, thereby providing a more reliable level of protection against cookie tossing attacks.

Using Validation in Applications

Using validation in applications will help your server constantly be alert and detect inconsistencies as quickly as possible. Specifically, we recommend using solutions such as:

• Server-side validation. All applications you plan to use should not only check for the presence of a cookie but also monitor its integrity. Specifically, for critical cookies, we recommend using Hash-based Message Authentication Code (HMAC), i.e., cryptographic signatures. This will make file tampering impossible. Alternatively, you can add a special hash to your cookies, generating it using the secret key and other session parameters.
• Timestamps. These must be enabled in cookies to track their lifecycle. Therefore, cookies that are too old or, conversely, recently created but show increased activity may be automatically rejected by the system as potentially dangerous.
• Checking additional characteristics. This should be performed during each session check. In particular, it is recommended to check the user's IP address, User-Agent, and a number of other parameters related to the request. If the address or browser is changed within the same session, this indicates a potential cookie tossing attack.

Use these methods to prevent online hackers and ensure the stable operation of your application.

Using Additional Architectural Solutions

There are also several solutions here that will increase the resilience of your subdomains to hacker attacks. In particular:

• Using isolation. This means using separate domains for different services instead of subdomains. This eliminates the possibility of a cookie tossing attack altogether. If this solution is not feasible, you should ensure that each of your subdomains operates in a separate, highly isolated environment.
• Using tokens instead of cookies. This solution will be effective for the most important, even critical, operations. Alternatively, you can use JSON Web Tokens (JWT) in the headers. These tokens are much more difficult to counterfeit. Moreover, they are completely immune to cookie tossing attacks, as they are not transmitted automatically by the browser, as is the case with cookies.
• CSP. Here, we are talking about using a strict Content Security Policy, which will limit the implementation of malicious code through substitutions. This eliminates the possibility of successful XSS attacks, which underlie many cookie tossing attacks.

Consider which of these protection methods are relevant for your specific situation and use them to build increased resilience into your applications.

Additional Recommendations for Developers

Regardless of the specific products they work with, every developer must consider the possibility of a cookie tossing attack. This should be done during the software design phase. There's even a specific term for this, called "Security by Design." To implement this approach, you need to take the following steps:

1. Check your code. Here, special attention should be paid to how cookies are handled, how session validation works, and how correctly the application responds to suspicious or duplicate files.
2. Regular penetration testing, often referred to as pentesting, is performed. This work is often outsourced by specialists who are thoroughly familiar with the specifics of the work to be performed. This means they will specifically test your software product's resilience to such threats.
3. Use the capabilities that automated security testing provides you. In particular, you can simulate a Cookie Tossing attack. You will have a fairly wide range of Dynamic Application Security Testing tools at your disposal, which will help you perform the upcoming work as correctly as possible and identify the risk long before the attack itself occurs.
4. Pay due attention to training the team. It is important for you to create conditions on site in which launching Cookie Tossing will not give the desired results. And this is possible only when the level of awareness in this matter is at a high level. Only in this way will it be possible to avoid the most common mistakes and create truly secure code. Regular security training for developers will pay for itself as quickly as possible.

Each of you can implement all these points independently in your own practice, thereby ensuring maximum efficiency of work aimed at countering Cookie Tossing attacks.

Tools and frameworks for effective work

Today, the market offers an extremely wide variety of specialized solutions in the field of web development, which by default include protection against Cookie Tossing attacks, as well as other actions of Internet intruders directly “out of the box”. Here, as an example, we can cite Express.js, Ruby on Rails, Django, ASP.NET Core. They already have built-in mechanisms for handling sessions, which involve the automatic use of protected cookies.

You will also have specialized libraries at your disposal, such as “js-cookie” for working with these files on the client side, as well as "tough-cookie" specifically for Node.js. Built-in security checking mechanisms are also often used here. This is what can significantly reduce the likelihood of errors on your part, which can become exactly the "bottleneck" that an Internet attacker will use to carry out their attack.

Summing Up

Application security is an extremely important issue that requires a comprehensive approach and constant monitoring. This is the only way you can prevent serious threats to your products. We have described in detail the measures that need to be taken for this in today's review. Use the recommendations provided to release truly safe and reliable software products to the market, as well as pay attention to regularly updating your own knowledge in this area and introducing advanced tools into practical use.

Mobile proxies from the MobileProxy.Space service will provide you with significant assistance here. With their help, you can effectively bypass any regional restrictions and access blocking, gaining access to up-to-date information regarding the latest threats and ways to combat them. High confidentiality and security of work on the Internet in general, the ability to automate routine and similar work are also guaranteed. More detailed information about the functionality, current prices can be found at the link https://mobileproxy.space/en/user.html?buyproxy. You can also use mobile proxy testing for free, and in case of difficulties in work, contact technical support. Specialists are available 24 hours a day.

分享文章：