Sunday, November 28, 2021

Data Exfiltration via CSS + SVG Font

This post will show that the SVG fonts and CSS can be used for reading the page's text contents.

There are several known ways to read the page's text contents with CSS. The known techniques are well covered in the following article by Juan Manuel Fernández:

CSS Injection Primitives :: DoomsDay Vault

These techniques can be useful to attackers in some situations, for example, when the input is sanitized and only limitted HTML tags can be used, or JavaScript cannot be used due to the Content Security Policy (CSP) restrictions.

The technique I want to introduce today is one such technique. The basic idea is the same as the following font ligature trick by Michał Bentkowski.

Stealing Data in Great style – How to Use CSS to Attack Web Application. -

It is the mostly same but I've never seen any article mentioning this and I thought it is worth mentioning because the technique I'll explain here can be useful in the specific situation such as when Michał's technique cannot be used due to the CSP's restriction, so I'm writing this.

Well, in my Japanese blog post, around here, I explained Michał's trick in detail in my words but the person who is reading this can read English, so please read his article first :)

Okay, you've read it, right? As you learned from his article, he used WOFF fonts convereted from SVG fonts. In my trick, I use SVG fonts without convering it. Michał said "browsers have stopped supporting the SVG format in fonts (hence the need to use the WOFF format)" but in fact, Safari still supports it. After all, the trick I am about to introduce is just a replacement of his trick with SVG fonts. But still, the reason I want to dare to introduce this trick is that SVG fonts can be used even when loading fonts is blocked by the CSP's restriction. That is, SVG fonts allow reading text contents even on pages where the CSP prohibits loading fonts. This is because SVG fonts can not only be loaded from URLs, like WOFF fonts, but also all font's components can be defined with in-line without loading from URLs.

Let's see how Michał's trick can be replaced.

In his trick, the WOFF font is loaded via <style>'s @font-face.

@font-face {
    font-family: "hack";
    src: url(

This style can be replaced with the following inline SVG.

<font horiz-adv-x="0">
<font-face font-family="hack" units-per-em="1000"></font-face>
<glyph unicode="&quot;0" horiz-adv-x="99999" d="M1 0z"></glyph>
<glyph unicode="1" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="2" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="3" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="4" horiz-adv-x="0" d="M1 0z"></glyph>
<glyph unicode="5" horiz-adv-x="0" d="M1 0z"></glyph>

Now, if the font-family property is set to "hack" via CSS, the SVG font is applied to the target's text even outside the SVG. This is not blocked by CSP even if the font-src 'none' is set. (Note that to observe the leaked data, this trick uses the background image request as well as Michał's trick, so at least, the host which can observe the request must be allowed in the img-src directive.)

I'll show you the PoC. When there is a vulnerable page like the following,

<!DOCTYPE html>
<meta charset="utf-8">
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-random';style-src 'unsafe-inline';img-src https:">
<script id="leakme" nonce="random">
const secret = "573ba8e9bfd0abd3d69d8395db582a9e";

<script nonce="random">
const params = (new URL(document.location)).searchParams;
const xss = params.get('xss');

I'll show you SVG fonts can leak the "secret" variable.

You can reproduce it by opening the following URL with Safari and clicking the "Go" button. 


The all code can be found in:

If the PoC works correctly, like the following video, multiple new windows will open and after waiting for a while, the secret variable's string will be displayed little by little, like "573b ..." on the page having the "Go" button.

It's almost the same as Michał's PoC, except that it uses SVG fonts, but there are a few changes. In his PoC, he loads the target page into the iframe but in my PoC, I used instead. This is because Safari blocks all third party cookies by default now and I thought the attack using the iframe is not so realistic PoC for Safari. Also, I changed the way to pass the data.  Here again, due to the third party cookie blocking, the cookie can not be set when the background image is loaded, so I used the session id with the URL parameter instead. 

By the way, if you're used to Chrome, you might wonder why multiple new windows are opened by one click. This is because Safari have the popup blocker but there is no limit to the number of windows that can be opened by one click. Thanks to this, it is possible to efficiently try to read the data using multiple windows. 

That's it. Thanks for reading! I hope this post helps you out.