CSS:the bomb inside your inbox

Gareth Heyes

Researcher

@garethheyes

• Published: Thursday, 6 August 2026 at 22:00 UTC

• Updated: Thursday, 6 August 2026 at 22:00 UTC

Gareth Heyes - gareth.heyes@portswigger.net - @garethheyes

It's quite common for webmail clients to render untrusted CSS in a trusted UI. They attempt to make this safe using CSS sanitization. In this paper I'm going to show you how to break out of trust boundaries, exfiltrate tokens, compromise 3rd party websites and even steal passwords.

Table of contents

• Introduction
• Abusing allowed HTML/CSS
  • Abusing HTML labels to perform UI actions
  • Controlling AI browsers via email
  • Account takeover from pasting into a draft email
  • Exfiltrating tokens when CSP is blocking all external resources
• Bypassing CSS sanitization
  • Making external requests
  • Syntax quirks
  • Image proxy bypasses
    • Tracking if email is viewed in Fastmail
    • Displaying your IP address in ProtonMail
    • Tracking if email is viewed in Gmail
  • Combining an image proxy bypass with indirect prompt injection
  • CSS mutation in Fastmail
• Exploitation with CSS
  • Defacing Outlook using CSS gadgets
  • CSS hotwiring in Fastmail
  • Stealing passwords
• Defences
• Future attacks
  • HTML only keylogger
  • Chrome real time keylogger
• References
• Materials

Introduction

Webmail has been around for decades and it's always had to solve a very difficult problem of taking untrusted HTML and displaying it to the user in a safe way. This is made even more challenging by each web standard evolving at a relentless pace. To solve this problem webmail uses sanitizers, they attempt to take the HTML provided and restrict it so that it can be displayed to users safely. Trouble is you can create discrepancies between what the sanitizer thinks is safe and what the browser actually renders. Some webmail clients go a step further by letting the browser parse the HTML and CSS first, then filtering the browser's interpreted output rather than the original source. Yet even this can be mutated into something malicious.

Over the last few months I've been looking at webmail clients like Yahoo Mail, AOL Mail, Fastmail, ProtonMail, GMail and Outlook. In search of discrepancies in their parsers and weak points in their sanitizers to produce a range of novel techniques to help exploit them.

Abusing allowed HTML/CSS

In this section I looked at the various "allow listed" CSS properties and HTML. With the goal of abusing them to spoof UI actions, control browsers, take over accounts or steal tokens. I targeted Fastmail, OpenAI's Atlas, Firefox, AOL Mail, Yahoo Mail and Outlook.

Abusing HTML labels to perform UI actions

HTML labels are an often overlooked element, using label tags you can target specific form elements that have an id attribute by using the label's for attribute. This works on any form element and you inherit the click action attached to the element. They are often missed by HTML sanitizers and I found at least 3 webmail clients that were vulnerable to this. I found a real bug in Outlook which would enable me to control Outlook's UI from an email message.

Using the label we can open Outlook's UI ribbon, then we can pin our message to the victim's Outlook. This still works today as Microsoft didn't fix it. If you find a sanitizer that allows labels and doesn't filter the "for" attribute you can use devtools to find targets using the JS below.

This code finds input, button, select and textarea elements that have an id. This was only the start, we'll come back to Outlook later. The label element will prove very useful for us.

Controlling AI browsers via email

OpenAI released a browser called Atlas when I was researching this topic so I decided to see if I could use sanitized CSS to perform indirect prompt injection from an email message in Fastmail.

Before we go further, let's cover the :before and :after pseudo-elements. They let you add text content before or after an element, and you can style that content however you like.They also inherit the element's existing click events, something I'll come back to later when we get to CSS hotwiring. I'll use them to hide text from an AI browser.

Rendered preview:

I experimented with various properties and noticed something interesting, you could use the :before and :after pseudo-elements to hide the text from the LLM and you could use opacity to hide it from the victim. This creates a disparity between what the victim sees and what the LLM sees, potentially altering the email's context.

