2

I read about Spectre (CVE-2017-5753) but it is unclear how it actually affect the everyday programmer? I read a couple articles but I am still not sure if it may break any of my old project or existing code. It would be great to know what I should look out for when trying to adapt to the changes Spectre introduced about how browsers processes JavaScript.

Hambalkó Bence
  • 125
  • 11
  • As far as I understand, Spectre allows a program A that runs on a machine M to read private data of program B running on the same machine M. Which means your JavaScript code isn't affected in any way. –  Jan 11 '18 at 13:01
  • I found so far only this: https://www.chromium.org/Home/chromium-security/ssca but I can't fully understand the consequences. – Hambalkó Bence Jan 11 '18 at 13:03
  • 1
    I'd say you're supposed to follow the advice on the page; if you don't fully understand the advice, there's no need to follow it (because you aren't using the affected features anyway). –  Jan 11 '18 at 13:05
  • The real fixes for spectre will have to be (are being) written at the kernel level -- javascript code doesn't have any direct way to tackle this problem. The recommendations you've found would make it more difficult to exploit this vulnerability, and most are good practice in any case, but they're not permanent fixes. – Daniel Beck Jan 11 '18 at 13:14
  • The thing that changes for *your* js code is that it will on less clients, as more security-aware users have now another good reason to completely disable javascript in their browsers. – Bergi Jan 11 '18 at 13:18
  • 1
    maybe you would get more info in Security.SE? https://security.stackexchange.com/search?q=spectre+javascript – Suraj Rao Jan 11 '18 at 13:22
  • This question is vague and too broad. Not sure why it's getting upvoted that much. Nobody's going to know what "Spectre" is referring to in a year, not to mention remember what its implications were. – Cerbrus Jan 11 '18 at 13:24

1 Answers1

3

After researching I found some recommendations here.

Best practices summed briefly:

  • Prevent cookies from being loaded into the memory of the renderer using options present in the Set-Cookie header.

  • Make it hard to guess and access the URL of pages that contain sensitive information. If the URL is known to the attacker, the renderer might be forced to load it into its memory. Same-origin policies alone do not protect against these attacks.

  • Ensure that all responses are returned with the correct MIME type, and that the content type is marked as nosniff. This will prevent the browser from reinterpreting the contents of the response, and can prevent it from being loaded into the memory of the renderer when a malicious site tries to load it in certain ways.

References:

Ákos Köte
  • 54
  • 4
  • 1
    The first article seems to be most relevant, [can you please sum it up in your answer](https://meta.stackexchange.com/q/8231)? What happened to `SharedArrayBuffer` and `performance.now` is imo irrelevant as a "recommendation for JS developers". – Bergi Jan 11 '18 at 13:36