A recently discovered vulnerability in Apache SkyWalking, a popular application performance monitoring tool, could allow attackers to execute malicious scripts and launch cross-site scripting (XSS) attacks. The flaw, identified as CVE-2025-54057, affects all versions of SkyWalking up to 10.2.0. CVE ID Description Severity Affected Versions CVE-2025-54057 Stored XSS vulnerability in Apache SkyWalking Important Through 10.2.0 [β¦]
SquareX warns Perplexity's Comet AI browser contains a hidden MCP API that bypasses security, allowing attackers to install malware and seize full device control.
When analyzing the content of websites in an attempt to determine what category it belongs to, we sometimes get an utterly unexpected result. It could be the official page of a metal structures manufacturer or online flower shop, or, say, a law firm website, with completely neutral content, but our solutions would place it squarely in the βAdult contentβ category. On the surface, it is completely unclear how our systems arrived at that verdict, but one look at the content categorization engineβs page analysis log clears it up.
Invisible HTML block, or SEO spam
The website falls into the questionable category because it contains an HTML block with links to third-party sites, invisible to regular users. These sites typically host content of a certain kindΒ β which, in our experience, is most often pornographic or gambling materialsΒ β and in the hidden block, you will find relevant keywords along with the links. These practices are a type of Black Hat SEO, or SEO spam: the manipulation of website search rankings in violation of ethical search engine optimization (SEO) principles. Although there are many techniques that attackers use to raise or lower websites in search engine rankings, we have encountered hidden blocks more frequently lately, so this is what this post focuses on.
Website owners rarely suspect a problem until they face obvious negative consequences, such as a sharp drop in traffic, warnings from search engines, or complaints from visitors. Those who use Kaspersky solutions may see their sites blocked due to being categorized as prohibited, a sign that something is wrong with them. Our engine detects both links and their descriptions that are present in a block like that.
How hidden links work
Hyperlinks that are invisible to regular users but still can be scanned by various analytical systems, such as search engines or our web categorization engine, are known as βhidden linksβ. They are often used for scams, inflating website rankings (positions in search results), or pushing down the ranking of a victim website.
To understand how this works, let us look at how todayβs SEO functions in the first place. A series of algorithms is responsible for ranking websites in search results, such as those served by Google. The oldest and most relevant one to this article is known as PageRank. The PageRank metric, or weight in the context of this algorithm, is a numerical value that determines the importance of a specific page. The higher the number of links from other websites pointing to a page, and the greater those websitesβ own weights, the higher the pageβs PageRank.
So, to boost their own websiteβs ranking in search results, the malicious actor places hidden links to it on the victim website. The higher the victim websiteβs PageRank, the more attractive it is to the attacker. High-traffic platforms like blogs or forums are of particular interest to them.
However, PageRank is no longer the only method search engines use to measure a websiteβs value. Google, for example, also applies other algorithms, such as the artificial intelligence-based RankBrain or the BERT language model. These algorithms use more sophisticated metrics, such as Domain Authority (that is, how much authority the website has on the subject the user is asking about), link quality, and context. Placing links on a website with a high PageRank can still be beneficial, but this tactic has a severely limited effect due to advanced algorithms and filters aimed at demoting sites that break the search engineβs rules. Examples of these filters are as follows:
Google Penguin, which identifies and penalizes websites that use poor-quality or manipulative links, including hidden ones, to boost their own rankings. When links like these are detected, their weight can be zeroed out, and the ranking may be lowered for both sites: the victim and the spam website.
Google Panda, which evaluates content quality. If the website has a high PageRank, but the content is of low quality, duplicated, auto-generated, or otherwise substandard, the site may be demoted.
Google SpamBrain, which uses machine learning to analyze HTML markup, page layouts, and so forth to identify manipulative patterns. This algorithm is integrated into Google Penguin.
What a Black Hat SEO block looks like in a pageβs HTML markup
Let us look at some real examples of hidden blocks we have seen on legitimate websites and determine the attributes by which these blocks can be identified.
This example utilizes a simple CSS style,
<div style="display: none;">. This is one of the most basic and widely known methods for concealing content; the parameter
display:none; stands for βdo not displayβ. We also see that each invisible
<div> section contains a set of links to low-quality pornographic websites along with their keyword-stuffed descriptions. This clearly indicates spam, as the website where we found this block has no relation whatsoever to the type of content being linked to.
Another sign of Black Hat SEO in the example is the attribute
rel="dofollow". This instructs search engines that the link carries link juice, meaning it passes weight. Spammers intentionally set this attribute to transfer authority from the victim website to the ones they are promoting. In standard practice, webmasters may, conversely, use
rel="nofollow", which signifies that the presence of the link on the site should not influence the ranking of the website where it leads.
Thus, the combination of a hidden block (
display:none;) and a set of external pornographic (in this instance) links with the
rel="dofollow" attribute unequivocally point to a SEO spam injection.
Note that all
<div> sections are concentrated in one spot, at the end of the page, rather than scattered throughout the page code. This block demonstrates a classic Black Hat SEO approach.
This example demonstrates a slightly more sophisticated approach to hiding the block containing Black Hat SEO content. It suggests an attempt to bypass the automated search engine filters that easily detect the
display:none;Β parameter.
Let us analyze the set of CSS styles:
<div style="overflow: auto; position: absolute; height: 0pt; width: 0pt;">. The properties position:
absolute;height:0pt;width:0pt; remove the block from the visible area of the page, while overflow: auto prevents the content from being displayed even if it exceeds zero dimensions. This makes the links inaccessible to humans, but it does not prevent them from being preserved in the DOM (document object model). Thatβs why HTML code scanning systems, such as search engines, are able to see it.
In addition to the zero dimensions of the block, in this example, just as in the previous one, we see the attribute
rel="dofollow", as well as many links to pornographic websites with relevant keywords.
The combination of styles that sets the block dimensions to zero is less obvious than
display:none; because the element is technically present in the rendering, although it is not visible to the user. Nevertheless, it is worth noting that modern search engine security algorithms, such as Google Penguin, detect this technique too. To counter this, malicious actors may employ more complex techniques for evading detection. Here is another example:
<script src="files/layout/js/slider3d.js?v=0d6651e2"></script><script src="files/layout/js/layout.js?v=51a52ad1"></script>
<style type="text/css">.ads-gold {height: 280px;overflow: auto;color: transparent;}.ads-gold::-webkit-scrollbar { display: none;}.ads-gold a {color: transparent;}.ads-gold {font-size: 10px;}.ads-gold {height: 0px;overflow: hidden;}</style>
<div class="ads-gold">
Ganhe RΓ‘pido nos Jogos Populares do Cassino Online <a href="https://580-bet.com" target="_blank">580bet</a>
Cassino <a href="https://bet-7k.com" target="_blank">bet 7k</a>: DiversΓ£o e Grandes VitΓ³rias Esperam por VocΓͺ
Aposte e VenΓ§a no Cassino <a href="https://leao-88.com" target="_blank">leao</a> β Jogos FΓ‘ceis e Populares
Jogos Populares e Grandes PrΓͺmios no Cassino Online <a href="https://luck-2.com" target="_blank">luck 2</a>
Descubra os Jogos Mais Populares no Cassino <a href="https://john-bet.com" target="_blank">john bet</a> e Ganhe
<a href="https://7755-bet.com" target="_blank">7755 bet</a>: Apostas FΓ‘ceis, Grandes Oportunidades de VitΓ³ria
Jogue no Cassino Online <a href="https://cbet-88.com" target="_blank">cbet</a> e Aumente suas Chances de Ganhar
Ganhe PrΓͺmios IncrΓveis com Jogos Populares no Cassino <a href="https://bet7-88.com" target="_blank">bet7</a>
Cassino <a href="https://pk55-88.com" target="_blank">pk55</a>: Onde a Sorte EstΓ‘ ao Seu Lado
Experimente o Cassino <a href="https://8800-bet.com" target="_blank">8800 bet</a> e Ganhe com Jogos Populares
Ganhe Facilmente no Cassino Online <a href="https://doce-88.com" target="_blank">doce</a>
Aposte e Vença no Cassino <a href="https://bet-4-br.com" target="_blank">bet 4</a>
Jogos Populares e Grandes Premiaçáes na <a href="https://f12--bet.com" target="_blank">f12bet</a>
Descubra a DiversΓ£o e VitΓ³ria no Cassino <a href="https://bet-7-br.com" target="_blank">bet7</a>
Aposte nos Jogos Mais Populares do Cassino <a href="https://ggbet-88.com" target="_blank">ggbet</a>
Ganhe PrΓͺmios RΓ‘pidos no Cassino Online <a href="https://bet77-88.com" target="_blank">bet77</a>
Jogos FΓ‘ceis e RΓ‘pidos no Cassino <a href="https://mrbet-88.com" target="_blank">mrbet</a>
Jogue e Ganhe com Facilidade no Cassino <a href="https://bet61-88.com" target="_blank">bet61</a>
Cassino <a href="https://tvbet-88.com" target="_blank">tvbet</a>: Onde a Sorte EstΓ‘ Ao Seu Lado
Aposte nos Melhores Jogos do Cassino Online <a href="https://pgwin-88.com" target="_blank">pgwin</a>
Ganhe Grande no Cassino <a href="https://today-88.com" target="_blank">today</a> com Jogos Populares
Cassino <a href="https://fuwin-88.com" target="_blank">fuwin</a>: Grandes VitΓ³rias Esperam por VocΓͺ
Experimente os Melhores Jogos no Cassino <a href="https://brwin-88.com" target="_blank">brwin</a>
</div></body>
Aside from the parameters we are already familiar with, which are responsible for concealing a block (
height:0px,color:transparent,overflow:hidden), and the name that hints at its contents (
\<style type="text/css"\>.ads-gold), strings with scripts in this example can be found at the very beginning:
<script src="files/layout/js/slider3d.js?v=0d6651e2"></script> and
<script src="files/layout/js/layout.js?v=51a52ad1"></script>. These indicate that external JavaScript can dynamically control the page content, for example, by adding or changing hidden links, that is, modifying this block in real time.
This is a more advanced approach than the ones in the previous examples. Yet it is also detected by filters responsible for identifying suspicious manipulations.
Other parameters and attributes exist that attackers use to conceal a link block. These, however, can also be detected:
the parameter
visibility:hidden; can sometimes be seen instead of
display:none;.
Within
position:absolute;, the block with hidden links may not have a zero size, but rather be located far beyond the visible area of the page. This can be set, for example, via the property
left:-9232px;, as in the example below.
How attackers place hidden links on other peopleβs websites
To place hidden links, attackers typically exploit website configuration errors and vulnerabilities. This may be a weak or compromised password for an administrator account, plugins or an engine that have not been updated in a long time, poor filtering of user inputs, or security issues on the hosting providerβs side. Furthermore, attackers may attempt to exploit the human factor, for example, by setting up targeted or mass phishing attacks in the hope of obtaining the website administratorβs credentials.
Let us examine in detail the various mechanisms through which an attacker gains access to editing a pageβs HTML code.
Compromise of the administrator password. An attacker may guess the password, use phishing to trick the victim into giving it away, or steal it with the help of malware. Furthermore, the password may be found in a database of leaked credentials. Site administrators frequently use simple passwords for control panel protection or, even worse, leave the default password, thereby simplifying the task for the attacker.
After gaining access to the admin panel, the attacker can directly edit the pageβs HTML code or install their own plugins with hidden SEO blocks.
Exploitation of CMS (WordPress, Joomla, Drupal) vulnerabilities. If the engine or plugins are out of date, attackers use known vulnerabilities (SQL Injection, RCE, or XSS) to gain access to the siteβs code. After that, depending on the level of access gained by exploiting the vulnerability, they can modify template files (header.php, footer.php, index.php, etc.), insert invisible blocks into arbitrary site pages, and so on.
In SQL injection attacks, the hacker injects their malicious SQL code into a database query. Many websites, from news portals to online stores, store their content (text, product descriptions, and news) in a database. If an SQL query, such as
SELECT *FROM posts WHERE id='$id' allows passing arbitrary data, the attacker can use the
$id field to inject their code. This allows the attacker to change the content of records, for example, by inserting HTML with hidden blocks.
In RCE (remote code execution) attacks, the attacker gains the ability to run their own commands on the server where the website runs. Unlike SQL injections, which are limited to the database, RCE provides almost complete control over the system. For example, it allows the attacker to create or modify site files, upload malicious scripts, and, of course, inject invisible blocks.
In an XSS (cross-site scripting) attack, the attacker injects their JavaScript code directly into the web page by using vulnerable input fields, such as those for comments or search queries. When another user visits this page, the malicious script automatically executes in their browser. Such a script enables the attacker to perform various malicious actions, including stealthily adding a hidden
<div> block with invisible links to the page. For XSS, the attacker does not need direct access to the server or database, as in the case with SQL injection or RCE; they only need to find a single vulnerability on the website.
An attack via the hosting provider. In addition to directly hacking the target website, an attacker may attempt to gain access to the website through the hosting environment. If the hosting providerβs server is poorly secured, there is a risk of it being compromised. Furthermore, if multiple websites or web applications run on the same server, a vulnerability in one of them can jeopardize all other projects. The attackerβs capabilities depend on the level of access to the server. These capabilities may include: injecting hidden blocks into page templates, substituting files, modifying databases, connecting external scripts to multiple websites simultaneously, and so forth. Meanwhile, the website administrator may not notice the problem because the vulnerability is being exploited within the server environment rather than the website code.
Note that hidden links appearing on a website is not always a sign of a cyberattack. The issue often arises during the development phase, for example, if an illegal copy of a template is downloaded to save money or if the project is executed by an unscrupulous web developer.
Why attackers place hidden blocks on websites
One of the most obvious goals for injecting hidden blocks into other peopleβs websites is to steal the PageRank from the victim. The more popular and authoritative the website is, the more interesting it is to attackers. However, this does not mean that moderate- or low-traffic websites are safe. As a rule, administrators of popular websites and large platforms do their best to adhere to security rules, so it is not so easy to get close to them. Therefore, attackers may target less popularΒ β and less protectedΒ β websites.
As previously mentioned, this approach to promoting websites is easily detected and blocked by search engines. In the short term, though, attackers still benefit from this: they manage to drive traffic to the websites that interest them until search engine algorithms detect the violation.
Even though the user does not see the hidden block and cannot click the links, attackers can use scripts to boost traffic to their websites. One possible scenario involves JavaScript creating an iframe in the background or sending an HTTP request to the website from the hidden block, which then receives information about the visit.
Hidden links can lead not just to pornographic or other questionable websites but also to websites with low-quality content whose sole purpose is to be promoted and subsequently sold, or to phishing and malicious websites. In more sophisticated schemes, the script that provides βvisitsβ to such websites may load malicious code into the victimβs browser.
Finally, hidden links allow attackers to lower the reputation of the targeted website and harm its standing with search engines. This threat is especially relevant in light of the fact that algorithms such as Google Penguin penalize websites hosting questionable links. Attackers may use these techniques as a tool for unfair competition, hacktivism, or any other activity that involves discrediting certain organizations or individuals.
Interestingly, in 2025, we have more frequently encountered hidden blocks with links to pornographic websites and online casinos on various legitimate websites. With low confidence, we can suggest that this is partly due to the development of neural networks, which make it easy to automate such attacks, and partly due to the regular updates to Googleβs anti-spam systems, the latest of which was completed at the end of September 2025: attackers may have rushed to maximize their gains before the search engine made it a little harder for them.
Consequences for the victim website
The consequences for the victim website can vary in severity. At a minimum, the presence of hidden links placed by unauthorized parties hurts search engine reputation, which may lead to lower search rankings or even complete exclusion from search results. However, even without any penalties, the links disrupt the internal linking structure because they lead to external websites and pass on a portion of the victimβs weight to them. This negatively impacts the rankings of key pages.
Although unseen by visitors, hidden links can be discovered by external auditors, content analysis systems, or researchers who report such findings in public reports. This is something that can undermine trust in the website. For example, sites where our categorization engine detects links to pornography pages will be classified as βAdult contentβ. Consequently, all of our clients who use web filters to block this category will be unable to visit the website. Furthermore, information about a websiteβs category is published on our Kaspersky Threat Intelligence Portal and available to anyone wishing to look up its reputation.
If the website is being used to distribute illegal or fraudulent content, the issue enters the legal realm, with the owner potentially facing lawsuits from copyright holders or regulators. For example, if the links lead to websites that distribute pirated content, the site may be considered an intermediary in copyright infringement. If the hidden block contains malicious scripts or automatic redirects to questionable websites, such as phishing pages, the owner can be charged with fraud or some other cybercrime.
How to detect a hidden link block on your website
The simplest and most accessible method for any user to check a website for a hidden block is to view its source code in the browser. This is very easy to do. Navigate to the website, press Control+U, and the websiteβs code will open in the next tab. Search (Control+F) the code for the following keywords:
display:none,visibility:hidden,opacity:0,height:0,width:0,position:absolute. In addition, you can check for keywords that are characteristic of the hidden content itself. When it comes to links that point to adult or gambling sites, you should look for
porn,sex,casino,card, and the like.
A slightly more complex method is using web developer tools to investigate the DOM for invisible blocks. After the page fully loads, open DevTools (F12) in the browser and go to the Elements tab. Search (Control+F) for keywords such as
<a,iframe,display:none,hidden,opacity. Hover your cursor over suspicious elements in the code so the browser highlights their location on the page. If the block occupies zero area or is located outside the visible area, that is an indicator of a hidden element. Check the Computed tab for the selected element; there, you can see the applied CSS styles and confirm that it is hidden from the userβs view.
You can also utilize specialized SEO tools. These are typically third-party solutions that scan website SEO data and generate reports. They can provide a report about suspicious links as well. Few of them are free, but when selecting a tool, you should be guided primarily by the vendorβs reputation rather than price. It is better to use tried-and-true, well-known services that are known to be free of malicious or questionable payloads. Examples of these trusted services include Google Search Console, Bing Webmaster Tools, OpenLinkProfiler, and SEO Minion.
Another way to discover hidden SEO spam on a website is to check the CMS itself and its files. First, you should scan the database tables for suspicious HTML tags with third-party links that may have been inserted by attackers, and also carefully examine the websiteβs template files (header.php, footer.php, and index.php) and included modules for unfamiliar or suspicious code. Pay particular attention to encrypted insertions, unclear scripts, or links that should not originally be present in the websiteβs structure.
Additionally, you can look up your websiteβs reputation on the Kaspersky Threat Intelligence Portal. If you find it in an uncharacteristic categoryΒ β typically βAdult contentβ, βSexually explicitβ, or βGamblingβΒ β there is a high probability that there is a hidden SEO spam block embedded in your website.
How to protect your website
To prevent hidden links from appearing on your website, avoid unlicensed templates, themes, and other pre-packaged solutions. The entire site infrastructure must be built only on licensed and official solutions. The same principle applies to webmasters and companies you hire to build your website: we recommend checking their work for hidden links, but also for vulnerabilities in general. Never cut corners when it comes to security.
Keep your CMS, themes, and plugins up to date, as new versions often patch known vulnerabilities that attackers can exploit. Delete any unused plugins and themes, if any. The less unnecessary components are installed, the lower the risk of an exploit in one of the extensions, plugins, and themes. It is worth noting that this risk never disappears completelyΒ β it is still there even if you have a minimal set of components as long as they are outdated or poorly secured.
To protect files and the server, it is important to properly configure access permissions. On servers running Linux and other Unix-like systems, use 644 for files and 755 for folders. This means that the owner can open folders, and read and modify folders and files, while the group and other users can only read files and open folders. If write access is not necessary, for example in template folders, forbid it altogether to lower the risk of malicious actors making unauthorized changes. Furthermore, you must set up regular, automatic website backups so that data can be quickly restored if there is an issue.
Additionally, it is worth using web application firewalls (WAFs), which help block malicious requests and protect the site from external attacks. This solution is available in Kaspersky DDoS Protection.
To protect the administrator panel, use only strong passwords and 2FA (Two-Factor Authentication) at all times. You would be well-advised to restrict access to the admin panel by IP address if you can. Only a limited group of individuals should be granted admin privileges.
When you visit almost any website, youβll see a pop-up asking you to accept, decline, or customize the cookies it collects. Sometimes, it just tells you that cookies are in use by default. We randomly checked 647 websites, and 563 of them displayed cookie notifications. Most of the time, users donβt even pause to think about whatβs really behind the banner asking them to accept or decline cookies.
We owe cookie warnings to the adoption of new laws and regulations, such as GDPR, that govern the collection of user information and protection of personal data. By adjusting your cookie settings, you can minimize the amount of information collected about your online activity. For example, you can decline to collect and store third-party cookies. These often arenβt necessary for a website to function and are mainly used for marketing and analytics. This article explains what cookies are, the different types, how they work, and why websites need to warn you about them. Weβll also dive into sensitive cookies that hold the Session ID, the types of attacks that target them, and ways for both developers and users to protect themselves.
What are browser cookies?
Cookies are text files with bits of data that a web server sends to your browser when you visit a website. The browser saves this data on your device and sends it back to the server with every future request you make to that site. This is how the website identifies you and makes your experience smoother.
Letβs take a closer look at what kind of data can end up in a cookie.
First, thereβs information about your actions on the site and session parameters: clicks, pages youβve visited, how long you were on the site, your language, region, items youβve added to your shopping cart, profile settings (like a theme), and more. This also includes data about your device: the model, operating system, and browser type.
Your sign-in credentials and security tokens are also collected to identify you and make it easier for you to sign in. Although itβs not recommended to store this kind of information in cookies, it can happen, for example, when you check the βRemember meβ box. Security tokens can become vulnerable if they are placed in cookies that are accessible to JS scripts.
Another important type of information stored in cookies that can be dangerous if it falls into the wrong hands is the Session ID: a unique code assigned to you when you visit a website. This is the main target of session hijacking attacks because it allows an attacker to impersonate the user. Weβll talk more about this type of attack later. Itβs worth noting that a Session ID can be stored in cookies, or it can even be written directly into the URL of the page if the user has disabled cookies.
Example of a Session ID as displayed in the Firefox browserβs developer panel
Example of a Session ID as seen in a URL address: example.org/?account.php?osCsid=dawnodpasb<...>abdisoa.
Besides the information mentioned above, cookies can also hold some of your primary personal data, such as your phone number, address, or even bank card details. They can also inadvertently store confidential company information that youβve entered on a website, including client details, project information, and internal documents.
Many of these data types are considered sensitive. This means if they are exposed to the wrong people, they could harm you or your organization. While things like your device type and what pages you visited arenβt typically considered confidential, they still create a detailed profile of you. This information could be used by attackers for phishing scams or even blackmail.
Main types of cookies
Cookies by storage time
Cookies are generally classified based on how long they are stored. They come in two main varieties: temporary and persistent.
Temporary, or session cookies, are used during a visit to a website and deleted as soon as you leave. They save you from having to sign in every time you navigate to a new page on the same site or to re-select your language and region settings. During a single session, these values are stored in a cookie because they ensure uninterrupted access to your account and proper functioning of the siteβs features for registered users. Additionally, temporary cookies include things like entries in order forms and pages you visited. This information can end up in persistent cookies if you select options like βRemember my choiceβ or βSave settingsβ. Itβs important to note that session cookies wonβt get deleted if you have your browser set to automatically restore your previous session (load previously opened tabs). In this case, the system considers all your activity on that site as one session.
Persistent cookies, unlike temporary ones, stick around even after you leave the site. The website owner sets an expiration date for them, typically up to a year. You can, however, delete them at any time by clearing your browserβs cookies. These cookies are often used to store sign-in credentials, phone numbers, addresses, or payment details. Theyβre also used for advertising to determine your preferences. Sensitive persistent cookies often have a special attribute HttpOnly. This prevents your browser from accessing their contents, so the data is sent directly to the server every time you visit the site.
Notably, depending on your actions on the website, credentials may be stored in either temporary or persistent cookies. For example, when you simply navigate a site, your username and password might be stored in session cookies. But if you check the βRemember meβ box, those same details will be saved in persistent cookies instead.
Cookies by source
Based on the source, cookies are either first-party or third-party. The former are created and stored by the website, and the latter, by other websites. Letβs take a closer look at these cookie types.
First-party cookies are generally used to make the site function properly and to identify you as a user. However, they can also perform an analytics or marketing function. When this is the case, they are often considered optional β more on this later β unless their purpose is to track your behavior during a specific session.
Third-party cookies are created by websites that the one youβre visiting is talking to. The most common use for these is advertising banners. For example, a company that places a banner ad on the site can use a third-party cookie to track your behavior: how many times you click on the ad and so on. These cookies are also used by analytics services like Google Analytics or Yandex Metrica.
Social media cookies are another type of cookies that fits into this category. These are set by widgets and buttons, such as βShareβ or βLikeβ. They handle any interactions with social media platforms, so they might store your sign-in credentials and user settings to make those interactions faster.
Cookies by importance
Another way to categorize cookies is by dividing them into required and optional.
Required or essential cookies are necessary for the websiteβs basic functions or to provide the service youβve specifically asked for. This includes temporary cookies that track your activity during a single visit. It also includes security cookies, such as identification cookies, which the website uses to recognize you and spot any fraudulent activity. Notably, cookies that store your consent to save cookies may also be considered essential if determined by the website owner, since they are necessary to ensure the resource complies with your chosen privacy settings.
The need to use essential cookies is primarily relevant for websites that have a complex structure and a variety of widgets. Think of an e-commerce site that needs a shopping cart and a payment system, or a photo app that has to save images to your device.
A key piece of data stored in required cookies is the above-mentioned Session ID, which helps the site identify you. If you donβt allow this ID to be saved in a cookie, some websites will put it directly in the pageβs URL instead. This is a much riskier practice because URLs arenβt encrypted. Theyβre also visible to analytics services, tracking tools, and even other users on the same network as you, which makes them vulnerable to cross-site scripting (XSS) attacks. This is a major reason why many sites wonβt let you disable required cookies for your own security.
Example of required cookies on the Osano CMP website
Optional cookies are the ones that track your online behavior for marketing, analytics, and performance. This category includes third-party cookies created by social media platforms, as well as performance cookies that help the website run faster and balance the load across servers. For instance, these cookies can track broken links to improve a websiteβs overall speed and reliability.
Essentially, most optional cookies are third-party cookies that arenβt critical for the site to function. However, the category can also include some first-party cookies for things like site analytics or collecting information about your preferences to show you personalized content.
While these cookies generally donβt store your personal information in readable form, the data they collect can still be used by analytics tools to build a detailed profile of you with enough identifying information. For example, by analyzing which sites you visit, companies can make educated guesses about your age, health, location, and much more.
A major concern is that optional cookies can sometimes capture sensitive information from autofill forms, such as your name, home address, or even bank card details. This is exactly why many websites now give you the choice to accept or decline the collection of this data.
Special types of cookies
Letβs also highlight special subtypes of cookies managed with the help of two similar technologies that enable non-standard storage and retrieval methods.
A supercookie is a tracking technology that embeds cookies into website headers and stores them in non-standard locations, such as HTML5 local storage, browser plugin storage, or browser cache. Because theyβre not in the usual spot, simply clearing your browserβs history and cookies wonβt get rid of them.
Supercookies are used for personalizing ads and collecting analytical data about the user (for example, by internet service providers). From a privacy standpoint, supercookies are a major concern. Theyβre a persistent and hard-to-control tracking mechanism that can monitor your activity without your consent, which makes it tough to opt out.
Another unusual tracking method is Evercookie, a type of zombie cookie. Evercookies can be recovered with JavaScript even after being deleted. The recovery process relies on the unique user identifier (if available), as well as traces of cookies stored across all possible browser storage locations.
How cookie use is regulated
The collection and management of cookies are governed by different laws around the world. Letβs review the key standards from global practices.
General Data Protection Regulation (GDPR) and ePrivacy Directive (Cookie Law) in the European Union.
Under EU law, essential cookies donβt require user consent. This has created a loophole for some websites. You might click βReject Allβ, but that button might only refuse non-essential cookies, allowing others to still be collected.
Lei Geral de Proteção de Dados Pessoais (LGPD) in Brazil.
This law regulates the collection, processing, and storage of user data within Brazil. It is largely inspired by the principles of GDPR and, similarly, requires free, unequivocal, and clear consent from users for the use of their personal data. However, LGPD classifies a broader range of information as personal data, including biometric and genetic data. It is important to note that compliance with GDPR does not automatically mean compliance with LGPD, and vice versa.
California Consumer Privacy Act (CCPA) in the United States.
The CCPA considers cookies a form of personal information. This means their collection and storage must follow certain rules. For example, any California resident has the right to stop cross-site cookie tracking to prevent their personal data from being sold. Service providers are required to give users choices about what data is collected and how itβs used.
The UKβs Privacy and Electronic Communications Regulations (PECR, or EC Directive) are similar to the Cookie Law.
PECR states that websites and apps can only save information on a userβs device in two situations: when itβs absolutely necessary for the site to work or provide a service, or when the user has given their explicit consent to this.
Federal Law No. 152-FZ βOn Personal Dataβ in Russia.
The law broadly defines personal data as any information that directly or indirectly relates to an individual. Since cookies can fall under this definition, they can be regulated by this law. This means websites must get explicit consent from users to process their data.
In Russia, website owners must inform users about the use of technical cookies, but they donβt need to get consent to collect this information. For all other types of cookies, user consent is required. Often, the user gives this consent automatically when they first visit the site, as itβs stated in the default cookie warning.
Some sites use a banner or a pop-up window to ask for consent, and some even let users choose exactly which cookies theyβre willing to store on their device.
Beyond these laws, website owners create their own rules for using first-party cookies. Similarly, third-party cookies are managed by the owners of third-party services, such as Google Analytics. These parties decide what kind of information goes into the cookies and how itβs formatted. They also determine the cookiesβ lifespan and security settings. To understand why these settings are so important, letβs look at a few ways malicious actors can attack one of the most critical types of cookies: those that contain a Session ID.
Session hijacking methods
As discussed above, cookies containing a Session ID are extremely sensitive. They are a prime target for cybercriminals. In real-world attacks, different methods for stealing a Session ID have been documented. This is a practice known as session hijacking. Below, weβll look at a few types of session hijacking.
Session sniffing
One method for stealing cookies with a Session ID is session sniffing, which involves intercepting traffic between the user and the website. This threat is a concern for websites that use the open HTTP protocol instead of HTTPS, which encrypts traffic. With HTTP, cookies are transmitted in plain text within the headers of HTTP requests, which makes them vulnerable to interception.
Attacks targeting unencrypted HTTP traffic mostly happen on public Wi-Fi networks, especially those without a password and strong security protocols like WPA2 or WPA3. These protocols use AES encryption to protect traffic on Wi-Fi networks, with WPA3 currently being the most secure version. While WPA2/WPA3 protection limits the ability to intercept HTTP traffic, only implementing HTTPS can truly protect against session sniffing.
This method of stealing Session ID cookies is fairly rare today, as most websites now use HTTPS encryption. The popularity of this type of attack, however, was a major reason for the mass shift to using HTTPS for all connections during a userβs session, known as HTTPS everywhere.
Cross-site scripting (XSS)
Cross-site scripting (XSS) exploits vulnerabilities in a websiteβs code to inject a malicious script, often written in JavaScript, onto its webpages. This script then runs whenever a victim visits the site. Hereβs how an XSS attack works: an attacker finds a vulnerability in the source code of the target website that allows them to inject a malicious script. For example, the script might be hidden in a URL parameter or a comment on the page. When the user opens the infected page, the script executes in their browser and gains access to the siteβs data, including the cookies that contain the Session ID.
Session fixation
In a session fixation attack, the attacker tricks your browser into using a pre-determined Session ID. Thus, the attacker prepares the ground for intercepting session data after the victim visits the website and performs authentication.
Hereβs how it goes down. The attacker visits a website and gets a valid, but unauthenticated, Session ID from the server. They then trick you into using that specific Session ID. A common way to do this is by sending you a link with the Session ID already embedded in the URL, like this: http://example.com/?SESSIONID=ATTACKER_ID. When you click the link and sign in, the website links the attackerβs Session ID to your authenticated session. The attacker can then use the hijacked Session ID to take over your account.
Modern, well-configured websites are much less vulnerable to session fixation than XSS-like attacks because most current web frameworks automatically change the userβs Session ID after they sign in. However, the very existence of this Session ID exploitation attack highlights how crucial it is for websites to securely manage the entire lifecycle of the user session, especially at the moment of sign-in.
Cross-site request forgery (CSRF)
Unlike session fixation or sniffing attacks, cross-site request forgery (CSRF or XSRF) leverages the websiteβs trust in your browser. The attacker forces your browser, without your knowledge, to perform an unwanted action on a website where youβre signed in β like changing your password or deleting data.
For this type of attack, the attacker creates a malicious webpage or an email message with a harmful link, piece of HTML code, or script. This code contains a request to a vulnerable website. You open the page or email message, and your browser automatically sends the hidden request to the target site. The request includes the malicious action and all the necessary (for example, temporary) cookies for that site. Because the website sees the valid cookies, it treats the request as a legitimate one and executes it.
Variants of the man-in-the-middle (MitM) attack
A man-in-the-middle (MitM) attack is when a cybercriminal not only snoops on but also redirects all the victimβs traffic through their own systems, thus gaining the ability to both read and alter the data being transmitted. Examples of these attacks include DNS spoofing or the creation of fake Wi-Fi hotspots that look legitimate. In an MitM attack, the attacker becomes the middleman between you and the website, which gives them the ability to intercept data, such as cookies containing the Session ID.
Websites using the older HTTP protocol are especially vulnerable to MitM attacks. However, sites using the more secure HTTPS protocol are not entirely safe either. Malicious actors can try to trick your browser with a fake SSL/TLS certificate. Your browser is designed to warn you about suspicious invalid certificates, but if you ignore that warning, the attacker can decrypt your traffic. Cybercriminals can also use a technique called SSL stripping to force your connection to switch from HTTPS to HTTP.
Predictable Session IDs
Cybercriminals donβt always have to steal your Session ID β sometimes they can just guess it. They can figure out your Session ID if itβs created according to a predictable pattern with weak, non-cryptographic characters. For example, a Session ID may contain your IP address or consecutive numbers, and a weak algorithm that uses easily predictable random sequences may be used to generate it.
To carry out this type of attack, the malicious actor will collect a sufficient number of Session ID examples. They analyze the pattern to figure out the algorithm used to create the IDs, then apply that knowledge to predicting your current or next Session ID.
Cookie tossing
This attack method exploits the browserβs handling of cookies set by subdomains of a single domain. If a malicious actor takes control of a subdomain, they can try to manipulate higher-level cookies, in particular the Session ID. For example, if a cookie is set for sub.domain.com with the Domain attribute set to .domain.com, that cookie will also be valid for the entire domain.
This lets the attacker βtossβ their own malicious cookies with the same names as the main domainβs cookies, such as Session_id. When your browser sends a request to the main server, it includes all the relevant cookies it has. The server might mistakenly process the hackerβs Session ID, giving them access to your user session. This can work even if you never visited the compromised subdomain yourself. In some cases, sending invalid cookies can also cause errors on the server.
How to protect yourself and your users
The primary responsibility for cookie security rests with website developers. Modern ready-made web frameworks generally provide built-in defenses, but every developer should understand the specifics of cookie configuration and the risks of a careless approach. To counter the threats weβve discussed, here are some key recommendations.
Recommendations for web developers
All traffic between the client and server must be encrypted at the network connection and data exchange level. We strongly recommend using HTTPS and enforcing automatic redirect from HTTP to HTTPS. For an extra layer of protection, developers should use the HTTP Strict Transport Security (HSTS) header, which forces the browser to always use HTTPS. This makes it much harder, and sometimes impossible, for attackers to slip into your traffic to perform session sniffing, MitM, or cookie tossing attacks.
It must be mentioned that the use of HTTPS is insufficient protection against XSS attacks. HTTPS encrypts data during transmission, while an XSS script executes directly in the userβs browser within the HTTPS session. So, itβs up to the website owner to implement protection against XSS attacks. To stop malicious scripts from getting in, developers need to follow secure coding practices:
Validate and sanitize user input data.
Implement mandatory data encoding (escaping) when rendering content on the page β this way, the browser will not interpret malicious code as part of the page and will not execute it.
Use the HttpOnly flag to protect cookie files from being accessed by the browser.
Use the Content Security Policy (CSP) standard to control code sources. It allows monitoring which scripts and other content sources are permitted to execute and load on the website.
For attacks like session fixation, a key defense is to force the server to generate a new Session ID right after the user successfully signs in. The website developer must invalidate the old, potentially compromised Session ID and create a new one that the attacker doesnβt know.
An extra layer of protection involves checking cookie attributes. To ensure protection, it is necessary to check for the presence of specific flags (and set them if they are missing): Secure and HttpOnly. The Secure flag ensures that cookies are transmitted over an HTTPS connection, while HttpOnly prevents access to them from the browser, for example through scripts, helping protect sensitive data from malicious code. Having these attributes can help protect against session sniffing, MitM, cookie tossing, and XSS.
Pay attention to another security attribute, SameSite, which can restrict cookie transmission. Set it to Lax or Strict for all cookies to ensure they are sent only to trusted web addresses during cross-site requests and to protect against CSRF attacks. Another common strategy against CSRF attacks is to use a unique, randomly generated CSRF token for each user session. This token is sent to the userβs browser and must be included in every HTTP request that performs an action on your site. The site then checks to make sure the token is present and correct. If itβs missing or doesnβt match the expected value, the request is rejected as a potential threat. This is important because if the Session ID is compromised, the attacker may attempt to replace the CSRF token.
To protect against an attack where a cybercriminal tries to guess the userβs Session ID, you need to make sure these IDs are truly random and impossible to predict. We recommend using a cryptographically secure random number generator that utilizes powerful algorithms to create hard-to-predict IDs. Additional protection for the Session ID can be ensured by forcing its regeneration after the user authenticates on the web resource.
The most effective way to prevent a cookie tossing attack is to use cookies with the __Host- prefix. These cookies can only be set on the same domain that the request originates from and cannot have a Domain attribute specified. This guarantees that a cookie set by the main domain canβt be overwritten by a subdomain.
Finally, itβs crucial to perform regular security checks on all your subdomains. This includes monitoring for inactive or outdated DNS records that could be hijacked by an attacker. We also recommend ensuring that any user-generated content is securely isolated on its own subdomain. User-generated data must be stored and managed in a way that prevents it from compromising the security of the main domain.
As mentioned above, if cookies are disabled, the Session ID can sometimes get exposed in the website URL. To prevent this, website developers must embed this ID into essential cookies that cannot be declined.
Many modern web development frameworks have built-in security features that can stop most of the attack types described above. These features make managing cookies much safer and easier for developers. Some of the best practices include regular rotation of the Session ID after the user signs in, use of the Secure and HttpOnly flags, limiting the session lifetime, binding it to the clientβs IP address, User-Agent string, and other parameters, as well as generating unique CSRF tokens.
There are other ways to store user data that are both more secure and better for performance than cookies.
Depending on the websiteβs needs, developers can use different tools, like the Web Storage API (which includes localStorage and sessionStorage), IndexedDB, and other options. When using an API, data isnβt sent to the server with every single request, which saves resources and makes the website perform better.
Another exciting alternative is the server-side approach. With this method, only the Session ID is stored on the client side, while all the other data stays on the server. This is even more secure than storing data with the help of APIs because private information is never exposed on the client side.
Tips for users
Staying vigilant and attentive is a big part of protecting yourself from cookie hijacking and other malicious manipulations.
Always make sure the website you are visiting is using HTTPS. You can check this by looking at the beginning of the website address in the browser address bar. Some browsers let the user view additional website security details. For example, in Google Chrome, you can click the icon right before the address.
This will show you if the βConnection is secureβ and the βCertificate is validβ. If these details are missing or data is being sent over HTTP, we recommend maximum caution when visiting the website and, whenever possible, avoiding entering any personal information, as the site does not meet basic security standards.
When browsing the web, always pay attention to any security warnings your browser gives you, especially about suspicious or invalid certificates. Seeing one of these warnings might be a sign of an MitM attack. If you see a security warning, itβs best to stop what youβre doing and leave that website right away. Many browsers implement certificate verification and other security features, so it is important to install browser updates promptly β this replaces outdated and compromised certificates.
We also recommend regularly clearing your browser data (cookies and cache). This can help get rid of outdated or potentially compromised Session IDs.
Always use two-factor authentication wherever itβs available. This makes it much harder for a malicious actor to access your account, even if your Session ID is exposed.
When a site asks for your consent to use cookies, the safest option is to refuse all non-essential ones, but weβll reiterate that sometimes, clicking βReject cookiesβ only means declining the optional ones. If this option is unavailable, we recommend reviewing the settings to only accept the strictly necessary cookies. Some websites offer this directly in the pop-up cookie consent notification, while others provide it in advanced settings.
The universal recommendation to avoid clicking suspicious links is especially relevant in the context of preventing Session ID theft. As mentioned above, suspicious links can be used in whatβs known as session fixation attacks. Carefully check the URL: if it contains parameters you do not understand, we recommend copying the link into the address bar manually and removing the parameters before loading the page. Long strings of characters in the parameters of a legitimate URL may turn out to be an attackerβs Session ID. Deleting it renders the link safe. While youβre at it, always check the domain name to make sure youβre not falling for a phishing scam.
In addition, we advise extreme caution when connecting to public Wi-Fi networks. Man-in-the-middle attacks often happen through open networks or rogue Wi-Fi hotspots. If you need to use a public network, never do it without a virtual private network (VPN), which encrypts your data and makes it nearly impossible for anyone to snoop on your activity.
Self-hosted blind XSS hunter via Docker. Deploy xsshunterβexpress in five minutes to capture stealthy XSS payloads with screenshots, DOM dumps, and full context.
Web Hacking Playground is a controlled web hacking environment. It consists of vulnerabilities found in real cases, both in pentests and in Bug Bounty programs. The objective is that users can practice with them, and learn to detect and exploit them.
Other topics of interest will also be addressed, such as: bypassing filters by creating custom payloads, executing chained attacks exploiting various vulnerabilities, developing proof-of-concept scripts, among others.
Important
The application source code is visible. However, the lab's approach is a black box one. Therefore, the code should not be reviewed to resolve the challenges.
Additionally, it should be noted that fuzzing (both parameters and directories) and brute force attacks do not provide any advantage in this lab.
Setup
It is recommended to use Kali Linux to perform this lab. In case of using a virtual machine, it is advisable to use the VMware Workstation Player hypervisor.
The environment is based on Docker and Docker Compose, so it is necessary to have both installed.
To install Docker on Kali Linux, run the following commands:
It is recommended to log out and log in again so that the user is recognized as belonging to the docker group.
To install Docker Compose, run the following command:
sudo apt install -y docker-compose
Note: In case of using M1 it is recommended to execute the following command before building the images:
export DOCKER_DEFAULT_PLATFORM=linux/amd64
The next step is to clone the repository and build the Docker images:
git clone https://github.com/takito1812/web-hacking-playground.git cd web-hacking-playground docker-compose build
Also, it is recommended to install the Foxy Proxy browser extension, which allows you to easily change proxy settings, and Burp Suite, which we will use to intercept HTTP requests.
We will create a new profile in Foxy Proxy to use Burp Suite as a proxy. To do this, we go to the Foxy Proxy options, and add a proxy with the following configuration:
Proxy Type: HTTP
Proxy IP address: 127.0.0.1
Port: 8080
Deployment
Once everything you need is installed, you can deploy the environment with the following command:
git clone https://github.com/takito1812/web-hacking-playground.git cd web-hacking-playground docker-compose up -d
This will create two containers of applications developed in Flask on port 80:
The vulnerable web application (Socially): Simulates a social network.
The exploit server: You should not try to hack it, since it does not have any vulnerabilities. Its objective is to simulate a victim's access to a malicious link.
Important
It is necessary to add the IP of the containers to the /etc/hosts file, so that they can be accessed by name and that the exploit server can communicate with the vulnerable web application. To do this, run the following commands:
sudo sed -i '/whp-/d' /etc/hosts echo "$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-socially) whp-socially" | sudo tee -a /etc/hosts echo "$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-exploitserver) whp-exploitserver" | sudo tee -a /etc/hosts
When using the exploit server, the above URLs must be used, using the domain name and not the IPs. This ensures correct communication between containers.
When it comes to hacking, to represent the attacker's server, the local Docker IP must be used, since the lab is not intended to make requests to external servers such as Burp Collaborator, Interactsh, etc. A Python http.server can be used to simulate a web server and receive HTTP interactions. To do this, run the following command:
sudo python3 -m http.server 80
Stages
The environment is divided into three stages, each with different vulnerabilities. It is important that they are done in order, as the vulnerabilities in the following stages build on those in the previous stages. The stages are:
Stage 1: Access with any user
Stage 2: Access as admin
Stage 3: Read the /flag file
Important
Below are spoilers for each stage's vulnerabilities. If you don't need help, you can skip this section. On the other hand, if you don't know where to start, or want to check if you're on the right track, you can extend the section that interests you.
Stage 1: Access with any user
Display
At this stage, a specific user's session can be stolen through Cross-Site Scripting (XSS), which allows JavaScript code to be executed. To do this, the victim must be able to access a URL in the user's context, this behavior can be simulated with the exploit server.
The hints to solve this stage are:
Are there any striking posts on the home page?
You have to chain two vulnerabilities to steal the session. XSS is achieved by exploiting an Open Redirect vulnerability, where the victim is redirected to an external URL.
The Open Redirect has some security restrictions. You have to find how to get around them. Analyze which strings are not allowed in the URL.
Cookies are not the only place where session information is stored. Reviewing the source code of the JavaScript files included in the application can help clear up doubts.
Stage 2: Access as admin
Display
At this stage, a token can be generated that allows access as admin. This is a typical JSON Web Token (JWT) attack, in which the token payload can be modified to escalate privileges.
The hint to solve this stage is that there is an endpoint that, given a JWT, returns a valid session cookie.
Stage 3: Read the /flag file
Display
At this stage, the /flag file can be read through a Server Site Template Injection (SSTI) vulnerability. To do this, you must get the application to run Python code on the server. It is possible to execute system commands on the server.
The hints to solve this stage are:
Vulnerable functionality is protected by two-factor authentication. Therefore, before exploiting the SSTI, a way to bypass the OTP code request must be found. There are times when the application trusts the requests that are made from the same server and the HTTP headers play an important role in this situation.
The SSTI is Blind, this means that the output of the code executed on the server is not obtained directly. The Python smtpd module allows you to create an SMTP server that prints messages it receives to standard output:
The application uses Flask, so it can be inferred that the template engine is Jinja2 because it is recommended by the official Flask documentation and is widely used. You must get a Jinja2 compatible payload to get the final flag.
The email message has a character limitation. Information on how to bypass this limitation can be found on the Internet.
Solutions
Detailed solutions for each stage can be found in the Solutions folder.
Resources
The following resources may be helpful in resolving the stages:
Web Hacking Playground is a controlled web hacking environment. It consists of vulnerabilities found in real cases, both in pentests and in Bug Bounty programs. The objective is that users can practice with them, and learn to detect and exploit them.
Other topics of interest will also be addressed, such as: bypassing filters by creating custom payloads, executing chained attacks exploiting various vulnerabilities, developing proof-of-concept scripts, among others.
Important
The application source code is visible. However, the lab's approach is a black box one. Therefore, the code should not be reviewed to resolve the challenges.
Additionally, it should be noted that fuzzing (both parameters and directories) and brute force attacks do not provide any advantage in this lab.
Setup
It is recommended to use Kali Linux to perform this lab. In case of using a virtual machine, it is advisable to use the VMware Workstation Player hypervisor.
The environment is based on Docker and Docker Compose, so it is necessary to have both installed.
To install Docker on Kali Linux, run the following commands:
It is recommended to log out and log in again so that the user is recognized as belonging to the docker group.
To install Docker Compose, run the following command:
sudo apt install -y docker-compose
Note: In case of using M1 it is recommended to execute the following command before building the images:
export DOCKER_DEFAULT_PLATFORM=linux/amd64
The next step is to clone the repository and build the Docker images:
git clone https://github.com/takito1812/web-hacking-playground.git cd web-hacking-playground docker-compose build
Also, it is recommended to install the Foxy Proxy browser extension, which allows you to easily change proxy settings, and Burp Suite, which we will use to intercept HTTP requests.
We will create a new profile in Foxy Proxy to use Burp Suite as a proxy. To do this, we go to the Foxy Proxy options, and add a proxy with the following configuration:
Proxy Type: HTTP
Proxy IP address: 127.0.0.1
Port: 8080
Deployment
Once everything you need is installed, you can deploy the environment with the following command:
git clone https://github.com/takito1812/web-hacking-playground.git cd web-hacking-playground docker-compose up -d
This will create two containers of applications developed in Flask on port 80:
The vulnerable web application (Socially): Simulates a social network.
The exploit server: You should not try to hack it, since it does not have any vulnerabilities. Its objective is to simulate a victim's access to a malicious link.
Important
It is necessary to add the IP of the containers to the /etc/hosts file, so that they can be accessed by name and that the exploit server can communicate with the vulnerable web application. To do this, run the following commands:
sudo sed -i '/whp-/d' /etc/hosts echo "$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-socially) whp-socially" | sudo tee -a /etc/hosts echo "$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' whp-exploitserver) whp-exploitserver" | sudo tee -a /etc/hosts
When using the exploit server, the above URLs must be used, using the domain name and not the IPs. This ensures correct communication between containers.
When it comes to hacking, to represent the attacker's server, the local Docker IP must be used, since the lab is not intended to make requests to external servers such as Burp Collaborator, Interactsh, etc. A Python http.server can be used to simulate a web server and receive HTTP interactions. To do this, run the following command:
sudo python3 -m http.server 80
Stages
The environment is divided into three stages, each with different vulnerabilities. It is important that they are done in order, as the vulnerabilities in the following stages build on those in the previous stages. The stages are:
Stage 1: Access with any user
Stage 2: Access as admin
Stage 3: Read the /flag file
Important
Below are spoilers for each stage's vulnerabilities. If you don't need help, you can skip this section. On the other hand, if you don't know where to start, or want to check if you're on the right track, you can extend the section that interests you.
Stage 1: Access with any user
Display
At this stage, a specific user's session can be stolen through Cross-Site Scripting (XSS), which allows JavaScript code to be executed. To do this, the victim must be able to access a URL in the user's context, this behavior can be simulated with the exploit server.
The hints to solve this stage are:
Are there any striking posts on the home page?
You have to chain two vulnerabilities to steal the session. XSS is achieved by exploiting an Open Redirect vulnerability, where the victim is redirected to an external URL.
The Open Redirect has some security restrictions. You have to find how to get around them. Analyze which strings are not allowed in the URL.
Cookies are not the only place where session information is stored. Reviewing the source code of the JavaScript files included in the application can help clear up doubts.
Stage 2: Access as admin
Display
At this stage, a token can be generated that allows access as admin. This is a typical JSON Web Token (JWT) attack, in which the token payload can be modified to escalate privileges.
The hint to solve this stage is that there is an endpoint that, given a JWT, returns a valid session cookie.
Stage 3: Read the /flag file
Display
At this stage, the /flag file can be read through a Server Site Template Injection (SSTI) vulnerability. To do this, you must get the application to run Python code on the server. It is possible to execute system commands on the server.
The hints to solve this stage are:
Vulnerable functionality is protected by two-factor authentication. Therefore, before exploiting the SSTI, a way to bypass the OTP code request must be found. There are times when the application trusts the requests that are made from the same server and the HTTP headers play an important role in this situation.
The SSTI is Blind, this means that the output of the code executed on the server is not obtained directly. The Python smtpd module allows you to create an SMTP server that prints messages it receives to standard output:
The application uses Flask, so it can be inferred that the template engine is Jinja2 because it is recommended by the official Flask documentation and is widely used. You must get a Jinja2 compatible payload to get the final flag.
The email message has a character limitation. Information on how to bypass this limitation can be found on the Internet.
Solutions
Detailed solutions for each stage can be found in the Solutions folder.
Resources
The following resources may be helpful in resolving the stages:
Traxss is an automated framework to scan URLs and webpages for XSS Vulnerabilities. It includes over 575 Payloads to test with and multiple options for robustness of tests.
Getting Started
Prerequisites
Traxss depends on Chromedriver. On MacOS this can be installed with the homebrew command:
brew install cask chromedriver
Alternatively, find a version for other operating systems here: https://sites.google.com/a/chromium.org/chromedriver/downloads
Installation
Run the command:
pip3 install -r requirements.txt
Running Traxss
Traxx can be started with the command:
python3 traxss.py
This will launch an interactive CLI to guide you through the process.
Types of Scans
Full Scan with HTML
Uses a query scan with 575+ payloads and attempts to find XSS vulnerabilities by passing parameters through the URL. It will also render the HTML and attempt to find manual XSS Vulnerablities (this feature is still in beta).
Full Scan w/o HTML
This scan will run the query scan only.
Fast Scan w/o HTML
This scan is the same as the full w/ HTML but it will only use 7 attack vectors rather than the 575+ vectors.
Fast Scan w/o HTML
This scan is the same as the fast w/o HTML but it will only use 7 attack vectors rather than the 575+ vectors.
Contributing
Thank you for your interest! All types of contributions are welcome.
Fork and clone this repository
Create your branch from the master branch
Please open your PR with the master branch as the base
For continuous coverage, we push out major Detectify security updates every two weeks, keeping our tool up-to-date with new findings, features and improvements sourced from our security researchersΒ includingΒ theΒ DetectifyΒ CrowdsourceΒ community.
Login