As you can see I show the victim some French and they naturally use Atlas's AI prompt feature to translate the message but the LLM doesn't see French it sees something completely different:

With a bit of indirect prompt engineering we can fool Atlas into following a "debug" operation when a trigger word is encountered, in this case "translate". When the user types this command Atlas will open some browser tabs and exfiltrate the victim's name from the current web page and send it to a remote server via the hash. I constructed the prompt in this way to bypass confirmation prompts in Atlas, as the LLM compared the text it was given to the destination URL of the tab. By outputting each URL this basically opened all the tabs without confirmation from the user.

Account takeover from pasting into a draft email

Whilst I was in the middle of conducting this research my colleague James Kettle noticed when he copied and pasted his IP address from a website into an email it contained an advert. He was expecting just the text with his IP address but he got more than he bargained for. That led us to wonder what happens if your clipboard contains some malicious CSS.

I began to investigate what each browser did when you had HTML on your clipboard. A probe you can use for this is "<style>*{color:red}</style>". You can then use Hackvertor's "Copy as HTML" button. This creates a blob with HTML and places it on your clipboard. Then on the target site you can search for DOM elements with the contenteditable attribute which is pretty common on webmail clients. When I pasted this probe into AOL and Yahoo! Mail the text of the webpage briefly flashed red. This is a clear indication that the CSS wasn't being sanitized correctly and there was some sort of race condition.

Interestingly there was different behaviour on different browsers. Chrome seems to rewrite inline style blocks into style attributes, Safari just seems to drop the styles whereas Firefox allows inline style tags and background image requests. Out of all the browsers Firefox seemed the best target so I tried to exploit it.

I started to look at what styles Firefox supported, they seemed to block @import requests and animations. This basically prevents you from using recursively importing style sheets and thus you are limited to attributes selectors and brute-forcing the tokens. I then looked for targets that had juicy tokens to steal. One target looked super promising: Medium. They have a login via email feature that produces a 12 character hex token. If you can obtain this token then you can login as the user. An attacker can just initiate this process with the victim's email then create some CSS to copy to the clipboard, the victim then only needs to paste into a draft and then their token is stolen.

Before we start, let's cover the basics. The square brackets define an attribute selector, which consists of an attribute name, an operator, and a value.

The first example matches when the attribute is exactly "x". The second matches when the attribute starts with "x", the third when it ends with "x", and the last one when "x" appears anywhere in the value.

You can't brute force a 12 character hex token, there's just too much CSS! 10 characters is feasible but there can be a lot of trailing junk at the start and end which makes the CSS too large. The answer is nesting, it allows you reduce the amount of CSS by performing the same selector repeatedly without having to output it again.

In these examples we use nested attribute selectors to select an element if the attribute begins with example.com and contains "foo". The "starts with" selector is reused in the second example and selects the element if it starts with example.com and contains "bar".

You can use multiple nested selectors which will be really useful for us to reduce the amount of generated CSS. Here's what the URL looks like:

If we were to use the "starts with" and "ends with" attribute selectors the generated CSS would be too large. However, using nesting we can match the start with one selector that's outputted only once and then nest the other selectors to brute-force the token with a smaller amount of CSS:

We can do this using the "contains" attribute selector but instead of matching just the hex we can also match the prefix of the token parameter name followed by the hex. For example "en=c2e16", we can do the same with the end of the token by using a suffix of "a1781&o". This allows me to precisely get 5 characters at the start and end of the token whilst reducing the CSS. Note that over 5 characters at the start and end is not feasible due to the amount of CSS required. You can even use :not selectors to filter out combinations of hex you're not interested in such as those with a prefix or suffix that appear in the later part of the URL:

In the preceding example I filter out combinations that have a prefix of an underscore. Which are not related to the token. Note technically this isn't necessary and you could reduce the CSS without it however I thought I'd include it because it might be useful in other circumstances. You can also use short variables to reduce the payload and then use them to assign multiple background images. I've done that in the poc code shared in the materials section. I'll share a snippet of the code here so you can see what I mean:

