Join GitHub today
Out-of-beta security review #601
added a commit
Oct 19, 2018
pushed a commit
Oct 23, 2018
added a commit
Oct 24, 2018
New client security review
We planned to do an extensive security review of the new beta client before releasing it and realized that from 18.10.2018 until 24.10.2018.
The following is a summary of what we reviewed, tested and what we found as part of the security review. We did not find any severe issue. We did find a few bugs that could influence client security if a layer of protection (e.g. CSP) would not be working for some reason.
This security review focused on the client security (not server) and targeted the following topics:
All of the tests described in the following sections have been executed in local test environments and did not influence the production systems. We worked in pairs during the security review.
Injections and XSS
There are two mechanisms that protect Tutanota users from code injections and XSS. These are Content Security Policy (CSP) and sanitizing. We tried to exploit each of them separately. We also tried to identify problems with raw HTML insertions and insecure evaluations of code.
Content Security Policy
We completely disabled sanitizing in order for being able to test the effectiveness of the CSP. Afterwards, we sent mails that contained exploits to our test accounts and verified that CSP chimed in and that non of the exploits work. We ran these tests in our iOS and Android apps and on the web client as the CSP is enabled for the apps via a meta tag while we use headers for the web app.
In order to test the sanitizing, we completely disabled the CSP, opened exploit mails and posted arbitrary HTML to the editors and verified that the sanitizer doesn't permit injections.
We also reviewed the code snippets where the sanitizer settings.
Raw HTML DOM insertions
We manually reviewed code and verified that the sanitizer is used where user content is inserted into the dom. This mainly includes all usages of
Email privacy tester
We ran the run email privacy tester on Chromium, Firefox, Safari and Edge.
We reviewed the source code for potential evaluations of insecure code (
Exposure of sensitive data
We verified that all encryption primitives have been implemented and used correctly.
We checked for the web client, the Android and iOS apps, that MACs are enabled for all data encryption operations and that manipulated MACs lead to the expected error messages (e.g. for a mail body).
Random IVs are used
We reviewed all code parts where IVs are generated and made sure, that the IVs for data encryption are random.
Session key handling for encrypted mails
We tested, if a case exists where we send session keys for encrypted mails to the server. These tests where executed for the following cases:
PRNG and entropy
We tested that enough entropy is collected and used before generating keys on web client and in apps. We also verified that entropy is collected continously.
We made sure that JSBN (RSA implementation) and all native key generation implementations are seeded from our PRNG implementation.
Secure local data storage
We verified that the indexeddb database name has no connection to the users mail address and that all search words and suggestions on the index are encrypted.
We also examined different kinds of attacks on the local database.
In addition to that, we also checked how the push identifier and the local config are stored and if they contain sensitive data.
Crypto compatibility tests
We checked that all compatibility tests for cryptographic primitives run successfully on all platforms.
We identified security headers as the most important feature that needs to be configured correctly in order to increase security (especially CSP).
We also checked for auth data leaks and leaks to the browsing history.
We reviewed CORS, HSTS, CSP headers manually (CORS, CSP) and ran the following tests:
Auth data leaks
We checked that passwords or other auth data are not stored in dom or browser cache and focused on the following areas:
We checked that no user data is stored in the browsing history.
We created an overview diagram about all interfaces that the web and all native apps use and reviewed all data conversions on those component borders.
Components with known vulnerabilities
We verified that there are no security issues in used libraries (
In addition to that, we did an extensive code review for all runtime dependencies of Tutanota. We focused especially on eval and new Function() calls, rest requests using XMLHttpRequest and fetch, DOM manipulations using document.createElement, insertAdjacentHTML nor innerHTML.
These were our findings from reviewing all dependencies: