Definitely 2, since otherwise the syntax would be inconsistent. The next question is: 3) whitelist: specify which attributes are allowed 4) blacklist: specify which attributes are forbidden I'd go for 3), since the on* attributes vary depending on browser and browser version, and will continue to grow as new HTML/JS APIs appear. 3a) list all currently known HTML attributes (except event ones) 3b) list only the attributes that we want to allow to use 3c) list HTML attributes, but allow all namespaced attributes for extensibility (xwiki: prefix for our own usage, rdf: and rdfs: for semantic stuff, role: for accessibility, etc) For 4), instead of a specific list of attributes, we could blacklist attributes that start with on*. On 06/19/2013 09:23 AM, Thomas Delafosse wrote: -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+1 for 2) Besides the security issues, it's not a good practice to have in-line JavaScript as Sergiu pointed out. Regarding whitelisting vs. blacklisting, whatever the solution we need to make sure we support the HTML5 "data-" (custom) attributes. Thanks, Marius On Wed, Jun 19, 2013 at 5:06 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote: > Definitely 2, since otherwise the syntax would be inconsistent. > > The next question is: > > 3) whitelist: specify which attributes are allowed > 4) blacklist: specify which attributes are forbidden > > I'd go for 3), since the on* attributes vary depending on browser and > browser version, and will continue to grow as new HTML/JS APIs appear. > > 3a) list all currently known HTML attributes (except event ones) > 3b) list only the attributes that we want to allow to use > 3c) list HTML attributes, but allow all namespaced attributes for > extensibility (xwiki: prefix for our own usage, rdf: and rdfs: for > semantic stuff, role: for accessibility, etc) > > For 4), instead of a specific list of attributes, we could blacklist > attributes that start with on*. > > On 06/19/2013 09:23 AM, Thomas Delafosse wrote: >> Hi all, >> >> We have some security issues with the wiki syntax : people can use it >> for including some javascript, as you can pass javascript attributes >> (onclick, etc...) in links parameters for example. As it is dangerous to >> let anyone include javascript code, we should at least restrict which >> attributes unprivileged users could use with the wiki syntax. >> The question is, should users with PR rights still be able to include >> Javascript thanks to the syntax ? >> Either : >> 1) We restrict the wiki syntax for unprivileged users but give no >> restriction for users with PR. >> 2) We restrict the wiki syntax for everybody. >> >> To my mind, the wiki syntax is not designed for including javascript, there >> is the HTML macro and Skin extensions for that, so I'm in favor of 2). >> But perhaps this is something some of you use often, in which case we >> should perhaps rather go for solution 1). >> >> What do you think ? >> >> Thanks, >> >> Thomas

I'm OK for allowing namespaced attributes, but I don't really like the idea of letting people add regex. I think it would be more useful and secure to only let people add extra attributes in xwiki.properties.

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

I had in mind to authorize any attribute matching the following regex "^[a-zA-Z]+:[a-zA-Z]+$". With that, any prefixed attribute (without special chars) would be accepted, so I don't see any usecase for enabling some extra regex, while it can be useful to authorize some extra attributes.

Do we need the old printers?

I guess that as an independent rendering engine, it would be good to have the ability to have a full wiki->XDOM->XHTML pipeline. As a secure independent rendering engine, it would also be good to have a secure XHTML output, without making the (API) users do extra work to get the security working. Yes that's why I've also introduced secure blockRenderers and renderers.