1

To employ end-to-end encryption, I am using a small tool that encrypts contents that is then posted and stored on our servers. While there are several concerns on client based encryption, I think it is better then no encryption at all.

The tool is not delivered by the web pages itself, but stored on a trusted server and injected by Browser Extensions or Bookmarklets into the page we want to use encryption on.

For now, the pages where the tool is used are under our control too and somewhat trustworthy. However, I like to use the tool on third-party pages too, like webmail sites.

That makes me wonder about how a malicious (or even just a sloppy) website may threat the encryption, eg. by funneling the key or plain text to the server. Is there any chance of sandboxing the injected JS, or do DOM events and JS namespaces provide access that cannot be blocked in any way? How large are the chances that "good" sites will siphon the key by accident?

1

If you are executing the code in an extension, it is run in a separate context (for security reasong) and it can be made to run without the code/key being concealed to the called webpage (which is a bit different than the web page not being able to detect that you used some script within the page).

For example, GreaseMonkey is designed for doing this kind of thing (running scripts on third-party pages) and, as far as it is properly written,¹ the affected page can't read/manipulate the script.

¹ Some insecure constructs, like unsafeWindow, would allow a compromise of the script, and even for the page to run javascript with chrome privileges.

  • But the extension would have to open a new window I guess? If a form is injected into the client page DOM, it would be accessible to client JS delivered by the page, eg. keyup handlers could be added and form field values read. – dronus May 25 '15 at 11:24
  • Not necessarily. I don't know what UI is being used by your tool exactly. If you create a new "encrypt" button, the page certainly could detect that there's a new button, hide it / change its behavior, make a copy of the plaintext before it's being encrypted, or change the fields to make the extension task harder. But it wouldn't be able to recover the key (inside the extension source/config) that it is using. – Ángel May 25 '15 at 21:53
  • Ok cool... The Forms may be protected if moved to an IFRAME I guess, however if they where seperated from the client page, my own JS wouldn't be able to fill the forms on the client page either. So an browser extension has to do the transfer. That may be secure, but not bookmarklet compatible. – dronus May 29 '15 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.