CSS Injection
Try Hard Security Group
CSS Injection
Attribute Selector
CSS selectors are crafted to match values of an input element's name and value attributes. If the input element's value attribute starts with a specific character, a predefined external resource is loaded:
However, this approach faces a limitation when dealing with hidden input elements (type="hidden") because hidden elements do not load backgrounds.
Bypass for Hidden Elements
To circumvent this limitation, you can target a subsequent sibling element using the ~ general sibling combinator. The CSS rule then applies to all siblings following the hidden input element, causing the background image to load:
A practical example of exploiting this technique is detailed in the provided code snippet. You can view it here.
Prerequisites for CSS Injection
For the CSS Injection technique to be effective, certain conditions must be met:
Payload Length: The CSS injection vector must support sufficiently long payloads to accommodate the crafted selectors.
CSS Re-evaluation: You should have the ability to frame the page, which is necessary to trigger the re-evaluation of CSS with newly generated payloads.
External Resources: The technique assumes the ability to use externally hosted images. This might be restricted by the site's Content Security Policy (CSP).
Blind Attribute Selector
As explained in this post, it's possible to combine the selectors :has and :not to identify content even from blind elements. This is very useful when you have no idea what is inside the web page loading the CSS injection.
It's also possible to use those selectors to extract information from several block of the same type like in:
Combining this with the following @import technique, it's possible to exfiltrate a lot of info using CSS injection from blind pages with blind-css-exfiltration.
@import
The previous technique has some drawbacks, check the prerequisites. You either need to be able to send multiple links to the victim, or you need to be able to iframe the CSS injection vulnerable page.
However, there is another clever technique that uses CSS @import to improve the quality of the technique.
This was first showed by Pepe Vila and it works like this:
Instead of loading the same page once and again with tens of different payloads each time (like in the previous one), we are going to load the page just once and just with an import to the attackers server (this is the payload to send to the victim):
The import is going to receive some CSS script from the attackers and the browser will load it.
The first part of the CSS script the attacker will send is another
@importto the attackers server again.The attackers server won't respond this request yet, as we want to leak some chars and then respond this import with the payload to leak the next ones.
The second and bigger part of the payload is going to be an attribute selector leakage payload
This will send to the attackers server the first char of the secret and the last one
Once the attackers server has received the first and last char of the secret, it will respond the import requested in the step 2.
The response is going to be exactly the same as the steps 2, 3 and 4, but this time it will try to find the second char of the secret and then penultimate.
The attacker will follow that loop until it manages to leak completely the secret.
You can find the original Pepe Vila's code to exploit this here or you can find almost the same code but commented here.
The script will try to discover 2 chars each time (from the beginning and from the end) because the attribute selector allows to do things like:
This allows the script to leak the secret faster.
Sometimes the script doesn't detect correctly that the prefix + suffix discovered is already the complete flag and it will continue forwards (in the prefix) and backwards (in the suffix) and at some point it will hang. No worries, just check the output because you can see the flag there.
Other selectors
Other ways to access DOM parts with CSS selectors:
.class-to-search:nth-child(2): This will search the second item with class "class-to-search" in the DOM.:emptyselector: Used for example in this writeup:
Error based XS-Search
Reference: CSS based Attack: Abusing unicode-range of @font-face , Error-Based XS-Search PoC by @terjanq
The overall intention is to use a custom font from a controlled endpoint and ensure that text (in this case, 'A') is displayed with this font only if the specified resource (favicon.ico) cannot be loaded.
Custom Font Usage:
A custom font is defined using the
@font-facerule within a<style>tag in the<head>section.The font is named
pocand is fetched from an external endpoint (http://attacker.com/?leak).The
unicode-rangeproperty is set toU+0041, targeting the specific Unicode character 'A'.
Object Element with Fallback Text:
An
<object>element withid="poc0"is created in the<body>section. This element tries to load a resource fromhttp://192.168.0.1/favicon.ico.The
font-familyfor this element is set to'poc', as defined in the<style>section.If the resource (
favicon.ico) fails to load, the fallback content (the letter 'A') inside the<object>tag is displayed.The fallback content ('A') will be rendered using the custom font
pocif the external resource cannot be loaded.
Styling Scroll-to-Text Fragment
The :target pseudo-class is employed to select an element targeted by a URL fragment, as specified in the CSS Selectors Level 4 specification. It's crucial to understand that ::target-text doesn't match any elements unless the text is explicitly targeted by the fragment.
A security concern arises when attackers exploit the Scroll-to-text fragment feature, allowing them to confirm the presence of specific text on a webpage by loading a resource from their server through HTML injection. The method involves injecting a CSS rule like this:
In such scenarios, if the text "Administrator" is present on the page, the resource target.png gets requested from the server, indicating the text's presence. An instance of this attack can be executed through a specially crafted URL that embeds the injected CSS alongside a Scroll-to-text fragment:
Here, the attack manipulates HTML injection to transmit the CSS code, aiming at the specific text "Administrator" through the Scroll-to-text fragment (#:~:text=Administrator). If the text is found, the indicated resource is loaded, inadvertently signaling its presence to the attacker.
For mitigation, the following points should be noted:
Constrained STTF Matching: Scroll-to-text Fragment (STTF) is designed to match only words or sentences, thereby limiting its capability to leak arbitrary secrets or tokens.
Restriction to Top-level Browsing Contexts: STTF operates solely in top-level browsing contexts and does not function within iframes, making any exploitation attempt more noticeable to the user.
Necessity of User Activation: STTF requires a user-activation gesture to operate, meaning exploitations are feasible only through user-initiated navigations. This requirement considerably mitigates the risk of attacks being automated without user interaction. Nevertheless, the blog post's author points out specific conditions and bypasses (e.g., social engineering, interaction with prevalent browser extensions) that might ease the attack's automation.
Awareness of these mechanisms and potential vulnerabilities is key for maintaining web security and safeguarding against such exploitative tactics.
For more information check the original report: https://www.secforce.com/blog/new-technique-of-stealing-data-using-css-and-scroll-to-text-fragment-feature/
You can check an exploit using this technique for a CTF here.
@font-face / unicode-range
You can specify external fonts for specific unicode values that will only be gathered if those unicode values are present in the page. For example:
When you access this page, Chrome and Firefox fetch "?A" and "?B" because text node of sensitive-information contains "A" and "B" characters. But Chrome and Firefox do not fetch "?C" because it does not contain "C". This means that we have been able to read "A" and "B".
Text node exfiltration (I): ligatures
Reference: Wykradanie danych w świetnym stylu – czyli jak wykorzystać CSS-y do ataków na webaplikację
The technique described involves extracting text from a node by exploiting font ligatures and monitoring changes in width. The process involves several steps:
Creation of Custom Fonts:
SVG fonts are crafted with glyphs having a
horiz-adv-xattribute, which sets a large width for a glyph representing a two-character sequence.Example SVG glyph:
<glyph unicode="XY" horiz-adv-x="8000" d="M1 0z"/>, where "XY" denotes a two-character sequence.These fonts are then converted to woff format using fontforge.
Detection of Width Changes:
CSS is used to ensure that text does not wrap (
white-space: nowrap) and to customize the scrollbar style.The appearance of a horizontal scrollbar, styled distinctly, acts as an indicator (oracle) that a specific ligature, and hence a specific character sequence, is present in the text.
The CSS involved:
Exploit Process:
Step 1: Fonts are created for pairs of characters with substantial width.
Step 2: A scrollbar-based trick is employed to detect when the large width glyph (ligature for a character pair) is rendered, indicating the presence of the character sequence.
Step 3: Upon detecting a ligature, new glyphs representing three-character sequences are generated, incorporating the detected pair and adding a preceding or succeeding character.
Step 4: Detection of the three-character ligature is carried out.
Step 5: The process repeats, progressively revealing the entire text.
Optimization:
The current initialization method using
<meta refresh=...is not optimal.A more efficient approach could involve the CSS
@importtrick, enhancing the exploit's performance.
Text node exfiltration (II): leaking the charset with a default font (not requiring external assets)
Reference: PoC using Comic Sans by @Cgvwzq & @Terjanq
This trick was released in this Slackers thread. The charset used in a text node can be leaked using the default fonts installed in the browser: no external -or custom- fonts are needed.
The concept revolves around utilizing an animation to incrementally expand a div's width, allowing one character at a time to transition from the 'suffix' part of the text to the 'prefix' part. This process effectively splits the text into two sections:
Prefix: The initial line.
Suffix: The subsequent line(s).
The transition stages of the characters would appear as follows:
C ADB
CA DB
CAD B
CADB
During this transition, the unicode-range trick is employed to identify each new character as it joins the prefix. This is achieved by switching the font to Comic Sans, which is notably taller than the default font, consequently triggering a vertical scrollbar. This scrollbar's appearance indirectly reveals the presence of a new character in the prefix.
Although this method allows the detection of unique characters as they appear, it does not specify which character is repeated, only that a repetition has occurred.
Basically, the unicode-range is used to detect a char, but as we don't want to load an external font, we need to find another way. When the char is found, it's given the pre-installed Comic Sans font, which makes the char bigger and triggers a scroll bar which will leak the found char.
Check the code extracted from the PoC:
Text node exfiltration (III): leaking the charset with a default font by hiding elements (not requiring external assets)
Reference: This is mentioned as an unsuccessful solution in this writeup
This case is very similar to the previous one, however, in this case the goal of making specific chars bigger than other is to hide something like a button to not be pressed by the bot or a image that won't be loaded. So we could measure the action (or lack of the action) and know if a specific char is present inside the text.
Text node exfiltration (III): leaking the charset by cache timing (not requiring external assets)
Reference: This is mentioned as an unsuccessful solution in this writeup
In this case, we could try to leak if a char is in the text by loading a fake font from the same origin:
If there is a match, the font will be loaded from /static/bootstrap.min.css?q=1. Although it won’t load successfully, the browser should cache it, and even if there is no cache, there is a 304 not modified mechanism, so the response should be faster than other things.
However, if the time difference of the cached response from the non-cached one isn't big enough, this won't be useful. For example, the author mentioned: However, after testing, I found that the first problem is that the speed is not much different, and the second problem is that the bot uses the disk-cache-size=1 flag, which is really thoughtful.
Text node exfiltration (III): leaking the charset by timing loading hundreds of local "fonts" (not requiring external assets)
Reference: This is mentioned as an unsuccessful solution in this writeup
In this case you can indicate CSS to load hundreds of fake fonts from the same origin when a match occurs. This way you can measure the time it takes and find out if a char appears or not with something like:
And the bot’s code looks like this:
So, if the font does not match, the response time when visiting the bot is expected to be approximately 30 seconds. However, if there is a font match, multiple requests will be sent to retrieve the font, causing the network to have continuous activity. As a result, it will take longer to satisfy the stop condition and receive the response. Therefore, the response time can be used as an indicator to determine if there is a font match.
References
Try Hard Security Group
Last updated