So we have 5 characters at the start and end but we need to get the 2 characters in the middle. Yes you could brute-force those characters using Intruder but I thought it would be fun to solve this with code and it turns out to be quite trivial.

Here we use the contains attribute selector to get 5 chunks of hex, multiple times anywhere in the URL. In these examples we don't know where the hex occurs, we just know the value is somewhere in the URL. There can be a large number of hex chunks because there can be a lot of data in the URL. The goal of these requests is to try and find the two middle characters of the token.

How do you get those extra 2 characters in the middle? So server side we know the start and end of the token and also know multiple 5 character hex chunks that occur anywhere in the URL. To find the middle characters we slice off 1 character from the start part and one character off the end part. Then compare each hex chunk with the slice, if one starts with "bcde" we can work out the 6th character is "f" and if another hex chunk ends with "1234" we know the 7th character is zero. Once we have the full token we can login as the victim on Medium. Note this technique didn't just affect Medium; almost any 12 character hex token can be exfiltrated in this way provided there aren't 4 character duplicate substrings. Both Yahoo Mail and AOL Mail have the same race condition.

Exfiltrating tokens when CSP is blocking all external resources

At this point in this research I asked myself a very simple question: Does a CSP blocking external resources prevent token exfiltration? I like to do this when I'm conducting research because it gives you a clear goal to work towards. Sometimes this goal is possible, sometimes it isn't. The difficult part is recognising which of those is true.

It's quite common for websites to place numeric tokens in text nodes in an email and for users to paste them into a website. Imagine you have a style injection vulnerability in the email and CSP is blocking all external resources. Attribute selectors won't help you here.

To steal this token the first step is to generate links with every digit combination unordered, then move the non-matching links offscreen and make the remaining link full screen.

The problem we've got is that it's not possible to generate every combination of the token but we can generate the digits and the number of times they repeat.

In the first example, clicking the link will exfiltrate the token when it consists of 6 zeros. We now have a method to exfiltrate the tokens, now we need to calculate the digits and how often they repeat. To do that we need a font height oracle and manipulate the digits using animations.

The first step is to create a font-face rule for each digit:

This increases the size of the zero digit if the font-family is assigned "has_0". Note this code doesn't assign the font yet we need to do that using animations:

Notice the keyframe in the middle where we assign the font-family to arial to remove the exfiltration font, this adds a bit of a delay so the digits are detected correctly. This will then introduce oversized digits that we can measure using the font height oracle:

Once we change the height of the digit we can calculate the frequency by taking the calculated height minus the total height before the oversized digits were introduced. Then divide it by the oversized digit height to work out how many times the digit occurs. We use the flag variable to identify the digit so we can play the correct animation:

The goal of the if statement is to play the correct animation that identifies the digit and links it to the frequency of the digit. "Forwards" is used to ensure the animation doesn't loop, it starts in a paused state and the repeat count is 1. So now --c refers to how many digits there are and the --flag allows to link it to the correct digit. Now we know the animation to play, we need to assign to this variable a value of 0% which will become clear later.

Primer on the inset property

So we know the digits and their frequency, we now need to show the correct link and to do that we can use the inset property. This property allows you to control the top, left, right and bottom properties of the link. When using the shorthand inset property with a single value it controls all the properties at once. When each is set at 0% the link covers the whole screen. If it's assigned 100% the link will move offscreen to the bottom right corner.

Now we need to assign to the inset property with 0% for the correct link. To do this we take all the variables and give each a fallback of 100%. Then pass them to the max() function which will return 0% only if every variable is assigned with 0% otherwise it will be assigned 100%. The victim now just needs to click anywhere in the email and the digits and frequency will be sent to the attacker's server.

Bypassing CSS sanitization

