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?

2
  • you can prevent the JS from being manipulated server-side using SRI attribs and a CSP.
    – dandavis
    Aug 30, 2018 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 9, 2020 at 20:36

1 Answer 1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .