I
Ivan Shmakov
It seems that one reason behind people implementing various, for
the lack of a better word, “Wiki-like†formats, is the presense
of “security†issues with some XML-based “document†formats.
Shortly put, the question is: are those issues (at least the
ones related to XHTML) documented somewhere?
Here, by “security†issues I mean, mostly, the ability to spawn
fairly arbitrary code execution on the “client's†host. (Note
that even if confined to some language's interpreter, such as
the JavaScript one, the program will still, most of the time,
will be able to eat CPU resources in a hard to control fashion.)
* The purpose
The overall purpose is to establish some kind of a collaborative
environment (say, a Wiki) for me and my occasional collaborators
to use. So far, I've set up an Ikiwiki instance as the base for
such an environment (mostly because of its support for Git [1],
which I've found convenient to use, as the storage backend.)
However, Ikiwiki is somewhat restrictive about the features that
can be used on the pages. E. g.:
--cut: http://ikiwiki.info/plugins/htmlscrubber/ --
The web's security model is fundamentally broken; ikiwiki's html
sanitisation is only a patch on the underlying gaping hole that is
your web browser.
--cut: http://ikiwiki.info/plugins/htmlscrubber/ --
The list of the possibly dangerous tags in the default Ikiwiki
configuration apparently follows the considerations below.
--cut: http://feedparser.org/docs/html-sanitization.html --
Here is an incomplete list of potentially dangerous HTML tags and
attributes:
• script, which can contain malicious script
• applet, embed, and object, which can automatically download and
execute malicious code
• meta, which can contain malicious redirects
• onload, onunload, and all other on* attributes, which can contain
malicious script
• style, link, and the style attribute, which can contain malicious
script
style? Yes, style. CSS definitions can contain executable code.
--cut: http://feedparser.org/docs/html-sanitization.html --
While I understand that such issues could be dealt on the
“client's†side (I'd suggest using Lynx [2] or NoScript [3] for
that matter), it still makes me wonder, is there a more smart
way to manage the things than to entirely disallow a number of
the HTML (XHTML) features?
* References
[1] http://git-scm.com/
[2] http://lynx.isc.org/
[3] http://noscript.net/
the lack of a better word, “Wiki-like†formats, is the presense
of “security†issues with some XML-based “document†formats.
Shortly put, the question is: are those issues (at least the
ones related to XHTML) documented somewhere?
Here, by “security†issues I mean, mostly, the ability to spawn
fairly arbitrary code execution on the “client's†host. (Note
that even if confined to some language's interpreter, such as
the JavaScript one, the program will still, most of the time,
will be able to eat CPU resources in a hard to control fashion.)
* The purpose
The overall purpose is to establish some kind of a collaborative
environment (say, a Wiki) for me and my occasional collaborators
to use. So far, I've set up an Ikiwiki instance as the base for
such an environment (mostly because of its support for Git [1],
which I've found convenient to use, as the storage backend.)
However, Ikiwiki is somewhat restrictive about the features that
can be used on the pages. E. g.:
--cut: http://ikiwiki.info/plugins/htmlscrubber/ --
The web's security model is fundamentally broken; ikiwiki's html
sanitisation is only a patch on the underlying gaping hole that is
your web browser.
--cut: http://ikiwiki.info/plugins/htmlscrubber/ --
The list of the possibly dangerous tags in the default Ikiwiki
configuration apparently follows the considerations below.
--cut: http://feedparser.org/docs/html-sanitization.html --
Here is an incomplete list of potentially dangerous HTML tags and
attributes:
• script, which can contain malicious script
• applet, embed, and object, which can automatically download and
execute malicious code
• meta, which can contain malicious redirects
• onload, onunload, and all other on* attributes, which can contain
malicious script
• style, link, and the style attribute, which can contain malicious
script
style? Yes, style. CSS definitions can contain executable code.
--cut: http://feedparser.org/docs/html-sanitization.html --
While I understand that such issues could be dealt on the
“client's†side (I'd suggest using Lynx [2] or NoScript [3] for
that matter), it still makes me wonder, is there a more smart
way to manage the things than to entirely disallow a number of
the HTML (XHTML) features?
* References
[1] http://git-scm.com/
[2] http://lynx.isc.org/
[3] http://noscript.net/