Re: Timing attacks against CSS Shaders

On Mon, Dec 5, 2011 at 8:40 AM, Adam Barth <> wrote:

> On Sun, Dec 4, 2011 at 11:35 AM, Ralph Thomas <> wrote:
> > Until there is a strategy on preventing timing leaks, is there a way
> > you could change the content being shaded to not include sensitive
> > information (no external iframes, no :visited on links going to other
> > domains, no external-domain images [or none that needed
> > cookies/auth/etc to fetch])? Kind of like XHR is careful not to fetch
> > things it shouldn't.
> It's difficult to enumerate all the sources of sensitive information.
> It's long been part of the web security model that a web site can
> display content and information that it is not allowed to read.

Another problem in some browsers is <input type="file"> displaying
information that the page itself shouldn't know, such as the full path of
the file.

As an obscure example, consider the red wavy lines that many browsers
> draw under misspelled words.

Cool example.

It's very unclearly to me how we'd know we'd blocked all the sensitive
> inputs.


It would be very useful for white-hat security researchers to study the
extent of the problem using features already available such as CSS
transforms and SVG filters, and then see whether and how CSS shaders make
the problem worse. That would help us make informed decisions here.

"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John

Received on Tuesday, 6 December 2011 00:56:43 UTC