It's all well and good abusing the allowed HTML & CSS but at some point you'll want to break the restraints of the sanitizers to break out of the email message window. To do that you need a sanitizer bypass. In this section I targeted Fastmail, ProtonMail, Gmail, Cowork and Slack.

Making external requests

I thought a good place to start was finding all the ways to make external requests in CSS. Turns out there are more than you expect:

Syntax quirks

After looking at how to make external requests I started to look at syntax, I was so surprised how lax CSS actually is. Note I'm intentionally removing the closing parentheses. Here are some interesting examples:

What constitutes a comment is CSS is pretty shocking too:

You can see how useful that syntax could be to fool a sanitizer.

Fuzzing for interesting CSS behaviour

Shazzer has a pretty awesome feature to allow you to fuzz image requests even without JavaScript. This has been around for a while but nobody really used it publicly. I'm going to demonstrate how you can use it to find interesting CSS behaviour.

First off I fuzzed for characters ignored in property names, Firefox has some gold here, it ignores curly braces! This is useful when the CSS sanitizer employs a deny list of property names.

Vector: Characters before CSS property names

Example: <div style="}color:red">test</div>

Next I wanted to identify what properties can cause external requests. There were a lot more than I was expecting. These vectors are useful when you want to find a way to make an external request that is not blocked by the sanitizer.

Vector: CSS Properties that make external requests

Example: <div style=-webkit-mask-box-image:url(//evil)></div>

This next one led to a bug in Fastmail which I'll discuss later. CSS allows hex escapes in-between slashes which means you can fool the sanitizer into thinking the URL is relative.

Vector: CSS escapes that cause an external request in-between forward slashes

Example: <div style="background:url(/\0a/evil)">test</div>

You can use single character escapes too, this means you can use hex escapes without the zero and literal characters too such as a tab.

Vector: Escaped characters that cause an external request in-between forward slashes

Example: <div style="background:url(/\D/evil)">

There are many other interesting vectors that I will make public after my talk. You can grab them from the following Shazzer collection. Using this knowledge I could construct an image proxy bypass.

Image proxy bypasses

So what is an image proxy? The webmail client uses it to proxy image traffic through a server which enables the app to control if the image request is sent or not and protects the email user's IP address from being disclosed to a remote server. If you can bypass the image proxy then you can track when the email is viewed.

I've used Fastmail as an example above, they take a URL base64 encode it and pass it to an image proxy via the path. So now we know what an image proxy is and how it works. Next we're going to bypass them.

Tracking if email is viewed in Fastmail

Going into this research, I assumed there was no reliable way to tell whether someone had opened an email. I soon discovered that wasn't true. This lovely little vector uses an escaped backslash to bypass the image proxy. It also abuses an allowed listed domain in their CSP to track when an email is viewed in Fastmail. The sanitizer thinks the URL is relative whereas the browser thinks the host is user.fm. An attacker can see requests to the user.fm domain via a convenient access log provided by Fastmail. I used this bug to track if the email was viewed but this could also be abused to obtain keystrokes, I'm going to show that later in the paper.

Displaying your IP address in ProtonMail

This is a different technique for bypassing an image proxy, demonstrated against ProtonMail. Using this bug I could embed a graphic of the victim's IP address by default.

They said this wasn't a valid bug and stated you have to bypass remote image protection. Even though ProtonMail's own documentation says:

"Thanks to Proton Mail’s tracker protection, senders cannot use remote images to reliably determine who, when, or where someone opens an email, so remote images are shown automatically in the emails you read.".

Sorry the vector is such a mess, I was planning to simplify the exploit but after testing months later it appears that they silently fixed this. I guess it was a bug after all! It wasn't a great experience reporting a bug to ProtonMail. I've heard from other researchers that they have experienced the same. To contradict their own documentation shows a lack of understanding of their own threat model.

Tracking if email is viewed in Gmail

This vector uses the image-set() function to make a request and uses the fallback string when the variable "x" doesn't exist. This makes a request to a remote server. Gmail is still vulnerable to this despite numerous messages to convince them it's a problem. The triager seemed to think this required user interaction because I was editing a message with devtools. I told them I was only doing this to edit the email. In the end I gave up trying to convince them so we used it to exfiltrate Slack tokens in the next section of the paper.

Combining an image proxy bypass with indirect prompt injection

I had the great opportunity to collaborate with Pete Hendy, a colleague at PortSwigger to hack Cowork. Pete is an expert in making AI do bad things so he seemed like the ideal guy to help turn the Gmail proxy bypass into data exfiltration via indirect prompt injection. Cowork has a Gmail connector, this allows Cowork to interact with Gmail and produce draft emails on behalf of the user. This would be an ideal target since I had already discovered how to bypass the image proxy and make an external request. Now we needed something to steal so we decided to use Slack tokens. We had to construct an email convincing Cowork to go through the emails and find the token and then create a draft. Pete thought it would be a good idea to frame it around a CTF task:

The victim would then tell Cowork to go through all the emails and respond to them, Cowork would encounter this email get the Slack token and construct an HTML email that exfiltrated the token and create a draft email:

The victim would then visit the draft and then the background request would be made which would exfiltrate the Slack token.

CSS mutation in Fastmail

The CSSOM (CSS Object Model) is the browser's in-memory representation of all CSS rules and computed styles, exposed as JavaScript objects that scripts can read and modify. Webmail clients often use the CSSOM to parse and filter the stylesheet because it enables them to get what the browser actually rendered. The trouble is, the browser can perform transformations when the properties are read which can result in perfectly safe CSS mutating into malicious code.

To understand why this is important let's consider what Fastmail does. They take the styles from the HTML email and give the selectors, classes and ids a prefix which restricts the CSS to the user supplied element. This is because they embed the untrusted HTML with trusted HTML and therefore if they didn't add this prefix then the attacker controlled CSS could influence trusted UI on the page.

In this example they change the "x" class into "defanged5-x":

If we can produce some CSS that the sanitizer thinks is safe and mutate it into an unsafe state we can break out of these restrictions and control other elements on the page such as trusted UI or break out of the boundaries of the email message window. To see how this works let's look at a real mutation I found in Chrome that affected Fastmail:

Fastmail uses the CSSOM to parse the stylesheet, they then enumerate it and then read back the data but instead of Chrome returning the escapes as is, it decodes them and therefore mutates the style sheet. In the example the \7d\2a escapes get mutated to }*. I've simplified the example somewhat for clarity. Now you understand the concept we can construct a real mutation that changes all the page text to red:

Keyframe names aren't the only thing that mutates, I found another bug in Fastmail that used media queries to perform similar mutations:

These mutations still exist in Chrome today and any CSS filter that uses the CSSOM could be susceptible to this attack. I had a look at the vulnerable JavaScript to see how this bug occurred and after investigating I could see they outputted the mediaText without performing any filtering:

They fixed this by checking for malicious characters and skipping the media query completely:

Whilst testing for CSS mutation I came up with the following methodology. First you probe for allowed CSS by sending a message with syntax the webmail client might allow. Then you inspect the message with devtools to identify what properties and syntax they allow. Then you follow up and transform your vector to see if it gets mutated. Then repeat this process until you find an exploit. I've used CSS mutation as an example here but you can apply this to general CSS sanitization bypasses too.

Both bugs earned me $1000 bounty each and it was a pleasure to work with the Fastmail team to get them fixed. Using these bugs it was possible to steal clicks and spoof UI actions and even steal passwords which I'll show in the next section.

Exploitation with CSS

So far we've looked at how to get malicious CSS into the webmail client, this section is about exploiting it. Gaining control over the CSS of the webmail client is just the starting point, after that you need to do something with it. Typical exploit paths are defacement, UI spoofing and stealing passwords. We're going to cover defacement first.

Defacing Outlook using CSS gadgets

