Add a warning sentence for iframe load event step

[negibokken]

The attackers can use the presence or absence of an iframe load event on
the parent's iframe to guess the URL. And if the URL contains sensitive
information like a username, the attacker can steal that information.
The related information can be available on [1].

[1] https://crbug.com/1248444

• At least two implementers are interested (and none opposed):
  • Chromium implements this behavior.
  • But none of the others
• Tests are written and can be reviewed and commented upon at:
  • Currently I'm working on the creating the WPT (https://crrev.com/c/3713162)
• Implementation bugs are filed:
  • Chrome: https://crbug.com/1248444 (fixed)
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1774951
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=241753
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A

(See WHATWG Working Mode: Changes for more details.)

---

/iframe-embed-object.html ( diff )

[domenic]

This isn't the correct fix for the issue. Adding a warning with a "should" does not actually change the processing model; instead, you need to change the processing model to track any cross-origin navigations, and either fire or not-fire the load event.

Basically, you need to port https://chromium.googlesource.com/chromium/src/+/5f8ddef5a678553c9bb1491cd5710788e6d571b3%5E%21/#F0 into spec text.

[negibokken]

@domenic Thank you for your review! Does it mean making more detailed step 5 of iframe load event steps like below? (I will clear the sentence for the spec later)

5. Fire an event named load at element according to the following steps
   • If this same-document navigation was initiated by a cross-origin iframe
     and is cross-origin to its parent, fire onload on the owner iframe.
     • warning: Normally, the owner iframe's onload fires if and only if the window's
       onload fires (i.e., when a navigation to a different document completes).
       However, a cross-origin initiator can use the presence or absence of a
       load event to detect whether the navigation was same- or cross-document,
       and can therefore try to guess the url of a cross-origin iframe. Fire the
       iframe's onload to prevent this technique.
   • If ~~~ (describe the other cases and specify fire or non-fire the load event)

If so, the cases are the following 4 cases?

• same-document navigation
  • initiated by a cross-origin iframe and cross-origin iframe to its parent -> fire (this case)
  • initiated by a same-origin iframe and same-origin iframe to its parent -> fire
• cross-document navigation
  • initiated by a cross-origin iframe and cross-origin iframe to its parent -> ? (Need to research later)
  • initiated by a same-origin iframe and same-origin iframe to its parent -> ? (Need to research later)

[domenic]

I don't really understand your suggestion. Step 5 of the iframe load event steps currently always fires the event. So you're not actually changing anything by saying that it would fire. Maybe the iframe load event steps need to be called more often, instead.

Another, probably harder part is defining "initiated by" rigorously. I can think of many different interpretations of those words so just using them without defining them isn't enough to give a specification something people could implement. But we can talk more about that when you identify where, exactly, you need to fire the load event, where it isn't being fired already.

[negibokken]

Step 5 of the iframe load event steps currently always fires the event.
Maybe the iframe load event steps need to be called more often, instead.

Ah, that's true. Sorry, I made a mistake. We may need to add the step to call fire iframe load event.

Another, probably harder part is defining "initiated by" rigorously. I can think of many different interpretations of those words so just using them without defining them isn't enough to give a specification something people could implement. But we can talk more about that when you identify where, exactly, you need to fire the load event, where it isn't being fired already.

I'll try to identify where we need to fire the load event and where it isn't being fired already.

[negibokken]

Sorry for the late update. I’m still working on this. I'm thinking about where the load event firing process should be placed for the case of ¹.

I think the following steps of the case of ¹ are as below:

1. Start from here, about updating iframe attribute.
2. Go to the To process the iframe attributes, and in case ¹, src of iframe is updated so we follow the step 2.
3. Go to The shared attribute processing steps for iframe and frame elements, and run each step through step 8.
4. Go to To navigate an iframe or frame, and run each step through step 4
5. Go to To navigate

I'm currently checking the step of To navigate. Specifically step 7, how the browsingContext work when iframe.src is replaced. And I'm thinking it matches the condition of step 7.

If anything I find, I'll post the comment, and I'll update the PR.

Footnotes

1. https://crbug.com/1248444 ↩ ↩² ↩³