From: luci a. l. d' b. <sf...@gr...> - 2010-11-22 02:47:15
|
hi geoff and chealer and all (cc devel), first i want to say i understand what chealer means about XSS and that "data needs to be escaped" but i think his concerns are not valid here because we're in the admin area (that said i mean XSS as "rule 1" is not relevant in this case as only admins and trusted editors of the site should be responsible for what they put there in the menu items and no one else is able to modify that without the perms...). i am the geoff's side here, because we've got something broken, which was easily possible and useful to do before, and thus not respecting the environment (so breaking one of the 3rules, right ?). so i think geoff did a rollback fixing the issue, while you, chealer, are asking to do another rollback to break it again ? sorry chealer, but please, don't try to be more clever than every Tiki site Admin/Editor... if they wanted to create menu item "Policies & Procedures" and still stay valid, they could put it like "Policies & Procedures" there. so, if you really don't like allowing unescaped HTML there, you must go and code something to give people who upgrade some level of backward compatibility (especially for LTS) or provide some easily usable alternative to the previous functionality (like a checkbox for admin to "Allow HTML for menu items" or something like that) instead of breaking their menus and just telling them that it is dangerous XSS hole, you have no time to bother coding anything for it and that we won't support unescaped HTML in menu items anymore... otherwise we could soon end up escaping the data everywhere in the admin area arguing it is dangerous because of possible XSS making all the customization goodies in L&F panel inputs and textareas an overly complicated hell. luci On 11/22/2010 02:22 AM, Filipus Klutiero wrote: > On 2010-11-21 17:41, geoff@enmore wrote: >> Hi chealer >> >> I did actually socialise these changes extensively on the 'devel' >> list and discuss them with jonny before making them and didn't >> receive any objections, but I don't actually understand why you feel >> this should be rolled back. > I went over Rick's thread discussing menu issues quickly, it's quite > possible this was discussed there. I'm sorry if I gave the impression > you had not discussed the change, that was not my intention. >> >> When you say " this is not supported " who says so? and why? > I guess I say so :-) The code doesn't support putting HTML code in > names (you can actually do that, but it will interpreted literally). > The reason is the code can't autodetect which language you're > speaking. Usually, you want people to read exactly what you write, so > HTML special characters need to be escaped. But if you write > "<strong>WARNING</strong>" you probably want that to be output > directly in the HTML. Tiki can't do both without an option. >> >> This type of functionality was supported in earlier versions of Tiki >> and when using css menus was working in Tiki 6-branch upto 27th Oct >> >> Perhaps you could let us know what you think the issue is in some detail > In short, data needs to be escaped. > http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet > does a good presentation of escaping in the Web context. In this case, > rule 1 needs to be followed: > http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content > For example, create a menu option called "Policies & Procedures". In > cssmenu, pages with the menu would be invalid if the name is not escaped. >> >> Thanks >> >> geoff >> >> ------------------------------------------------------------------------ >> *From:* Filipus Klutiero [mailto:ch...@gm...] >> *Sent:* 21 November 2010 19:04 >> *To:* er...@us... >> *Cc:* tik...@li... >> *Subject:* Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[30773] >> branches/6.x/templates >> >> Hi eromneg, >> last week I fixed the display of menus, which wasn't escaping menu >> option names, in r30646. This revealed a problem in the main menu of >> info.tiki.org, which had 2 menu options with HTML code in their name >> field to display small icons in the menu. Discussing with Rick and >> changi, we fixed one last week, and the other one only today (by simply >> removing the icons). During the last week, info was not showing the >> problem because changi had locally reverted r30646 on info. Discussing >> with him, he told me r30646 had been "fixed" by r30773. >> >> It's possible some other sites are using this kind of hack to have >> particular menus, and I suppose that's what triggered your commit, but >> this is not supported. The name field is designed to contain, well, >> names, so HTML code is interpreted literally. An alternative if people >> want to put code is to have a menu option content field which could have >> Wiki syntax. Jonny and lindon discussed something like that yesterday: >> http://irc.tiki.org/irclogger_log/tikiwiki?date=2010-11-20,Sat&sel=243#l239 >> <http://irc.tiki.org/irclogger_log/tikiwiki?date=2010-11-20,Sat&sel=243#l239> >> What I would see is a radio button with 2 choices, a default choice >> "Simple" or "Standard" and another choice "Advanced" or "Custom". If the >> second choice is selected, the name field is replaced by a Content >> field, which is parsed as Wiki syntax. >> >> Unfortunately I can't commit to develop this. If you have no objection, >> I will just revert r30773. If some sites are using exotic names and want >> to keep them, they can locally apply r30773 and keep looking as before. >> > > > --------------------------------------------------------------------------- > > Freehosting PIPNI - http://www.pipni.cz/ > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > > > _______________________________________________ > Tikiwiki-cvs mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs > |