Open GoogleCodeExporter opened 9 years ago
todo:
* verify that input elements cannot be escalated into a security breach.
* see if suffixing input @name is viable.
* if suffixing isn't viable, see if domita can be hardened against input @name
confusion.
Original comment by felix8a
on 22 Jun 2011 at 1:28
standards notes:
these magic name behaviors are specified by the WebIDL attributes
[Replaceable]
[ReplaceableNamedProperties]
[OverrideBuiltins]
which are defined here
http://dev.w3.org/2006/webapi/WebIDL/#es-extended-attributes
and used in various places in the html5 spec.
also, I seem to remember IE6 has somewhat different behavior, but I haven't
checked that yet.
Original comment by felix8a
on 22 Jun 2011 at 1:40
fwiw, my oldish project to catch such occurences might be of interest —
http://kangax.github.com/domlint/
Original comment by kan...@gmail.com
on 22 Jun 2011 at 3:22
This is less a threat now that Domado is cajoled, right?
Original comment by metaw...@gmail.com
on 3 Aug 2012 at 9:26
No; the issue is cases where names in the DOM get turned into properties of
objects by the browser. The only aspect of Caja that affects this is what DOM
trees a gadget is allowed to cause to exist.
Original comment by kpreid@google.com
on 3 Aug 2012 at 9:39
If innocent code in a host page is doing feature detection, guest code might be
able to confuse it by naming a form or an input. On the other hand, guest code
can't assign to any properties of the node except whitelisted ones; creating a
log method on a node named "console" would put the method in a weak map, not on
the node itself, so innocent calls to console.log() would still fail. And if
there's a debugger running, its console would mask the form in the global scope.
Original comment by metaw...@gmail.com
on 31 Aug 2012 at 9:57
Original comment by kpreid@google.com
on 11 Nov 2013 at 6:31
Original issue reported on code.google.com by
felix8a
on 22 Jun 2011 at 1:26