1

Consider a cryptographic web application that relies on hosted JavaScript. This JavaScript could be manipulated server-side by a bad actor, defeating any cryptographic tasks. Namely:

  1. private keys could be sent back to the server

  2. cleartext could be sent back to the server

The Web Cryptography API addresses some of these concerns by providing cryptographic primitives without exposing keys, addressing item 1.

It looks to me like bad JavaScript could still transmit cleartext back to the server. Am I missing something, or is this issue not addressed by Web Crypto?

Anders
  • 64,406
  • 24
  • 178
  • 215
lofidevops
  • 3,550
  • 6
  • 23
  • 32
  • you can prevent the JS from being manipulated server-side using SRI attribs and a CSP. – dandavis Aug 30 '18 at 18:51
  • dandavis, If the bad actor has access to the server that serves the root document, then what's to stop him from simply changing the reference to the javascript file in the `script` tag to now point to one that he's compromised, and updating the SRI hash? – mti2935 Feb 09 '20 at 20:36

1 Answers1

3

It doesn't. That's excusable, because it cannot.

The server sends the code. If the server is hostile or compromised, then the code sent by the server may be malicious. It doesn't matter what the API does: the code sent by the server can avoid using it, or otherwise send all the data in cleartext to the server.

The reason to have cryptographic primitives that don't expose keys is mostly to protect against a server that's trustworthy, but that delivers code that can be partially exploited. If the attacker can arrange to run arbitrary Javascript code in your browser, you've lost. If the attacker is restricted in certain ways, e.g. if can only extract certain information or can only infect certain pages, then adding protections such as non-exposed keys makes it harder for the attacker to obtain the data they want.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179