Security audit of our leta.mullvad.net search service

Assured AB were contracted to perform a security assessment of our new Leta search service between 2023-03-27 and 2023-03-31.

Today we announce our new Leta search service, available at leta.mullvad.net. This service is available to valid Mullvad VPN customers, with the ability to use it as the default search engine in supported browsers.

Leta is also an option in Mullvad Browser for use as a default search engine. Further information about how Leta functions, how it can be used, and limitations are available on the Leta FAQ.

The Terms of Service page explains how the service functions, and what the business model is.

Quoting the report:

"Assured was tasked with conducting a penetration test on Mullvad Leta and to assess the web application with regards to security and privacy. Overall, Mullvad Leta is well contained with a small attack surface and good measures have been implemented to strengthen privacy as well as security."

Read the full audit report on Assured’s website.

Reports notes and comments

3.1.1 (Low) Content Security Policy (CSP) missing

Assured recommended configuring a Content Security Policy (CSP) for all documents, adhering to the principle of least privilege.

Mullvad: We have added a CSP.

3.1.2 (Low) Partial logging of unique user ID

Assured recommended disabling user identifiable log entries entirely in production, and removing the debug calls as soon as the product is ready for release. This is a preemptive measure to prevent accidental exposure in the future.

Mullvad: We removed all logging of user IDs.

3.1.3 (Note) HTTP Strict Transport Security Header Missing

Assured recommended ensuring that the Strict-Transport-Security response header is properly set as it is good practice to serve this header to inform clients that they should only connect to the server over TLS (HTTPS).

Mullvad: We have modified the configuration to ensure this is set for all assets served by our web server (however the service is only responding over HTTPS)

3.2.1 (Low) Potential Cross-Site Scripting (XSS) via Google results

Assured recommended using only the plain-text description from the Google results, rather than trusting HTML from an external party. A well-crafted CSP (see Finding 3.1.1) could also mitigate this issue to some extent.

Mullvad: We no longer use the HTML snippets from Google, just plain text.

3.3.1 Note Search terms never removed from cache

Assured recommended setting a hard expiration time for new entries, and clearing entries from the database upon expiration. The built-in expiration mechanism of Redis is already used to purge each user’s quota entries at the end of each day, and should be suitable and robust for this purpose as well. If the presence of search terms (e.g. personally identifiable terms) is considered sensitive, we also recommend allowing users to exempt their searches from caching.

Mullvad: We have updated so all entries are expired automatically after 30 days plus the fact that search queries are hashed

3.4.1 Note Plaintext search queries in cache database

Assured recommended hashing search terms before insertion / lookup in the cache database. Since search term cache lookups are only performed with exact matching, this should not affect functionality.

Mullvad: We are now hashing (and salting) the search terms before they are added to Redis