IIUC, the current version of HTML::Scrubber allows for the object tags to be either enabled or disabled entirely. However, while object can be used to add code (which is indeed a potential security hole) to a document, reading Objects, Images, and Applets in HTML documents reveals that the “dangerous” are not all the objects, but rather those having the following attributes:
classid %URI; #IMPLIED -- identifies an implementation --
codebase %URI; #IMPLIED -- base URI for classid, data, archive--
codetype %ContentType; #IMPLIED -- content type for code --
archive CDATA #IMPLIED -- space-separated list of URIs --
It seems that the following attributes are, OTOH, safe:
declare (declare) #IMPLIED -- declare but don't instantiate flag --
data %URI; #IMPLIED -- reference to object's data --
type %ContentType; #IMPLIED -- content type for data --
standby %Text; #IMPLIED -- message to show while loading --
height %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --
usemap %URI; #IMPLIED -- use client-side image map --
name CDATA #IMPLIED -- submit as part of form --
tabindex NUMBER #IMPLIED -- position in tabbing order --
Should the former attributes be scrubbed while the latter left intact, the use of the object tag would seemingly become safe.
Note also that allowing object (either restricted in such a way or not) automatically solves the [[/todo/svg]] issue.
For Ikiwiki, it may be nice to be able to restrict URI's (as required by the data and usemap attributes) to, say, relative and data: (as per RFC 2397) ones as well, though it requires some more consideration.
— [[Ivan_Shmakov]], 2010-03-12Z.
[[wishlist]]
SVG can contain embedded javascript. The spec that you link to contains
examples of objects that contain python scripts, Microsoft OLE
objects, and Java. And then there's flash. I don't think ikiwiki can
assume all the possibilities are handled securely, particularly WRT XSS
attacks.
--[[Joey]]
See also
