Re: Security implications of network timing

The performance timing information in the new API has implications fat
beyond Felton's classic work on browser or shared cache snooping. I
see this facilitating some major advances in the JavaScript port
scanning that myself, Robert Hanson, and Jeremiah Grossman explored in
2006. We had to use crude setTimeout's/image.onerror/image.onload to
exfiltrate data about Intranet systems.The finer-grain information
about DNS look ups and TCP connections will make this much worse.

http://www.slideshare.net/amiable_indian/javascript-malware-spi-dynamics

The perf guy in me love it. The whitehat in me hates it.

--
Billy Hoffman
Founder and CEO,
Zoompf - Making Websites Faster
Phone: +1 (404) 509-0051
Cell: +1 (404) 414-2000
Get your free web performance assessment today at zoompf.com/free



On Tue, Oct 4, 2011 at 7:54 AM, Tony Gentilcore <tonyg@chromium.org> wrote:
> Hi Security Gurus,
>
> The Resource Timing[1] specification has just entered last call phase. It
> provides network timing details for each subresource loaded by a page,
> to wit, the HTTP redirect, DNS, TCP connect, HTTP request and HTTP
> response phases.
>
> We suspected that exposing this additional detail could improve the
> effectiveness of timing attacks like those described by Felten and
> Schneider[2]. So we have speculatively guarded these times with a
> same-origin restriction.
>
> But even with the same-origin restriction, other folks have
> speculated[3] these times could be used to improve the effectiveness
> of statistical fingerprinting. At the same time, developers who want
> to use the feature are concerned that the same-origin restriction is
> too crippling for their use-cases.
>
> So, we'd like to take a step back and develop a list of novel attacks
> that could be enabled by exposing network timing. Then we can put in
> the proper set of restrictions to prevent them. The problem is that
> none of the web performance working group participants have expertise
> in security or privacy.
>
> Are there folks in this group who would be willing to help us generate a list
> of novel attacks that could be exposed by network timing?
>
> Thank you,
> Web Performance Working Group
>
> [1] http://w3c-test.org/webperf/specs/ResourceTiming/
> [2] http://sip.cs.princeton.edu/pub/webtiming.pdf
> [3] http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
>
>

Received on Wednesday, 5 October 2011 07:42:13 UTC