Proposal: Reverse iframe

[purplesyringa]

Abstract

Currently ZeroNet uses a wrapper for sidebar and notifications UI, and embeds site content with an iframe. This proposal fixes some issues caused by iframing by embedding ZeroNet UI into site content.

Rationale

• Add blob: scheme to Content-Security-Policy #2165, Allow Pointer Lock API in iframe #2057 - All features have to be marked unsafe by default, so supporting new ones is troublesome;
• Allow a site to bust out of IFrame #2154 - Most people don't understand what NOSANDBOX means;
• Chrome is going to block interactive content in iframes #2086 - Some interactive content in iframes might get blocked;
• Disable pull to refresh on all sites. #2058 - Pull-to-refresh is working weird with iframes;
• "Opened as child-window, stopping..." #2003 - "Opening as child window" is sometimes impossible to bypass;
• Open link in new tab really doesn't works #1736 - Opening link in a new tab is more difficult than required;
• Picture in picture mode #1707, Embedding other sites with iframes #565 - Embedding a site into a site is unsafe with an iframe;
• API for change browser's header/address bar color #1667 - Browser header style can only be set by root frame;
• Can't scroll in safari #1403 - Scrolling is impossible, iframe is most likely the reason;
• How to use localStorage? #1399, Accessing localStorage from zite #1054, Allow sites to use localresources, IndexedDB, WebSql, etc #29 - localStorage, IndexedDB, etc. are not available in sandboxed iframes;
• I make a WebGl game based on Unity3d. Then I put these files under my websites folder (clear all original files). When I open my web through ZeroNet, it just show nothing.  #1237 - Fullscreen API doesn't work;
• Error: Permission denied to access property "document" #1236, Allow zite loading outside iframe (for zite owners) #1262 - Some Vue plugins don't work;
• Sandbox prevents creating web worker #1010 - Creating Web Workers requires data: URI usage;
• Uncaught SecurityError: #469 - History management requires ZeroFrame usage.

Overview

Current architecture:

┌─────────────────────────────────────────────────────┐
│ WRAPPER (src/Ui/template/wrapper.html)              │
│ Stores secrets (e.g. wrapper key)                   │
│ ┌─────────────────────────────────────────────────┐ │
│ │ WS UPLINK                                       │ │
│ │ UiWebsocket API                                 │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ NOTIFICATIONS (<div>)                           │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ SITE NOTIFICATIONS (<div>)                  ║ │ │
│ │ ║ Unsafe content (possible XSS)               ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ WRAPPER NOTIFICATIONS (<div>)               │ │ │
│ │ │ Safe content (no leaking or spoofing)       │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ SIDEBAR (<div>)                                 │ │
│ │ Site and key management, safe                   │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ SITE DATA                                   ║ │ │
│ │ ║ Title, description, donate links, etc.      ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ └─────────────────────────────────────────────────┘ │
│ ╔═════════════════════════════════════════════════╗ │
│ ║ IFRAME SANDBOX                                  ║ │
│ ║ Unsafe content (managed by site code)           ║ │
│ ╚═════════════════════════════════════════════════╝ │
└─────────────────────────────────────────────────────┘

Safety layers are separated with double border.

No software has zero bugs. This includes security issues. There are many possible attack points here:

• Site notifications (protected by manual escaping) were exploited by me, revealing site private keys;
• Sidebar content (protected by manual escaping) wasn't exploited according to my sources, but it's still a valid point of attack;
• Iframe sandbox (protected by browser) is in theory unbreakable, but still adds unnecessary complexity;
• The final attack point is the external iframe (in case the wrapper is in an iframe itself). This was exploited by me once.

Proposed architecture;

┌─────────────────────────────────────────────────────┐
│ HTML PAGE                                           │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PREFIX (shadow DOM)                             │ │
│ │ Practically invisible to site content           │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ SITE NOTIFICATIONS (<div>)                  │ │ │
│ │ │ Unsafe content (possible XSS)               │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ WRAPPER NOTIFICATIONS (<iframe>)            ║ │ │
│ │ ║ Safe content (no leaking or spoofing)       ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ SIDEBAR (iframe)                            ║ │ │
│ │ ║ Site and key management                     ║ │ │
│ │ ║ ╔═════════════════════════════════════════╗ ║ │ │
│ │ ║ ║ GATE (iframe)                           ║ ║ │ │
│ │ ║ ║ ┌─────────────────────────────────────┐ ║ ║ │ │
│ │ ║ ║ │ WS UPLINK                           │ ║ ║ │ │
│ │ ║ ║ │ UiWebsocket API (ADMIN)             │ ║ ║ │ │
│ │ ║ ║ └─────────────────────────────────────┘ ║ ║ │ │
│ │ ║ ╚═════════════════════════════════════════╝ ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ GATE (iframe)                               ║ │ │
│ │ ║ ┌─────────────────────────────────────────┐ ║ │ │
│ │ ║ │ WS UPLINK                               │ ║ │ │
│ │ ║ │ UiWebsocket API (site)                  │ ║ │ │
│ │ ║ └─────────────────────────────────────────┘ ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ SITE DATA                                       │ │
│ │ Unsafe content (managed by site code)           │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

