T Rowley mentioned that this is part of the SVG attack surface and could do with a security review: * hookup of svg events - nsSVGSVGElement.cpp http://lxr.mozilla.org/mozilla/source/content/svg/content/src/nsSVGSVGElement.cpp
jwatt tested some stuff: making sure you can't make SVG events bubble out of iframes, making sure you can't inject synthesized events into other documents, etc. He hasn't found any problems there. jwatt said he was careful in his use of the isTrusted flag, and jst super-reviewed the code, so that aspect should be good. Shaver, did you have other concerns about SVG events, or can this be marked as fixed?
Assignee: general → jonathan.watt
The bug for implementing SVG events was bug 302103. I put up a couple of pages on two of my sites to do some cross-domain testing. See http://jwatt.org/svg/tests/svg-events-security.html
As the implementor of SVG events, I'm not sure I'm the appropriate person to do this review. However, I believe the code uses the existing event framework correctly to ensure it doesn't constitute a security hole. jst reviewed so it seems he believes so too. If anything, the SVG events should be less likely to be a source of a security hole than the pre-existing events since the apps don't listen for or perform a default action for SVG events. SVG events are purely a notification to content about things that have *already* happened (ie non-cancelable). Of course there's the potential that some extensions may listen for them and do inappropriate things, but that's no different to any of the other events. I consider this bug to be "fixed", so marking it so. If anyone disagrees please elaborate on what actions you still want me to take or reopen and assign to yourself.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.