Vulnerable S2b

Trusted partner — base-domain check

Same page, one line changed. Instead of comparing the whole origin, the portal asks only whether the trusted domain appears somewhere in it.

window.addEventListener("message", function(event) {
  if (event.origin !== "https://trusted-domain.com") {
    console.log("Invalid origin!");
    return;
  }
  document.getElementById("output").innerHTML = event.data;
});

window.addEventListener("message", function(event) {
  // only checks for the base domain, without properly handling subdomains
  if (event.origin.indexOf("trusted-domain.pmlab.amir.baby") === -1) {
    console.log("Invalid origin!");
    return;
  }
  document.getElementById("output").innerHTML = event.data;
});

Why this is exploitable. https://attacker.trusted-domain.pmlab.amir.baby is a subdomain of the trusted domain, and it contains the string trusted-domain.pmlab.amir.baby, so the check passes and the payload reaches the sink.
The writeup's note is right about the class of bug: any validator that reasons about the base domain instead of the full origin will treat attacker.trusted-domain.com as trusted. The practical attack is finding XSS on any subdomain of the trusted domain — then your page runs at a trusted-looking origin.

← Compare: /s2-exact (strict) Attacker page →

Widget output

Raw payload received

—

Embedded partner widget

Served from https://trusted-domain.pmlab.amir.baby.

Trusted partner — base-domain check

Widget output

Raw payload received

Embedded partner widget

Message flow