Changing the subject, since discussion has shifted to another piece of
duct tape. But hey, worse-is-better or something.
Boris Zbarsky wrote:
Robert Sayre wrote:
I guess it depends on what you meant by "doomed to failure."
...
My problem is how to make sure that such a solution remains safe when
some other part of the same organization writes some script that
rearranges things on the page a bit.
I am not sure what the threat is. If the page source is
<strip_dangerous>
<b>
<a onclick='javascript:doEvil()'>a</a>
</b>
</strip_dangerous>
the onclick attribute will not be in the DOM. The content sink will
never even see it. If the threat is that a script could insert such an
attribute, then I don't see how my proposal makes that problem worse. If
the threat is a script that re-authors the page on the server, then I
agree that my proposal does not solve that problem.
Gervase Markham wrote:
[1] the definition of "dangerous stuff",
[2] the difficulty of making sure the content doesn't close the
> livejournal-comment tag,
[3] the difficulty of making sure the content inside doesn't affect the
content outside (e.g. by overlaying it using CSS absolute positioning).
#2 seems solvable, though the solutions might not be pretty. #1 and #3
seem like social barriers to completion. I guess the answer is to cut
features until #3 is no longer a problem, reassure upset feature
advocates that strip_dangerous can be made more permissive by
identifying sanitization policies in an attribute, but place the
definition of any such policies out of scope for the initial effort.
I still suspect this is worth the effort, but everyone else seems to be
trying to talk me out of it :)
-Rob
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
