I don’t see how this would work. When the browser renders an “ff” ligature, it does not do so by converting every “ff” in the input into U+FB00, as such it will never use this font unless the user input actually contains U+FB00 which is unlikely.
Khaled, you're right - it doesn't work. The characters are not substituted. I made a quick proof of concept, but it triggered for the wrong reasons. Bummer.
Neat, but don't think its exploitable in reality, but neat indeed.
Did a bit of play around with it and it does seem to work on input fields but fortunately not on password type fields (which is logical, considering the browser is not rendering the actual characters for password fields)
I know of one community website that allows users to use custom third-party CSS and that shows a user's email address in the settings page, so I think you could at least leak email addresses through this (you can target a single input with the fake font, and email addresses aren't random, so the caveat of repeated characters not showing isn't that problematic).
This site doesn't allow password unmasking, but if it did that would also make it quite vulnerable on this front.
I can't make this work on my side, both Chromium and Firefox block the requests for the font resources from l0.cm (because CORS policy):
Font from origin 'http://l0.cm' has been blocked from loading by Cross-Origin Resource Sharing policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://lepunk.co.uk' is therefore not allowed access.
It can work on passwords too by the way, maybe it can give you an idea of the order based on the query order, and remember... this work only if the data got already loaded or the attribute got changed by JavaScript and not by manually typing...
Edit: Tested that but it load the last bg only (make sense), so you need to use animation for that to load them one after one.
They don't let you use urls. To use images in their custom stylesheet you have to upload it to reddit, then use a special code or something, that gets replaced with the image url.
They're setting custom fonts, but specifying the fonts should only be used for particular characters.
This attack assumes the attacker has some way of getting CSS they wrote onto the target website, via some other exploit.
The attacker then hosts many font files on a webserver they control. Let's call the fonts "a", "b", "c", and so on.
They then inject the CSS to set the font for text on the target page to their custom fonts - but tell it "use font a for all of the 'a' characters" and so on.
By observing which fonts are downloaded from their webserver, they can learn information on which characters are and are not present on the page.
If it's helpful: the "sting" of this attack is that it works even when you can't inject Javascript into the page; that's why it's referred to as an "HTML injection attack".
The canonical HTML injection attack is cross-site scripting --- it's so canonical, in fact, that we usually just think about XSS, and not the generalized flaw of HTML injection. This is an illustration of how even closing off Javascript as an attack vector doesn't stop HTML injection attacks from working.
If you get HTML/CSS control isn't that game over? If I can get HTML loaded into your Gmail tab, then I can setup a fake login or "Please re-enter your password to continue" that has a form action of myserver. (Which then just redirects you to wherever you were.)
Injecting scripting is cute because it's far more flexible, but I'd guess an HTML injection is enough to get a fairly high rate of success, albeit a bit more noticeably.
means "use the font-file 'http://attacker.example.com/?A' to format the text of element '#sensitive-information' but only to format the letter (glyph?) A". Presumably, the browser only bothers sending the request if it needs to, so my server at attacker.example.com can look out for ?A request to determine if the referer contains an element with that text.
As stated, the attack vector will be limited, but this could certainly leak some information if you can get a site to host that CSS.
I'm not really experienced in @font-face, but I think it's specifing a different webfont for single unicode characters (using the range attribute).
Chrome will then try to fetch the font from the many URLs, making an HTTP request for every character in the field (say "Hello" will try to fetch ?H, ?e, ?l, ?o) in the order it finds them.
If you're on the other side (ie. the server serving the font) you can rebuild the original string by seeing which requests have been made and in which order.
Haven't tried it, but I doubt it'll try to fetch the same letter twice, so most of the time the string wouldn't be complete (but again, I haven't tried so I don't know for sure).
This may not work exactly as planned if your target string is expected to be long enough. You can see from his example that the fetching takes place out of order, as expected from asynchronous calls.
Same as most html injection attacks. I haven't tested as I'm on the way to work, but I will try to craft the attack as follows:
1: discover html attribute vulnerable to this.
2: craft payload as a link, for Dom, reflected or stored.
3: watch them type characters as rules are triggered. (Is this possible to use as a key logger?!)
So that's general, then more specifically As an attacker I would probably trigger a password lock of the target where the user has to enter security questions. Then gather that information. Another reason to hate security questions.
Remediation:
Output encode in the proper context! This most certainly qualifies as the exact reason why your fancy blacklist (or whitelist) filter set is not the proper mitigation for xss. In the above scenario, The attacker is injecting rules as inline css in the context of an html attribute, so then output encode in that context.
Also I need to check if it can bypass the CSP in any way, though I doubt it.
Sorry for the organization or this post, as I mentioned im on the train.
When I try the proofs of concept in Firefox 41, I see all font requests being done at once at page load time, regardless of whether the font resource is used or not. This actually foils the exploit.
I suppose this is the way to mitigate the issue, to download unconditionally all the font resources for which the `unicode-range` is smaller than a minimum number of characters?
That is because release builds of Firefox does not support unicode-range, it just downloads all the fonts. But for unicode-range to be really supported, it must only download the fonts for ranges used in the page, as this feature is usually used to split huge fonts (like CJK ones) and let the browser only downloads what is really needed.
you could combine this with ::first-letter and custom selectors for each item of interest to get more specific data from targeted page elements...
If there was a way to target n-th letter in css, you could also get the full plaintext of an element with a huge number of font-face / selector combinations
The short answer is probably not, for the simple reason that CSS and HTML support in email is generally pretty poor. Most webmail clients rely on having to rewrite CSS (for obvious reasons), which means that properties tend to be on a whitelist rather than a blacklist, and I think @font-face is usually not on that list. For many clients, there is also hopefully remote resource load prevention that prevents it from working.
