On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev sergey.chernyshev@gmail.com 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 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...
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.
-- 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