On Tue, 04 Sep 2012 02:25:56 -0700, Clément Dietschy <clement(a)seizam.com>
wrote:
On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
<sergey.chernyshev(a)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 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]