Sure, it might look more difficult at the first glance, but security comes with a cost.

Resulting HTML

The resulting HTML (the one that browser receives) consists of a prefix and the real site .html file.

Prefix

Prefix is a "magic" HTML code that sets up an analogue of what was a wrapper by creating a shadow DOM node. This ensures that the sidebar and notifications are shown correctly, independent of main site styles, and that it doesn't affect the site itself.

Gate

A gate is an iframe that acts like a gate between UiWebsocket and its user. The gate handler uses the referrer to check what permissions the websocket must have.

Fixed issues / added features

• Add blob: scheme to Content-Security-Policy #2165, Allow Pointer Lock API in iframe #2057 - All features are now safe;
• Allow a site to bust out of IFrame #2154 - No need for NOSANDBOX anymore;
• Chrome is going to block interactive content in iframes #2086 - The only interactive content is simple notifications (i.e. buttons);
• Disable pull to refresh on all sites. #2058 - Pull-to-refresh can now be controlled by the site;
• "Opened as child-window, stopping..." #2003 - No need to be top frame anymore;
• Open link in new tab really doesn't works #1736 - Opening in a new tab made easy;
• Picture in picture mode #1707, Embedding other sites with iframes #565 - Embedding made possible (requires a separate proposal);
• API for change browser's header/address bar color #1667 - Controlled by the site now;
• Can't scroll in safari #1403 - Scrolling is fixed;
• How to use localStorage? #1399, Accessing localStorage from zite #1054, Allow sites to use localresources, IndexedDB, WebSql, etc #29 - localStorage, IndexedDB, etc. made possible (requires a separate proposal);
• I make a WebGl game based on Unity3d. Then I put these files under my websites folder (clear all original files). When I open my web through ZeroNet, it just show nothing.  #1237 - Fullscreen API without ZeroFrame;
• Error: Permission denied to access property "document" #1236, Allow zite loading outside iframe (for zite owners) #1262 - SecurityError's fixed;
• Sandbox prevents creating web worker #1010 - Web Workers by path should work now;
• Uncaught SecurityError: #469 - History API without ZeroFrame.

Implementation status

• Prefix
• Gate
• 0 button
• Sidebar
• Debug logs
• Notifications
• Modified panel
• Old wrapper compatiblity
• Local storage
• Wrapper commands
  • innerReady [compat]
  • innerLoaded & wrapperInnerLoaded [compat]
  • wrapperNotification, wrapperConfirm, wrapperPrompt, wrapperProgress
  • wrapperSetViewport [compat]
  • wrapperSetTitle [compat]
  • wrapperReload [compat]
  • wrapperGetLocalStorage & wrapperSetLocalStorage
  • wrapperPushState, wrapperReplaceState, wrapperGetState [compat]
  • wrapperGetAjaxKey
  • wrapperOpenWindow [compat]
  • wrapperPermissionAdd
  • wrapperRequestFullscreen [compat]
  • wrapperWebNotification & wrapperCloseWebNotification [compat]

ETA: at most 1 week if no major issues are found

[purplesyringa]

@HelloZeroNet @geekless @rllola @datsec @ValdikSS @filips123 @AnthyG @anoadragon453 @github-zeronet

Waiting for review!

[purplesyringa]

I've first predicted compatiblity issues, but, surprisingly, latest Firefox and Chrome in both Incognito and classic mode work well.

[purplesyringa]

I've found a minor issue with pushState/replaceState: sites could pretend as other sites because http://127.0.0.1:43110/talk.zeronetwork.bit and http://127.0.0.1:43110/me.zeronetwork.bit are same-origin. This can, however, be fixed by overriding history.pushState.

[github-zeronet]

Nice presentation. Very hard to get your head around without something to kick the tires on. Hopefully it won't take much effort to get make the concept testable enough to validate it doesn't break apps or core ZN functionality like the side bar.

Does this impact the URL at all? Currently, the Angular app needs to set the base href so references work. Otherwise, they try to access content from the root. e.g., "/site.css".

In reality, it needs to do some parsing of the URL so you don't have to hard code the site address. There is a current issue right now with .bit domains that I haven't tested with an app because I don't have a .bit domain. I just know it is an issue today with relative referencing.

