security considerations

[denuoweb]

I like the extension! My phone broke and I need better than a 4 day temporary code. Here are some security considerations. You mentioned you are releasing a new version?

Concern	Explanation	Mitigation
Unverified Sender in chrome.runtime.onMessage	The message listener does not inspect sender.id or sender.tab.url, so any code running in a context that can call chrome.runtime.sendMessage (e.g., any permitted content script) could invoke privileged functions such as buildRequest or approveTransaction.	At the top of the listener, check if (sender.id !== chrome.runtime.id) return false;. For "onLoginPage", additionally check sender.tab.url matches exactly the Duo login page domain.
Private Keys in chrome.storage.sync	Private RSA keys (privateRaw) are stored in cleartext in chrome.storage.sync. This means they are synchronized (in plaintext) to Google’s servers, and if the user’s Google account is compromised, so are the keys.	Switch to chrome.storage.local for all private key material. Optionally encrypt the private key under a user‑provided passphrase before storing.
Potential XSS via innerHTML on Untrusted API Data	The traverse() function directly inserts Duo API transaction attributes into the DOM via p.innerHTML = … or successDetails.innerHTML = …. If Duo’s server ever returned malicious HTML or if an attacker spoofed the API, this could result in a cross‑site scripting attack.	Escape all inserted strings (e.g., via a helper like escapeHtml) or use textContent and create <b> elements manually to avoid interpreting any embedded HTML.
Malicious Import Overwriting host / privateRaw / publicRaw	When the user imports a base64‑encoded JSON, they (or an attacker) could inject a device whose host is not Duo’s official API. The extension might then sign requests to a malicious server (which could return arbitrary data) or leak device keys.	During import, validate that every host value matches a strict Duo API domain pattern (e.g., /^api\-\d+\.duosecurity\.com$/). Perform a test GET /push/v2/device/transactions immediately after import; if it fails, reject the import.
Excessive storage.sync Quota Usage	Storing large Base64‑encoded key blobs in chrome.storage.sync can exceed Chrome’s per‑item or total sync quota, resulting in failed writes or data loss.	Store only minimal metadata (device IDs, click levels, names) in storage.sync. Keep the actual key blobs in storage.local, which has a much higher per‑item quota and does not synchronize to the cloud by default.
Insufficient Validation of Activation Code	The code only checks the length of the two segments of the activation code. If a user accidentally enters a code with the correct length but an invalid hostname, atob(code[1]) might produce a host that is not Duo’s. The extension will then attempt to POST the public key to a possibly malicious host.	Validate that host strictly matches Duo’s expected hostname pattern (e.g., ends with .duosecurity.com). Optionally perform a HEAD or simple GET /push/v2/status to confirm it is indeed Duo before proceeding.
Error Details Potentially Leaking Internal State	Some catch blocks rethrow errors that embed raw exception messages (Failed to fetch <url>: <networkErr>). Those messages might be shown directly to the user in the popup.	Wrap or sanitize error messages before displaying them. For internal logging, use console.error, but for UI feedback, display only user‑friendly text (e.g., “Network error, please try again later”).

[FreshSupaSulley]

Thanks! Yep, I'm preparing for a new version release. Of your security concerns, here's the suggested mitigations I plan to bundle with the release:

• Unverified Sender in chrome.runtime.onMessage
• Private Keys in chrome.storage.sync

This is laid out in the README. TLDR: turn off syncing.

• Potential XSS via innerHTML on Untrusted API Data

Can't see how this could happen due to certificate signing? But sure?

• Malicious Import Overwriting host / privateRaw / publicRaw

Non-issue. There needs to be explicit permission granted to access URLs (see host permissions)

• Excessive storage.sync Quota Usage

See #19. Storage will be distributed better in newest version.

• Insufficient Validation of Activation Code

Same reason as Malicious Import Overwriting host / privateRaw / publicRaw

• Error Details Potentially Leaking Internal State

I don't think leaking the internal state shows anything more sensitive beyond the failing request, which I'd actually prefer to still show to the user.

[FreshSupaSulley]

My mitigations:

Unverified Sender in chrome.runtime.onMessage:

Asserting (sender.id !== chrome.runtime.id) in service worker. Checking sender.tab.url is unnecessary thanks to basic extension security.

Potential XSS via innerHTML on Untrusted API Data

Although probably unnecessary, now we escape properties and values returned from the Duo API.

I edited the response above for justifications on how I made my decisions. Correct me if I'm wrong!

[denuoweb]

You took care of the important issues. Being a security app, being as secure as possible is best practice. We want to mitigate even tiny windows of opportunity. Bad actors are probably looking hard at this extension for weaknesses to exploit.

Is there a reason you want to continue using chrome.sync instead of chrome.local? What is the benefit?

[FreshSupaSulley]

You took care of the important issues. Being a security app, being as secure as possible is best practice. We want to mitigate even tiny windows of opportunity. Bad actors are probably looking hard at this extension for weaknesses to exploit.

I guess I'm always taking the environment this is running in into consideration when making security decisions. Host permissions protects against bad URLs, extensions run in isolated worlds, etc. But to your point, being incredibly strict can't hurt. There could always be undiscovered bugs, so we might as well add these potentially non-essential fixes even if the browser's security is supposed to protect the extension. Doesn't seem too difficult anyways (:

Is there a reason you want to continue using chrome.sync instead of chrome.local? What is the benefit?

The benefit is convenience. People that use multiple PC's (like me) can add a device to one browser and login to their account on a different computer's browser that they're logged into (and synced) without having to manually copy the data over themselves. Now you can login to through Duo on a work PC and a home PC without setting it up twice. The drawback is obviously relying on your Google Account to store private keys. Anyone that gets into your account and turns on syncing now has your data. However, you have to get into the account in the first place. Lots of people are satisfied with Google's security practices as many users have MFA enabled and use strong passwords. And btw, deciding whether to use chrome.sync or chrome.local is up to the user. You can disable syncing extensions if you want data to remain local.

I might add a link to a doc in this repo to the security section in the README on the disclaimer screen, warning the user about syncing, the inherit risks of storing your data in an extension, etc. You're more than welcome to add to it if you'd like.

[FreshSupaSulley]

What should absolutely be a future feature is the ability to verify if the Duo request came from the browser. The default setting is one-click, meaning if you happen to click it when there's only one push request active, and it happens to be malicious, your account is now compromised. Even more dangerous with zero-clicks, as there's no checking if that request is actually you - there just needs to be only one.

Any idea on how to programatically check if the request is coming from your browser (verify it's you)? I want to avoid making an API call everytime you try to approve a push request to get and compare the IP address to the one returned from the Duo API, so I'm curious if there's another way...

[denuoweb]

I sign in on my phone browser and verify myself using this desktop browser extension. Would my ability to do this be prevented with your feature?

[FreshSupaSulley]

No, you would just need to review the push request details (it would basically be a 2 click login).

It could be optional. There could be an option in settings to warn / force 2 click logins if the IP addresses don't match or it otherwise looks suspicious.