1

I'm working on a Chrome extension where I login by the popup UI so it's not part of the DOM of whatever website I'm on. Then I intend to inject an iFrame so that the iFrame body can't be read. I don't want a UI that's inside the popup since it has to be attached near the CE icon on the top-right.

So I can securely login (background script), I have my JWT, I need to get it into the iFrame, who's URL will be known eg. src attribute. I can't think of a way to safely get the JWT into the iFrame context. Since the iFrame will be created/destroyed and the login should last for several sessions not just every time the iFrame is injected.

Is there anyway around this?

I have also read about iFrames being faked/stuff covering them. The application is just for me/note taking.

update

If I can keep a bridge open between the background script and iFrame maybe I can keep the JWT in the bg script and do the API calls through that... not sure. I know postMessage is not secure.

another update

I'm going to go with a short code, you do the big login in drop down, then it spits out a short code, it's not copied to clipboard, then you hop to the injected iFrame and use that inside. It would have a lifetime.

update again

service worker/web_accessible_resources could be the way to do it

and another

I probably have a fundamental misunderstanding... but at this time, both remote origin url iframe and chrome injected iframe eg. src is chrome-extension://long-string... the contents inside can be found in the developer tools console. Using document.get or window.find('string')... so idk. You are not safe (Aviator line).

I need to do more testing, where I have JS being executed by the webpage not dev tools.

Interesting can change environments in devtools.

Anyway testing a page, the JS that runs in the page can't find either iFrame content. I think I can sleep with this in mind. This is just for me anyway.

I think I'm mixing up the purpose of shadow dom (kinda sandboxed but for styling) vs. iframe "completely" sandboxed/separate document. Shadow dom seems to be for making sure the non-remote src iframe isn't removed from a page.

  • 1
    Use the **internal** extension [messaging](https://developer.chrome.com/extensions/messaging) or [storage](https://developer.chrome.com/extensions/storage). – wOxxOm Aug 28 '22 at 06:26
  • Thanks for the ideas. I should note the iframe would be an https url... hopefully that's not a problem. I think it can still be in context/related to the extension that made it. – Jacob David C. Cunningham Aug 28 '22 at 14:40
  • JS environment of content scripts is isolated from the web page. – wOxxOm Aug 28 '22 at 17:19
  • Okay, I need to read up on that more, to make it all work, main goal being don't expose iframe content to website and don't expose JWT to website, but keep logged in with lifetime of JWT by keeping it in the context of popup.html/bg script/iframe. – Jacob David C. Cunningham Aug 28 '22 at 17:43
  • I actually saw some of your old responses. I think this is going to work. I built it the hard/dumb way with remote origin. But you can also use the popup html as the iframe. And if you wrap it in a sahdow, it seems like it's isolated from the webpage that it was injected in. I need to find more evidence of this. – Jacob David C. Cunningham Aug 29 '22 at 03:56
  • ...and it is [not secure](https://blog.ankursundara.com/shadow-dom/) hmm. – Jacob David C. Cunningham Aug 29 '22 at 04:13
  • ...however [here](https://stackoverflow.com/questions/61446288/chrome-extension-safely-communicate-from-executed-script-to-background-script) you say if it's using getUrl then the iframe is secure... that gives me hope -- last edit ,window.find is able to find my injected content in console hmm – Jacob David C. Cunningham Aug 29 '22 at 04:20

0 Answers0