I was testing the Outlook sanitizer and noticed they used DOMPurify but interestingly they were "allow listing" custom data attributes. I wondered why they were doing this so I examined the DOM and noticed a bunch of custom data attributes being used. Then I took some of these attributes and placed them into my email and observed the DOM when the email was received. To my surprise the sanitized HTML was being processed and the library was using these attributes to perform DOM manipulation. But what kind of manipulation are they doing? This was my next thought, so I inspected the DOM thoroughly and noticed they were appending the sanitized DOM with new nodes that included CSS property values outside of the allow list! This is where CSS gadgets were born.

What is a CSS gadget?

A CSS gadget occurs when some existing JavaScript appends an element to the DOM with a CSS property or value outside the webmail CSS sanitizer allow list. We can use this to break out of trust boundaries.

This is a real CSS gadget that I found on Outlook. Here Outlook "allow lists" custom data attributes. One of the libraries they use appends to the DOM with an element and CSS property value outside their allow list. In this case position:fixed which allows you to position an element anywhere on the page. Which breaks the trust boundaries of an email message:

We can then use this gadget to break out of the message window and deface Outlook. The library attempted to prevent you from overwriting visibility and other properties but because they were on the allow list we can simply use !important to overwrite them.

Here is what my Outlook looked like when viewing the message:

We'll come back to Outlook later on in the paper to abuse this gadget to steal passwords. Next we're going to use the mutated CSS on Fastmail.

CSS hotwiring in Fastmail

So I had arbitrary CSS on Fastmail where I could control all aspects of the page but what damage can you do with just CSS? It turns out that even with just pure CSS you can intercept every click on the page and perform unintended UI actions using a technique called CSS hotwiring.

What is CSS hotwiring?

CSS hotwiring is a technique that allows you to force the victim to click a specific UI action when clicking anywhere on the page including multi-step actions using just CSS. Imagine you receive an email message and it looks like spam, your first reaction would be to move it to spam but actually it was a CSS hotwiring attack and when you attempted to do that you actually performed an unrelated UI action.

How it works

We first need to understand the :before and :after pseudos. They allow you to place text content before and after the element in question. In addition they allow you to customise that text with CSS.

Browser rendered result:

As you can see the browser lets you customise the text and colours before and after the element. But what you might not have realised is that they also inherit the original element's click events!

Conducting a CSS hotwiring attack

First you need to find a visible UI action to attach to. You can do this by inspecting the DOM with devtools and finding interesting elements. I went for the VIP action in Fastmail. Once you've found the element you need a CSS selector to target it. You can do this in devtools using the "Copy selector" feature when you right click and copy on the element. Next, you need to use the selector and use either the :before or :after pseudos to customise the CSS:

It's essential to use the content property otherwise the attack won't work. If you don't use it your pseudo element will be ignored. I use a space to make the element invisible to the victim. Now when you click anywhere on the page the VIP action will be performed or whichever action you've chosen to do. You can even chain these together. For example Fastmail has a side bar, I simply attached to the side bar, opened it up then attached to the VIP action after that. You can use z-index to stack UI actions:

Stealing passwords

For client side attacks using CSS the impact is often low. I wanted to increase impact and so I decided to investigate if it was possible to steal passwords using CSS.

Current CSS keyloggers are a lie

Before we start I need to call out current techniques on this topic. It was declared that you could create a CSS keylogger by using the ends with attribute selector. Unfortunately, this has no practical value, in order for this to work you need a binding between the HTML attribute value and the value DOM property. Without this they simply do not work. To create this binding a JS framework is often required. To illustrate this take a look at the following example:

As you can see the first example sends a background image request whereas if you type into the second input it does not. This is why the current publicly known techniques fail. If I used this CSS in Outlook a request would not be made even if I controlled all the CSS on the page.

My first attempt at a keylogger

This is where the label hijacking clicks comes in handy. We can use the label tag to intercept the clicks on the select element to focus rather than open the select menu which would give away it's not a password field.

