Maybe the widgets on the website should have security verification badges? On the pages of secured widgets the badge would say that it's safe to use them. As far as I know the Widgets extension designed specially to create safe alternative to 'plain-old insertion of raw html and javascript to wikipages'. ----- Yury Katkov
On Tue, Sep 4, 2012 at 2:28 PM, Daniel Friesen <[email protected]> wrote: > On Tue, 04 Sep 2012 02:25:56 -0700, Clément Dietschy <[email protected]> > wrote: > >>> >>> On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev >>> <[email protected]> wrote: >>> >>> > Hi everybody, >>> > >>> > A few years back I saw a need in easy widget creation and too many >>> > extensions that just did that, but were not so well maintained and had >>> > a >>> > bunch of XSS holes in them and so on, that's when I came up with idea >>> > of >>> > Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets >> >> >> >> A very useful extension, enabling quick integration of external services. >> Thanks for creating it. >> >>> Since individual widgets were just wiki pages, I created a standalone >>> > wiki >>> > where everybody can post their widgets (in special "Widget" namespace) >>> > which will be available to everyone after basic security review (it >>> > integrates with Flagged Revisions if it's installed): >>> > http://www.mediawikiwidgets.org/ >> >> >> >> A very useful website, but sadly dying slowly, as you said. I hope we'll >> find a solution to save it. >> >>> Best, >>> > >>> > Sergey >>> >>> I don't really like this idea. I'd prefer it that the Widgets extension >>> doesn't get any more popular than it already is. >>> >>> Frankly I wish I could stick an {{XSS alert}} template on that page and >>> be >>> done with it. But I haven't because the extension is only an enabler >>> making it trivially easy to add an XSS hole into your wiki. >>> >> >> Yes, the use of the smarty language within pages, IF misused, can be >> dangerous. > > > The larger danger is the people not misusing it. It's way to easy to write > something the wrong way and open yourself up to attack. > > >> The premise of the extension is flawed. If someone cannot be trusted to >>> >>> securely write a widget in PHP there is no way that they can be trusted >>> to >>> properly escape raw concatenated html. >>> >> >> Yes, someone writing a widget through the wiki with this extension must be >> trusted. >> BUT not as trusted as someone writing a regular php extension >> (There is no backend vulnerability) >> AND, it's easier and faster to do it through the wiki. >> >> >>> It basically takes extension code; Something we can put into standard >>> repositories. Provide full pre-commit security review. Notify users of >>> security holes. And in the future incorporate systems to tell you when >>> there's a new version (likely with a security fix) you should upgrade to; >>> And puts it into raw concatenated html wiki pages -- lacking in extensive >>> escaping and high-level abstraction -- managed by users who do not >>> necessarily have any programming skills much less a proper understanding >>> of security. Somewhere developers naturally pay no attention to. >>> Somewhere >>> with no alerts about security holes, etc... And suggests that users just >>> C&P the Widget (potentially with an open XSS vector) into their wiki and >>> never look back to see if a critical hole has been fixed. >>> >> >> True, there are more secure and synchronized ways to go. >> >> A number of widgets inside that site have critical XSS vectors inside of >>> >>> them. Every time I go back there and look at random ones it doesn't take >>> long to find a hole. >> >> >> >> I use widgets a lot and never found such holes (but I mainly use very >> popular ones). >> Can you please give an example? I'm afraid there could be flaws I did not >> see... > > > Let's see... Going from A-Z in groups. Just doing some of the widgets at the > start of the list. > > The following have full on script execution vulnerabilities based on tricks > that can bypass the escaping used: > Widget:AddThis > Widget:DISQUS > Widget:Feed > Widget:Google Books > Widget:Google Maps > Widget:Google Street View > > The following have CSS based injection vulnerabilities (this is full on > script injection in some browsers): > Widget:Facebook Like Box > Widget:Feed > Widget:Google Calendar > > The following carelessly missed some escaping: > Widget:Facebook Like Box > > There were also some flash embedding video providers I won't bother listing. > They are iffy because if there's an open url redirector on the domains they > are delivered from, they could be tricked to deliver arbitrary flash based > malware. > > This was just a small portion at the start of the list. > > >> I would not be opposed to an extension that makes high-level validation >>> >>> and construction of simple widgets as extension code easier. Or making it >>> easier to get into Gerrit so people can submit extension code and we can >>> properly review it. >>> >> >> I do think this is a great idea. >> A "widget framework" extension that ease the development of widgets >> (sub)extensions. >> That would both provide the security and the ease of use. >> The only remaining problem being that a full release would be necessary to >> roll out widgets. >> I was actually planning to work on that before the end of the year as a >> way >> to replace the widget extension. >> (the extension is useful, but not perfect) >> >> >>> But there is absolutely no way that the fundamentals the Widgets >>> extension >>> are based on will provide the proper environment to create secure >>> widgets. >>> >> >> Maybe the widgets extension is not secure, but can we nevertheless imagine >> a way to write widgets code in pages? >> Lua will certainly be able to handle the logic that smarty does now. >> We're just missing a way (for sysops) to override the parser escaping of >> <script>, <iframe>, <img>... >> >>> -- >>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] >>> >> >> To me, there is no doubt that (wiki) websites must nowadays be able to >> interact with and embed the other services their users love. >> The logic necessary to render such external services is very basic and >> easy. >> I do believe that the easiest it is to contribute, the more contribution >> you get. >> (Just look at the great amount of resources there is on >> mwwidgets.orgcompared to >> mw.org). >> >> Saving Extension:Widgets, >> or building a better extension based on the same in-page code concept, >> is worth a try. > > > Widgets' abundance comes from how trivial it is to Copy & Paste without any > knowledge of programming and security -- something which unfortunately will > never create something secure --. As well as how widgets are nicely > organized into a wiki rather than scattered about. > It is quite possible we could do pretty well without the code in-page > concept. > > Things we'll need: > - An extension: > -- that makes high-level validation easy. (eg: Making sure a youtube video > id is in the right format) > -- with a way to eliminate much of the unnecessary boilerplate code in a > widget extension. > -- makes writing html output with secure high-level nested code structures > easy (rather than encouraging concatenation). > - Opening up Gerrit so people can quickly get in and submit their > extensions. > - An organized area that makes it easy to find extension based widgets. > Rather than scattering them through the other extensions. > - A wishlist page for widgets people want. > > Most widgets don't really exist since no-one with the right skills knows > they are wanted. > > Tbh if I were in my ideal working under a MediaWiki Foundation I don't think > I'd mind making one of my 20% time side projects, building simple widget > extensions that people want. > > >> -- >> Clément Dietschy >> *Seizam* Sàrl. >> 24, rue de Bâle >> 68300 Saint-Louis (France) >> tél. +33 6 87 75 99 27 >> www.seizam.com > > > > -- > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
