3

I should note, I'm not a chrome extension expert. However, I'm looking for some advice or high-level solution to a security concern I have with my chrome extension. I've searched quite a bit but can't seem to find a concrete answer.

The situation

I have a chrome extension that needs to have the user login to our backend server.

However, it was decided for design reasons that the default chrome popup balloon was undesirable. Thus I've used a modal dialog and jquery to make a styled popup that is injected with content scripts.

Hence, the popup is injected into the DOM o the page you are visiting.

The Problem

Everything works, however now that I need to implement login functionality I've noticed a vulnerability:
If the site we've injected our popup into knows the password fields ID they could run a script to continuously monitor the password and username field and store that data. Call me paranoid, but I see it as a risk. In fact, I wrote a mockup attack site that can correctly pull the user and password when entered into the given fields.

My devised solution

I took a look at some other chrome extensions, like Buffer, and noticed what they do is load their popup from their website and, instead, embed an iFrame which contains the popup in it. The popup would interact with the server inside the iframe.

My understanding is iframes are subject to same-origin scripting policies as other websites, but I may be mistaken.

As such, would do the same thing be secure?

TLDR

To simplify, if I embedded a https login form from our server into a given DOM, via a chrome extension, are there security concerns to password sniffing?

If this is not the best way to deal with chrome extension logins, do you have suggestions on what is? Perhaps there is a way to declare text fields that javascript can simply not interact with? Not too sure!

Thank you so much for your time! I will happily clarify anything required.

Manikandan C
  • 668
  • 1
  • 9
  • 22
Weaver
  • 619
  • 1
  • 4
  • 12

1 Answers1

2

The Same origin policy does indeed protect the contents of the iframe from the main page.

However. There's no way for the user to know whether the iframe in the page belongs to your extension or not. A rogue page could copy your design and impersonate your extension, and ultimately steal the credentials.

The only secure way to get the user to input credentials is through a separate window, popup or tab.
Chrome offers an API to open a window with desired properties, which should be sufficiently flexible to meet your design requirements. See this example, which is also about getting a credentials in a popup window: https://stackoverflow.com/a/10341102/938089

Community
  • 1
  • 1
Rob W
  • 341,306
  • 83
  • 791
  • 678
  • Thanks for all the information, Rob! It's quite helpful. The provided example is great as well. – Weaver Jun 27 '13 at 16:27
  • 1
    @Weaver I have just edited the example to use the latest extension APIs. Check out the revised example if you were reading the previous version. The previous version will cease to work next year because it was using [manifest version 1](http://developer.chrome.com/extensions/manifestVersion.html#manifest-v1-support-schedule). – Rob W Jun 27 '13 at 16:29
  • You mention the potential for the popup to be mimicked by another page. If our login flow within the extension requires the user to click on the extension and then a button within, how would a website copy that? They don’t have the ability to listen to that extension icon button click, right? – Kyle Holmberg Jan 29 '20 at 10:28
  • 1
    @KyleHolmberg Do you mean the [browser action button](https://developer.chrome.com/extensions/browserAction)? Since that button is in the trusted browser UI area, it cannot be spoofed. The answer is about UI in the page's content area, which can easily be manipulated by the web page. – Rob W Feb 04 '20 at 23:58