Slashdot Mirror

← Back to Stories (view on slashdot.org)

New JavaScript-Based Timing Attack Steals All Browser Source Data

Posted by samzenpus on from the protect-ya-neck dept.

Trailrunner7 writes "Security researchers have been warning about the weaknesses and issues with JavaScript and iframes for years now, but the problem goes far deeper than even many of them thought. A researcher in the U.K. has developed a new technique that uses a combination of JavaScript-based timing attacks and other tactics to read any information he wants from a targeted user's browser and sites the victim is logged into. The attack works on all of the major browsers and researchers say there's no simple fix to prevent it."

7 of 167 comments (clear)

  1. Yes, there is a simple fix by Anonymous Coward · · Score: 2, Informative

    Disable Javascript.

    1. Re:Yes, there is a simple fix by Anonymous Coward · · Score: 3, Informative

      Disable Javascript.

      You might as well stay off of the Web then.

      I tried that a couple of times and I couldn't do any banking, use my brokerage account, use any financial sites, all other content would not show correctly.

      Unfortunately, JavaScript has become a necessity for the Web.

      I can't think of any website that actually worked without it.

    2. Re:Yes, there is a simple fix by dicobalt · · Score: 5, Informative

      NoScript is your friend.

    3. Re:Yes, there is a simple fix by Anonymous Coward · · Score: 3, Informative

      Other fix: disable iframes,

    4. Re:Yes, there is a simple fix by plover · · Score: 4, Informative

      Javascript is cool for offering great content. But why would anyone allow JavaScript from non-primary-domain sources? Advertisers may want their readers to have an "rich, interactive, dynamic experience". Fine, they can offer that: on their site, after the users click over to your site from a static image.

      The rest of the linked-in javascript out there is mostly analytics, which do not benefit you as a user.

      And as a web site operator, you can be pretty sure that customers don't want to be pwned just because of a javascript brought in by your site. Should you really be linking to others that offer it?

      The GP said "he's whitelisting everything." He's doing it wrong - allow the javascript from servers in the *.domain.com for any given page, then selectively enable it from sites that add on features you care about, like disqus and vimeo. It's not a long list, and once you've whitelisted vimeo and vimeocdn for one site, you're not constantly enabling them on others.

      --
      John
    5. Re:Yes, there is a simple fix by jfengel · · Score: 3, Informative

      Frenemy. Or rather, lots of web sites are my frenemies, scooping up Javascript from dozens of web sites with no clear indication that they're aware of the interactions or trustworthiness of those sites. Slate.com is my particular nemesis here; I once counted two dozen separate sites that would have had to be enabled before the site could run as its designers intended, some of them down 4 and 5 layers of indirection.

      NoScript, who treats everybody as an enemy until told otherwise, requires an awful lot of hand-holding before permitting that. NoScript I trust (more or less) to be on my side, but lots of web site designers consider them the enemy, and that makes our mutual encounters... tense.

  2. discussed three years ago by Joining+Yet+Again · · Score: 3, Informative

    This sort of timing attack was discussed three years ago on the Mozilla blog.

    Could someone elaborate on exactly what hasn't been fixed for the Mozilla-based browsers? Dunno about the rest.