It's not clear if this prefix concept in the DOM can have an impact today. One thing that makes this challenging to predict up-front is you can't realistically know what all the third party libraries are doing in a Node-based app until you see an error. You have the core ones used to build a basic Angular, React or Vue app, then you have a bunch more you add for app functionality (such as charting). Later, we upgrade these, hoping they don't break.

What's the minimal you can do (time wise) to be able to have a branch where we can test the highest risk portions of the design, such as the new PREFIX (shadow DOM)? It doesn't have to do everything or provide new functionality. And, for testing, can still rely on NOSANDBOX, so long as it provides a way to test new scenarios. Just need to see validate it doesn't breaks apps.

[purplesyringa]

What's the minimal you can do (time wise) to be able to have a branch where we can test the highest risk portions of the design, such as the new PREFIX (shadow DOM)?

If you're asking for a high-risk PoC (meaning unsafe, i.e. can be abused by sites), it'll probably be finished today (it's 9am for me). By now, ZeroTalk, static sites, ZeroSites and ZeroHello all mostly work (except localStorage stuff and such).

[purplesyringa]

Ok, so, are there any sites using wrapperWebNotification / wrapperCloseWebNotification` at all yet? I have only one, but it's not released yet, and I don't know other people using these commands, so I don't think it makes sense to support them.

[filips123]

@imachug That commands should probably be available, but marked as deprecated and removed on next major version.

Also, how would you prevent CORS? Because all sites would be on same origin, any site would be able to access all data from other sites even without permission.

---

I think that this would be good improvement. This would also allow Progressive Web Apps with Web Manifests and Service Workers available.

Can you share your unsafe PoC when it is available? I would like to test it.

[purplesyringa]

That commands should probably be available, but marked as deprecated and removed on next major version.

Sure, but innerLoaded, wrapperPushState and wrapperReplaceState are still useful, so we can probably leave them (or remove in two major versions or something)

@HelloZeroNet

Also, how would you prevent CORS? Because all sites would be on same origin, any site would be able to access all data from other sites even without permission.

We'd compare Origin/Referer to the request URL, and if it doesn't match, we'd use X-Frame-Options and Content-Security-Policy for iframes and just 403 Forbidden for data.

Can you share your unsafe PoC when it is available? I would like to test it.

Sure, ping me tomorrow if I forget to send you a link.

[purplesyringa]

I'm currently a bit stuck with site-in-site (aka picture-in-picture) mode implementation. Good old 3 years old StackOverflow thread without an answer. Please tell me if you know how to fix that issue.

[purplesyringa]

Unfortunately I couldn't find a way to fix that issue, so I'm switching to another architecture:

┌─────────────────────────────────────────────────────┐
│ HTML PAGE                                           │
│ Secret (wrapper key [site])                         │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PREFIX (shadow DOM)                             │ │
│ │ Practically invisible to site content           │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ SITE NOTIFICATIONS (<div>)                  │ │ │
│ │ │ Unsafe content (possible XSS)               │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ WRAPPER NOTIFICATIONS (<iframe>)            ║ │ │
│ │ ║ Safe content (no leaking or spoofing)       ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ │ ╔═════════════════════════════════════════════╗ │ │
│ │ ║ SIDEBAR (iframe)                            ║ │ │
│ │ ║ Site and key management                     ║ │ │
│ │ ║ Secret (wrapper key [ADMIN])                ║ │ │
│ │ ║ ┌─────────────────────────────────────────┐ ║ │ │
│ │ ║ │ WS UPLINK                               │ ║ │ │
│ │ ║ │ UiWebsocket API (ADMIN)                 │ ║ │ │
│ │ ║ └─────────────────────────────────────────┘ ║ │ │
│ │ ╚═════════════════════════════════════════════╝ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ WS UPLINK                                   │ │ │
│ │ │ UiWebsocket API (site)                      │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ SITE DATA                                       │ │
│ │ Unsafe content (managed by site code)           │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

Basically, we're getting rid of iframe gate and using wrapper key instead. This architecture is still secure, but is more error-prone, so I should be careful enough.

[filips123]

What is different between site and wrapper notifications? Could both of them use DIV or IFRAME or even be in same element?

[purplesyringa]

Site notifications are possibly insecure and don't store sensitive information; wrapper notifications are always secure and may store sensitive information. For example, Database was rebuilt notification is a site notification, while Enter private key: [...] (you get it when you press Sign & publish) is a wrapper notification.

It's unsafe to use div for wrapper notifications. But it's possible to use iframe for site notifications, though that's overcomplicated and slow.

[purplesyringa]

@filips123 Forgot to ping you