xwiki-devs May 2010

xwiki-devs@xwiki.org

30 participants
85 discussions

by Jerome Velociter

----- "Andreas Jonsson" <aj(a)member.fsf.org> wrote: > The work on the new right manager user interface looks very > promising. > Good work! > > But I also think that the underlying security model must urgently be > revised. > > Although I must say that I love the idea that the users can write > their own applications on top of XWiki, the current security just > doesn't support this. > > When executing a script, who should be held accountable for the > actions are taken by the script? > > In traditional operating systems, a user is expected to know and > trust > the programs that he or she chooses to run. Considering how much > problems there are with "viruses" I'd say that this security model > works badly in traditional environments. > > But in a wiki, scripts are executed at any page load. A user who > casually browse the wiki cannot know when and what scripts are > executed. Thus, it is a complete disaster to use a security model > where the users are held accountable for whatever actions the script > is doing. > > For instance, to take over a wiki that is open for anonymous > commenting, just post a script that sits and waits for a user with > admin or programming rights to view the page. > > How can the security model be fixed? > > There are two roles that should be considered involved in the > execution of a script: user and programmer. Both the programmer and > the user should be held accountable for whatever actions are taken by > the script, but neither trust the other. The programmer says "go > ahead and run this script, but you wont be able to do anything that > you don't already have rights to". The user says "sure, I'll go > ahead > and run your script, but I don't give you any rights that you don't > already have." > > Hence, a script should be executed with the intersection of the > rights that the two roles possess. > > But it should be possible for a programmer that have carefully > sanitized the user input to lend his or hers full privileges to the > user. > > It should also be possible for users to indicate that they have > reviewed a script and indicate that they trust a certain scripts or > that they trust some programmer. In other words, the users should be > able to lend their full rights to a particular script or to scripts > written by a trusted programmer, when executed by the user. > > What about contents that is generated by a script? > > If the user who runs a script becomes the programmer of any scripts > that are generated and saved, we have just added one level of > indirection for attackers: An anonymous commenter could post a script > that waits for an administrator. This script should in turn post a > script (whos programmer would then be the administrator) that waits > for an administrator. > > Since both user and programmer should be held accountable for the > actions taken by a script, it might be reasonable that they are also > both credited for any contents generated by the script. Thus both > the > user and the programmer could be considered "the programmer" for any > new scripts generated by a script. But this might be unnecessarily > complex. > > Instead, a distninction could be made on documents that is "saved > with a programmer set" and those that are not. When rendering a > document > that does not have a programmer, all rights should be denied for > scripts in the document. Saving a document with yourself as "the > programmer" must not be allowed without first prompting the user for > a > confirmation, where the user must input a password. This to prevent > attacks where the user is tricked into saving content with to the > programmer set. > > How can this be implemented in XWiki? > > A document has a "creator", which is the person who saved the first > revision of the document and each revision of the document has an > "author", which is the person who saved the revision. We have to > extend the document format to support a "programmer". > > "The user" is of course the logged in user that requests the page. > The user is authenticated the ordinary way and both programmer (if > any) and user is noted in the context. Thereafter any rights check > is > made by checking if both user and programmer has the right. If there > is no programmer, all right checks should return "deny", except maybe > for the "view"-right that should be checked against the user to allow > the include macro without saving with a programmer. (But this opens > up for an attack where page content which aren't viewable by everyone > can be extracted, so maybe not. It could be a configurable option.) > > Obviously, it is important that comments to a page are not rendered > with a programmer set. This will make it impossible to execute > privileged scripts in comments. I don't think that is a useful > feature, anyway. > > This will also require some additional user interaction. The default > should be to not set any programmer when saving a document, and this > will of course not require anything special from the user. > > But when saving a page, it should be possible to select "save with me > set to the programmer". If the user chooses this option, she will be > forwarded to a confirmation page "You are about to save this content > with you set to the programmer. Please confirm by entering your save > password." > > It should also be possible to select "save with me as programmer and > lend my rights to users executing scripts in this page", whereupon > the > confirmation page should be marked with a big warning sign and > contain > a harsh lecture on sanitizing user input. It might be a good idea to > introduce a special "save setuid" right that the user must have in > order to at all be allowed to do this. A user that have programming > rights should additionally have the option to set the programmer to > an > arbitrary user. A setuid script should, of course, have a programmer > with as little privileges as possible. A set of dummy users with > varying privileges could be prepared for this purpose. > > In order to allow saving documents with "the programmer" set in bulk > (for instance in the import application), there should also be a > confirmation page for allowing "saving with programmer set" > throughout > a request. > > Is this sufficient? > > Maybe. We have at least made it a lot harder for attackers, because > now they must trick a privileged user to confirm a "save with myself > as programmer". If the same password is used for saving pages as for > logging in, this can be accomplished by spoofing a login-page. Thus, > there should be a separate "save password" which must differ from the > ordinary login password. > > It might even be possible to allow users to save javascript > extensions. But there should at least be a configurable option to > demand programming rights for this. Javascripts opens up many > attack paths. > > Tasks: > > 1. Add "programmer" attribute to document. It could be a 'XWiki.ProgramClass' object (to be discussed) > > 2. Add "execute scripts with the programmers privilege (setuid)"-flag > to document. Same, could be a property of said object > > 3. Change the RightService to: > > 1. if a programmer is not set, deny everything except "view", > which > (as a configurable wiki option) can be checked only for the > user > (to allow using the include macro without saving with a > programmer), > > 2. check rights only for the programmer, if the setuid-flag is > set, > > 3. check rights only for user, if the programmer is "trusted" or > the user "trusts" the document, > > 4. check rights for both user and programmer, otherwise. > > Although the current right service implementation can be kludged > into supporting this, it really needs to be rewritten from > scratch, > both for clarity and speed. > > The special treatment when the document author happens to have > programming rights must be removed. > > How to determine if a programmer or the document is "trusted" is > an > open question, but I guess that users with programming or admin > rights, at least, can be considered trusted. > > 4. Add "save password" to the user profile, which must be set to a > non-empty string that differs from the login password for the > user > to be allowed to "save with myself as programmer" or "save > setuid". > > 5. Add user interface controls for saving a page with programmer set. > > 6. Add confirmation page for confirming "save with myself as > programmer". > > 7. Add user interface controls and confirmation page for "save > setuid". > > 8. Add wiki-option to demand programming rights for saving javascript > extensions. FYI it's already the case of "always-use" extensions. (Same for CSS extensions) > > 9. Fix all applications that undoubtly will be broken by this change. The changes listed here are not really backward compatible, so it will be a necessary way anyway, in order to have an application that make use of the programming right in a working state with a new security model. > > Do you other people agree with me when I say that the security model > must be replaced immediately? What do you think about my suggestion? > Please, poke at it to try to find any attacks that I have not > thought of. I'm very +1 to fix the programming right immediately (by that I mean for programmers to declare a page that require to be executed with the programming right). For the rest of the proposal, I have to think more about it before I make my mind. Anyway I think we can improve the security model incrementally - of course the sooner the better. > > I have started on a new right service implementation with a > cacheing front-end. I'll create a new module under core which I'll > call 'xwiki-security' and move the right service to the new > architecture while I'm at it. That's great. Don't hesitate to commit it early in the sandbox so that everyone can look at it. Jerome. > > > Best regards, > > Andreas Jonsson > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 3 months

Re: [xwiki-devs] [VOTE] Automatically add scope attribute in generated table header cells in XHTML renderer (summary)

by Thomas Mortagne

7 +1, committing now See http://jira.xwiki.org/jira/browse/XWIKI-5222 On Tue, May 25, 2010 at 14:31, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi dev, > > For Dutch Web Guidelines validity a <th> have to contains scope > attribute (scope="col" or scope="row") which means that default wiki > tables are invalid currently. > > See http://www.w3.org/TR/xhtml2/mod-tables.html#non-visual-rendering > for example of scope attribute use. > > I propose to modify XHTML renderer table header cell to do the following: > * if a scope is explicitly provided reuse it > * if there is no scope: > ** if first line or not first column: <th scope="col"> > ** if not first line and first column: <th scope="row"> > > I thing that covers most of the use cases and it will avoid having to > set explicitly scope attribute in all our standard pages. > > WDYT ? > > -- > Thomas Mortagne > -- Thomas Mortagne

14 years, 3 months

[xwiki-devs] [Proposal] Remove old attributes*.vm templates

by Alex Busenius

Hello devs, I propose to remove the following templates: web/standard/src/main/webapp/templates/attributes.vm web/standard/src/main/webapp/templates/attributesinline.vm They are not used any more (replaced by the "Information" tab), are still in 1.0 syntax, are not internationalized (the only one used translation is missing) and they also have some security issues. Alex

14 years, 3 months

[xwiki-devs] [VOTE] Automatically add scope attribute in generated table header cells in XHTML renderer

by Thomas Mortagne

Hi dev, For Dutch Web Guidelines validity a <th> have to contains scope attribute (scope="col" or scope="row") which means that default wiki tables are invalid currently. See http://www.w3.org/TR/xhtml2/mod-tables.html#non-visual-rendering for example of scope attribute use. I propose to modify XHTML renderer table header cell to do the following: * if a scope is explicitly provided reuse it * if there is no scope: ** if first line or not first column: <th scope="col"> ** if not first line and first column: <th scope="row"> I thing that covers most of the use cases and it will avoid having to set explicitly scope attribute in all our standard pages. WDYT ? -- Thomas Mortagne

14 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r28991 - in platform/web/trunk/standard/src/main/webapp: resources/js/xwiki/table templates

by Sergiu Dumitriu

On 05/25/2010 11:20 AM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-05-25 11:20:42 +0200 (Tue, 25 May 2010) > New Revision: 28991 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.css > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > Log: > XWIKI-5219 - Improve livetable markup for better accessibility compliance > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.css > =================================================================== > -.xwiki-livetable-pagination span.pagenumber { > +.xwiki-livetable-pagination a.pagenumber { For more flexibility, this could become just .xwiki-livetable-pagination .pagenumber -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 3 months

[xwiki-devs] [VOTE] Improve accessibility of livetables pagination

by Denis Gervalle

Hi devs, Even if ajax based stuff will never fully comply with accessibility requirements, I would like to improve a little bit the livetable pagination markup so it gets closer to these requirements. Currently, the pagination feature use <span> for numbers, and also use empty <span> with a background image for previous/next page buttons. Both of these practice produce very poor interface once the css is disabled. I attach a patch that improve the situation by using <a> in place of <span>, so that links are properly identified when css is not used or with a screen readers. Using CSS, the behavior and the design is unchanged. Here is my +1 to apply this ASAP on trunk. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 3 months

[xwiki-devs] OSGi manifest data for our core modules

by Vincent Massol

Hi devs, I'd like to add OSGi manifest data generation for our core modules during our build. This would be the first step in allowing xwiki modules to be used in an osgi environment (whether it's by us later on or by external users who want to use the xwiki rendering for example). WDYT? Thanks -Vincent

14 years, 3 months

[xwiki-devs] Need tempresource support to integrate office-preview

by Asiri Rathnayake

Hello Devs, I've been looking at integrating office-preview module into our main source but I'm really not happy with how presentation preview support is currently implemented, its a load of hacks (btw, its myself who coded it that way). When a presentation office document is imported, it generates a bunch of html files (slides) and a set of images. I need a way to group these artifacts into a single temporary directory and link from the wiki page into the main slice (html page). This is not possible without something like tempresource action and currently I use charting action with a lot of hacks (and only image slides are supported). Is anyone working on tempresource action? Can I work on it? Thanks. - Asiri

14 years, 3 months

[xwiki-devs] Programmatically Login

by Luiz Marcelo Serique

Hi, I'm new on list, and new on xwiki too, we have successfully deployed the XWiki Enterprise 2.3 in our company, but there is some pre requisites that we must accomplish to integrate the system to our SSO aplication. The SSO is a very simple aplication that stores all users and groups on a independent database, the SSO system have a interface that shows, like a catalog, all the internal systems that a specific person (logged in person) has access. The archictecture is very simple, and almost time insecure, passing by GET parameter the credentials to other systems in php, java, python, etc..., but this is another point that we here have to discuss and adjust adjust. To provide this SSO to xwiki i was wondering create a Filter that verify those GET parameters and programmatically authenticates the user to XWiki and use the MyFormAuthenticator.authenticate() to perform the login. But here come the question, the authenticate method needs a XWikiContext object, is it possible to have this context in a Servlet Filter? And you guys have some suggestions about my strategy? Any alternative to what i want achieve? -- L. Marcelo

14 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r28950 - platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table

by Vincent Massol

On May 20, 2010, at 7:15 PM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-05-20 19:15:53 +0200 (Thu, 20 May 2010) > New Revision: 28950 > > Modified: > platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > Log: > XWIKI-5212 - Livetable filter serialization does not properly support multi-valued form elements > Merge from trunk r28947 Do we have a test for this? How do we unit-test UI components? Thanks -Vincent > Modified: platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > =================================================================== > --- platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20 17:11:02 UTC (rev 28949) > +++ platform/web/branches/xwiki-web-2.3/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-05-20 17:15:53 UTC (rev 28950) > @@ -609,11 +609,12 @@ > for (var i = 0; i < this.inputs.length; ++i) { > var key = this.inputs[i].name; > if ((this.inputs[i].type == "radio") || (this.inputs[i].type == "checkbox")) { > - if (this.filters[key]) { > - if (this.filters[key] == this.inputs[i].value.strip()) { > - this.inputs[i].checked = true; > + var filter = this.filters[key]; > + if (filter) { > + if (Object.isArray(filter)) { > + this.inputs[i].checked = (filter.indexOf(this.inputs[i].value.strip()) != -1); > } else { > - this.inputs[i].checked = false; > + this.inputs[i].checked = (filter == this.inputs[i].value.strip()); > } > } > } else { > @@ -624,14 +625,14 @@ > } > > for (var i = 0; i < this.selects.length; ++i) { > - if (!this.filters[this.selects[i].name]) { > - continue; > - } > - for (var j = 0; j < this.selects[i].options.length; ++j) { > - if (this.selects[i].options[j].value == this.filters[this.selects[i].name]) { > - this.selects[i].options[j].selected = true; > - } else { > - this.selects[i].options[j].selected = false; > + var filter = this.filters[this.selects[i].name]; > + if (filter) { > + for (var j = 0; j < this.selects[i].options.length; ++j) { > + if (Object.isArray(filter)) { > + this.selects[i].options[j].selected = (filter.indexOf(this.selects[i].options[j].value) != -1); > + } else { > + this.selects[i].options[j].selected = (this.selects[i].options[j].value == filter); > + } > } > } > } > @@ -649,7 +650,7 @@ > // Ignore filters with blank value > if (!filters[i].value.blank()) { > if ((filters[i].type != "radio" && filters[i].type != "checkbox") || filters[i].checked) { > - result += ("&" + filters[i].name + "=" + encodeURIComponent(filters[i].value)); > + result += ("&" + filters[i].serialize()); > } > } > }

14 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2010