Skip to content

Security

Guillem Puche edited this page Jun 11, 2022 · 19 revisions

Security of the Skia Wallet

Understand the security risks of the browsers

List of security issues

Here you've a list of common attacks:

Security issues when storing the user's mnemonic key on the browser

Here you'll discover how Skia Wallet saves the mnemonic key of the persons on the browsers. The company Auth0 is recognized for offering to the software developers an easy way to implement, adaptable authentication and authorization for their apps and websites.

They wrote an article "Secure Browser Storage: The Facts" in 2021 storing data and attacking the code with the common security issues (). The next popular storage techniques were attacked:

  • Local Storage. Read about its technical details on MDN.
  • Session Storage. Read about its technical details on MDN.
  • Cookies.
  • In memory.

Protect against security risks

Basic best practices

A long list by [OWASP][owasp-cheatsheets] of the most common attacks and how to prevent them.

Skia Wallet team has to work on the next areas:

  • [To do] Cross-Site Scripting or XSS.
  • [To do] Cross-Site Request Forgery or CSRF
  • [To do] Sanitize the inputs with the Javascript library DOMPurify (its goals here). It's a common issue on multiple type of attacks.
  • [To do] Set up the HTML headers: X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Referrer-Policy, Content-Type, Strict-Transport-Security, Content-Security-Policy, Access-Control-Allow-Origin, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy, remove X-Powered-By.
  • [To do] Use Two-Factor Authentication (2FA) and verifiers for Skia Wallet team members with access to key feature: the codebase (2FA on Github, GPG on Github)

Secondary:

Secure the storage of the mnemonic key

There's another technology that browsers supports called Web Workers that guarantee that the data remains inside a Web Worker and cannot be accessed from outside, like an attacker.

Web Workers

"Web workers enable developers to benefit from parallel programming in JavaScript. Parallel programming allows applications to run different computations at the same time." according to Auth0. "Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface." by MDN

image Image from [Auth0]

"The Worker interface spawns real OS-level threads, and mindful programmers may be concerned that concurrency can cause effects in your code if you aren't careful. However, since web workers have carefully controlled communication points with other threads, it's actually very hard to cause concurrency problems. There's no access to non-threadsafe components or the DOM. And you have to pass specific data in and out of a thread through serialized objects. So you have to work really hard to cause problems in your code. by MDN

"Web Workers can run JavaScript code in a background thread separate from the main execution thread of the JS frontend application. They communicate with the frontend application via a channel called MessageChannel. Specifically, the application can send a message to the Web Worker to perform some action via the MessageChannel. The Web Worker will perform the action and send back to the application the needed information." by Auth0. "With Web Workers, the secret is available in the isolated JavaScript code of the Web Worker. If JS frontend code needs access to the secret, the Web Worker implementation is the only one satisfying the requirement while preserving the secret confidentiality.".

Bruce Wilson says "any data that is passed via postMessage()" (the method used by Web Worker to communicate with the main thread) "is copied before it is passed, so changing the data in the main window thread does not result in changes to the data in the worker thread. This provides inherent protection from conflicting concurrent changes to data that’s passed between main thread and worker thread".

Benefits of Web Workers over the previous storing web techniques:

  • Supported by all major mobile and desktop browsers. Can I Use shows the compatibility table and supported by ~96% of browser's user in the world.
  • It prevents third-party code from accessing mnemonic key and HTTP-request interceptions. Since third-party codes run on the main thread, they cannot intercept requests initiated by the web workers. Yes, when we store access tokens in web workers, API requests needing those access tokens should also be initiated from the web workers.

Some concerns found on the documentation and Internet:

  • MDN "Workers are considered to have their own execution context, distinct from the document that created them. For this reason they are, in general, not governed by the content security policy of the document (or parent worker) that created them. [...] To specify a content security policy for the worker, set a Content-Security-Policy response header for the request which delivered the worker script itself."
  • HTML5 Security Cheat Sheet by OWASP
    • Web Workers are allowed to use XMLHttpRequest object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
    • While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
    • Validate messages exchanged with a Web Worker. Do not try to exchange snippets of JavaScript for evaluation e.g. via eval() as that could introduce a DOM Based XSS vulnerability.
  • Questions about security risks on Stack Overflow
    • Answer: "the MessagePort interface is 100% client-side. A compromised machine could have a malicious script read directly in its RAM and derive the sensitive information from there, but once again, if they can do it... they can certainly access that token by means a lot simpler.".
  • Mozilla Security Review in 2008:
    • Workers execute in a tightly controlled sandbox.
    • No access to Components or other global JS components.
    • Only basic JS (Math, Date, etc.), timeouts, XHR, and importScripts.
    • No pref dependencies yet, maybe will provide one to customize the number of OS threads allowed.
    • Script loading is subject to the same restrictions as on the main thread (content policies, same origin restrictions, etc.).
    • XHR uses the same code as the main thread.

Developer tools for security analyzes

Skia Wallet uses in the development workflow:

  • Snyk to "find and fix security vulnerabilities in code and dependencies".

References

Clone this wiki locally