W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2013

Help needed (or not?) (was ISSUE-27: Implementation concern on how to enforce display-time : should we provide more advice on how to do this efficiently?)

From: Giorgio Maone <g.maone@informaction.com>
Date: Sun, 10 Feb 2013 21:05:55 +0100
Message-ID: <5117FDA3.6090400@informaction.com>
To: Web Application Security Working Group <public-webappsec@w3.org>
Ragarding UI security's "display-time", http://www.w3.org/TR/UISafety/
just says:
<SNIP>
5.1 Preparation
[...]
Display changes tracking - whenever a repaint occurs in the topmost
window or in one of its descendants, create a record containing a weak
reference to the document causing the repaint, the screen coordinates of
the regions being repainted and a timestamp detailing when the repaint
occurred, and add this record to a screen-global list named "Display
Changes List". Records older than the maximum value for
input-protection's display-time can be discarded on update.

5.2 UI Event handling

Timing attacks countermeasure - check whether the "Display Change List"
contains any record younger than the input-protection's display-time
value, whose repainted regions intersect with the protected UI elements
and whose repaint-causing document is different than the protected one.
If this is true, hinting at a recent change in the way the protected UI
is displayed, with causes external to the UI itself (e.g. an overlapping
element in an ancestor document or a floating window being suddenly
moved away), assume a timing attack is happening [...]
</SNIP>

These notes are, of course, non-normative and based on my own experience
about trying to provide a similar protection *within the limitations of
a Firefox extension*, i.e. hacking around very limited APIs such as the
MozAfterRepaint event. I'm pretty sure user agent implementers, having
direct access to the OS-provided facilities and directly managing their
own display lists, reflow and so on, are in a much better position to
figure out the most efficient strategy for enforcing this feature in an
optimized way. Therefore I believe we can either poll the browser
vendors' experts (developers of the layout/gfx components, I guess) for
generally valid hints (if any), or leave the specification as it is and
let each browser vendor figure out what works best for his own specific
implementation.

Thoughts?

Many thanks!
-- G
Received on Sunday, 10 February 2013 20:06:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 10 February 2013 20:06:19 GMT