Before we build our keylogger we need to cover a selection of CSS syntax that's useful for us. The :has() pseudo-class lets you style an element based on its contents. In this example, the animation plays on the div when the "a" key is pressed. The :checked pseudo-class allows us to react to the option being selected:

My first attempt at a keylogger was to use dictionary words and multiple animations that showed a link for each dictionary word. First you assign an animation per letter. Then when the victim presses a key the animation plays. I'm using the word "at" in this example. When "a" then "t" are pressed the variables will be set to 0%. I use a variable fallback of 100% which means the max() function will only return 0% when both values are set to 0%.

The dictionary keylogger was a good starting point but it wouldn't work in Outlook. So I started to construct a real one. Their CSS sanitizer blocked using :checked with a class. I got round this using the adjacent sibling combinator, this allowed me to target specific options:

I needed to break out of the message window to create a convincing login screen. This is where the CSS gadget I found on Outlook comes in handy. So I used the CSS gadget to gain control over the page. Outlook uses DOMPurify which meant I could construct a fully functional keylogger that works in sanitized CSS and HTML filtered by DOMPurify:

So we had a keylogger but with limitations. It could steal passwords but it wasn't real time and the Outlook toolbar remained because the gadget couldn't hide it. The victim had to wait just under 1 second to type their next letter which is explained in the next paragraphs. It wasn't likely to fool someone. What we needed was a realtime keylogger!

Creating a real time keylogger

It was pretty amazing that I could construct a fully functional keylogger that was protected by DOMPurify and filtered by Outlook's CSS sanitizer but I wasn't satisfied with that. I wanted to make it realtime and to do that we need a browser quirk.

First we need to understand what happens with the select element. When you press a key that selects an option the browser starts a timer, if the next key is not after the currently selected option letter the browser waits for this timer which is just under 1 second before it allows you to select another letter. This is what causes the current keylogger not be realtime. If you look at the sanitized keylogger you'll notice that I repeat the letters in a natural order to compensate for this. (Check the materials section for the full source code)

I spent some time trying to get around this and I discovered that Firefox actually resets this timer when you move the select element off screen. We then just move it back in a very short time and this makes it real time:

We can spoof the select to look like a password input box by using the -webkit-text-security property:

So we have our real time keylogger but a lot of that CSS is not on the allow list of Outlook's sanitizer. We have limited control over the CSS and can capture keystrokes but we want full control over the CSS so we can completely spoof the login screen and fool the victim. What we need to do now is bypass Outlook's CSS sanitizer.

Bypassing Outlook's CSS sanitizer

Here's a good tip when trying to bypass a CSS sanitizer, keep good notes! Record the input you sent and record the transformed output you got back when inspecting with devtools. This is so useful when you want to chain techniques, identify quirks or write it up afterwards. I'm going to share my historical attempts to break Outlook's CSS sanitizer. Thanks to the good notes I kept, you can actually follow the discovery journey:

Import blocked by CSP

Arbitrary CSS selector injection!

Arbitrary CSS injection!

If you followed the attempts closely, a few important milestones stand out. First, I managed to get an @import statement through the sanitizer, only for it to be blocked by the CSP.

What's significant about this is not that I managed to smuggle an import through because on its own it's pretty pointless since the CSP blocks it. The deeper understanding is that Outlook's sanitizer thinks the import is part of the media query! This is why it is allowed.

The second milestone is the ability to inject arbitrary CSS selector:

This turns all the page text to red. So the Outlook sanitizer continues to think the selector is part of the media query even though it's not. We can change the colour to red but what happens when we choose position:fixed? We're still on the allow list, this meant I needed another sanitizer quirk. So finally to the third milestone of the tests. I needed a way to fool Outlook into allowing arbitrary CSS:

This final piece of the puzzle now destroys the CSS sanitizer. It gives me full control over the CSS. It does this by using a comment with a double quote, this fools the sanitizer into thinking this code is part of a string and for some reason this bad sanitizer is perfectly fine with what it thinks are dangling strings.

