https://codereview.appspot.com/9667044/diff/1/src/com/google/caja/plugin/domado.js
File src/com/google/caja/plugin/domado.js (right):
https://codereview.appspot.com/9667044/diff/1/src/com/google/caja/plugin/domado.js#newcode5755
src/com/google/caja/plugin/domado.js:5755: // TODO(kpreid): should be
internal .documentElement getter only
On 2013/05/22 20:44:12, ihab.awad wrote:
Not sure what the TODO means....
// guest code
Object.defineProperty(document, 'documentElement', {value:
someOtherElement});
document.body; // reads above prop, not Domado's definition of
documentElement
This is a non-conformance and a way for the guest to shoot itself in the
foot, but not a strong security problem. There are other cases where
something like this might be actually relevant to Domado invariants, so
I think it's worth eventually having a general solution to the problem
and this is a place where it would be used.
https://codereview.appspot.com/9667044/diff/1/src/com/google/caja/plugin/domado.js#newcode5756
src/com/google/caja/plugin/domado.js:5756: var htmlEl =
this.documentElement;
On 2013/05/22 20:44:12, ihab.awad wrote:
I assume this is working on the *tame* side, so htmlEl is in general
(pending
the "take over the frame" refactoring) a <caja-v-html>, and its child
with
nodeName of BODY is a <caja-v-body>, right?
Yes, this is deliberately written to be strictly in terms of the tame
view of the DOM, so that it is irrelevant to integrity-of-the-sandbox
analysis.
Hm. It hadn't crossed my mind that such things as .nextSibling are also
potentially overridable by the guest, so in principle there should be a
lot more TODOs like the one above. (Still no security issue, by the
previous paragraph's argument.)
https://codereview.appspot.com/9667044/
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
