On 1/9/15 7:14 AM, Anne van Kesteren wrote:
Both parent and input need to be cloned in this case. While parent's
callback runs it changes the type of input, at which point input's
callback runs. So, yes.

OK. So just to be clear, the type will be set before the input's cloning callback runs, yes?

It's a bit unclear to me why "When an input element's type attribute
changes state" does not sanitize this value

When the type changes it sanitizes the value of the input. Though I see nothing in the spec to indicate this; I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27791

But in this case the value is not set yet when the type changes. Then the cloning callback runs and sets the value on the now-file-type input, no?

In particular, the current spec for <input> says:

  The cloning steps for input elements must propagate the value, dirty
  value flag, checkedness, and dirty checkedness flag from the node
  being cloned to the copy.

This is not conditional on the input type in any way, unlike .value sets. So if we allow the type to change before the cloning steps run, the cloning steps need to be adjusted to deal with this situation.

And in particular, all cloning steps need to be carefully audited to deal with issues like this.

or how cloning it makes it a security concern.

Because if the cloning steps in HTML are left as-is but run after script can change the type, then you can create a file input with an arbitrary value filled in. Which is a security concern.


Reply via email to