Re: [xwiki-users] Searching workaround for HTML in title-field
Joel Forsberg wrote:
Do you happen to know the JIRA ticket for this bug? (if there is one?)
http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
engine.
The {pre} seems to dodge some of the unwanted effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to
have
disappeared, instead leaving a p-tag artifact depending on circumstances.
CrossSiteScripting example: scriptalert('I pwnd U')/script
= bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
--
If you want to get to the top, you have to start at the bottom
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
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.
Caleb
Ivan Levashew wrote:
Joel Forsberg wrote:
Do you happen to know the JIRA ticket for this bug? (if there is one?)
http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
engine.
The {pre} seems to dodge some of the unwanted effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to
have
disappeared, instead leaving a p-tag artifact depending on circumstances.
CrossSiteScripting example: scriptalert('I pwnd U')/script
= bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
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 ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
Ivan Levashew wrote: 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. We have something like that. We call it XDOM. It can be rendered into XHTML, PDF OpenOffice export etc. http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule There is an issue for adding means to manipulate the XDOM using server side script. http://jira.xwiki.org/jira/browse/XWIKI-5234 2 problems: 1. Lots of content (including all of the .vm templates) is in Syntax 1.0 which doesn't use the new rendering module. 2. Syntax 2.0 parsers contain lots of code and have bugs of their own. IMO security code should be as small and as heavily reviewed as possible. 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. I think you could strip all types of script invocation from a stream of xml without actually parsing the xml. If you can't do it with sed, it's not worth doing ;) ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
On Friday 05 March 2010 15:06:34 Sergiu Dumitriu wrote:
snipped
{pre}{/pre} prevents re-rendering the content.
The result with this is:
A damn
ruler
Which again is a bit wrong, but this is a bug in the core, it always
assumes that the content that it got from the title field is
velocity+HTML, even if the page is in xwiki/2.0 syntax.
Do you happen to know the JIRA ticket for this bug? (if there is one?)
The {pre} seems to dodge some of the unwanted effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving a p-tag artifact depending on circumstances.
CrossSiteScripting example: scriptalert('I pwnd U')/script
= bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
Kind regards, Joel
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Searching workaround for HTML in title-field
On 03/05/2010 04:30 PM, Joel Forsberg wrote:
On Friday 05 March 2010 15:06:34 Sergiu Dumitriu wrote:
snipped
{pre}{/pre} prevents re-rendering the content.
The result with this is:
A damn
ruler
Which again is a bit wrong, but this is a bug in the core, it always
assumes that the content that it got from the title field is
velocity+HTML, even if the page is in xwiki/2.0 syntax.
Do you happen to know the JIRA ticket for this bug? (if there is one?)
There isn't one AFAIK.
The {pre} seems to dodge some of the unwanted effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving ap-tag artifact depending on circumstances.
Yes, that's another bug in the 1.0 renderer, one which can't be easily
avoided: the panel display itself is in a 1.0 document, which sees the
{pre} and uses it. As a workaround, you can edit the panel using the
object editor.
CrossSiteScripting example:scriptalert('I pwnd U')/script
= bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
Kind regards, Joel
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