We have all the elements required to create a realtime keylogger in Outlook and here's a demo of me emailing the victim with an email that takes over the entire screen. Spoofs Outlook's login screen and steals the password on Firefox.

Defences

One of the best methods to protect against these attacks is strict isolation. If you isolate the email message using sandboxed iframes you restrict the ability to break out of trusted boundaries. If you are not using sandboxed iframes, always be careful when allowing custom attributes and check for HTML/CSS gadgets. Use a strict allow list of characters when validating keywords and names to avoid mutation when using the CSSOM.

Block the ability to make image requests from an email message. Blocking data: URLs is a good idea too because they can be used to spoof UI without making external requests. I used them to construct a realistic login screen for Outlook. Avoid using "allow listed" domains that an attacker can control. As we've seen with Fastmail this can be abused.

You should block select menus in your HTML sanitizer. It was still possible to construct a keylogger in "allow listed" HTML/CSS in Outlook. Blocking select would have prevented that.

Dangerous selectors like :has,:checked, :focus and :not shouldn't be allowed either because they can be used to emulate UI components and steal data. You should always investigate your app for gadgets as they can lead to escaping sanitizer restrictions as we've seen with Outlook. Always use an image proxy to restrict image resource requests. Outlook didn't even have one.

Future attacks

HTML only keylogger

Chrome has proposed a new element called selectedcontent, this allows you to customize your select elements but you can use this combined with lazy loaded images to only render the content when visible. This means we can have a HTML only keylogger! The victim presses a key, the image is only loaded when it appears in the selectedcontent element which enables you to steal the keystroke! I use small unicode characters to obscure the text. I love this because it blends cutting edge features with retro HTML:

It's not realtime of course…

Chrome real time keylogger

One thing was bugging me, I had a realtime keylogger in Firefox but not Chrome. So I spent some time trying to figure out a way to make one. I messed around trying to move elements off the screen but no matter what I did I couldn't figure out how to reset Chrome's timer when the key was pressed. Frustrated, I started to look at bleeding edge HTML and found some gold. Interest invokers allow you to control if elements are shown when other elements are focussed or hovered. This gives you a powerful mechanism to create a real time keylogger in Chrome. The only problem is the HTML attributes are currently unlikely to be allowed by a HTML sanitizer. Still basically what you can do is create a select menu for each keystroke you want to capture and then hide them using opacity and show the first one:

Then you link each select together using the interestfor attribute and make each select a popover. Then when the victim types a letter, the next one is focussed and so on:

You can grab all the source code for the techniques mentioned in the materials section.

References

I think it would be a shame if we reached a point where nobody reads blog posts anymore. I've been a web security researcher for over 20 years. I've got where I am today by sharing and learning with other researchers. AI is definitely impactful but that doesn't mean we can't share blog posts and create novel techniques. I've shared my testing notes to emphasize how useful sharing human knowledge is because we can make connections that an AI can't currently do. My goal with this research is to hopefully share things that AI can't quite discover. Yet.

As part of that I want to thank the other researchers that helped me learn techniques that were useful in conducting this research. I would like to thank Rebane for the groundbreaking CSS CPU. I built on the work of Paul Gerste to exfiltrate data using CSS, in particular the font techniques. I'd like to thank Temani Afif for his work in calculating the heights of elements in CSS. Slonser’s work was highly influential when constructing exfiltration methods. The mutation XSS paper by Mario Heiderich et all, was a key influence behind the CSS mutation attacks. Thanks to everyone who shared their knowledge and let's continue to do so even with the rapid pace of AI.

Materials

You can obtain all the source code for the techniques described in the post. I've created separate folders for each technique. You can grab them from the Github repository:

https://github.com/portswigger/css-the-bomb-inside-your-inbox

Thanks for reading!

Gareth Heyes

PortSwigger Research

Back to all articles