James DeLisle wrote:
This is not a problem only with the search field.
It's a security policy that
XWiki allows it's users to run script. In syntax 1.0 you are allowed to type
HTML (and thus script) into the document, in syntax 2.0 you can use HTML in
the document by invoking the HTML macro.
My opinion is that to prevent users from running script you would have to set up
an output filter such as Apache mod_filter and implement a policy which blocks all
script which is in parts of the page which are user editable.
I have a short experience with Jaxer. It is not maintained, but is
pretty usable if starting from scratch is OK for you. Notable difference
is that most operations are performed on structured DOM trees as opposed
to structureless strings in e. g. PHP. The engine is serverside Mozilla,
so the tricks like innerHTML are working, but strings are exception
instead of a rule in the world of Jaxer.
I think, sooner or later it would be evident that next major revision of
X-Wiki must use structured data instead of all that
easy-to-forget-because-anyway-it-mostly-works escaping.
This makes sense because, for instance, one might want to enable users
to post into common blog but prevent them from storing scripts. There is
no "string noscript(string)" function. It is far beyond mere escaping.
Even if such function existed, parsing and serializing is CPU-costly.
--
If you want to get to the top, you have to start at the bottom