Yet another chrome extension (this time an iframe injector)

Jacob David C. Cunningham
4 min readAug 28, 2022

GitHub repo (the main branch uses non-remote origin method)

Update

There is a much easier way to build this. You use the contents of the popup ui as the iframe. Then you don’t need a remote origin url. Supposedly it is secure. I am not sure on this but when I was using a remote origin url, the iframe was usually always there. But with the chrome one, it seems to get removed more… that lead me to a shadow root SO question. Initially I thought this was part of security but it’s more intended for avoiding styling collision/cleaning the DOM up (less nodes show up). Also apparently some sites will remove iframes.

I’m not an expert in Chrome extension security though so I’m using this at my own risk.

Well at any rate, here is the NANTA chrome extension injected as an iframe using the a chrome-extension://long-string iframe src.

iframe taking up 20vw of website

This is using the local network Pi API/DB. This is not what I wanted to build. This proves I can build what I want to build so… I’ll post an update later when it’s doing what I want, probably in day or two.

Initial publish

Note: the reason for the shortcode is I have not figured out how to safely send a JWT from the background script to the remote origin iframe. If you know let me know. I believe it is possible but I need to look into it more.

I’m probably not going to go with this theme, just wanted something better than white. Also I used to use subtle patterns in the past but it’s hard to pull off.

Why did I make this?

The main thing I wanted until I ran into the JWT persistence problem is I wanted something that can popup based on a scheduler. But also I wanted to take notes on things, see what I recently modified. I already have this capability with my various apps.

All note taking apps

In fact to get this project done on time I took the note taking module out of the Cross Platform App on the right (ReactJS build in ElectronJS desktop app).

Initially in my designs I did not have it be a full thing that takes up the sidebar or bottom bar.

Was supposed to be just a little widget/overlay thing like the old one see below.

This is when I found out all this injected info is exposed to the website due to window.postMessage and not using an iframe.

But then I thought about how the UI would cover things up. Would rather just always have it there.

Tech layout

It’s possible I built this wrong where I didn’t need to do what I did. But I was in a rush/wanted to build it in a day or two.

The login form/short code is held in popup ui. It does the actual API calls in background.js and the shortcode is stored in chrome.storage.

Unfortunately my data for the most part is locally hosted on my WiFi/Raspberry Pi 3 B+ server. So I will have to migrate that to the remote DB at some point.

Vulnerabilities and downsides

This is not secure with regard to the possibility of someone covering your iframe with theirs and intercepting the clicks/keystrokes. The shortcode has a long lifetime. So if someone got that, that would suck. In my implementation I did not have it copy-able to a clipboard in case that is intercepted. Hence I manually type it out. It does suck that every time you go to a new website or a website that is not a SPA, you have to login.

While the iframe is separate from the host website, it is hard to get data into it from the popup ui. I think it is possible with service workers but not sure right now, need to look into it more.

--

--