On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote:
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrobson@gmail.com wrote:
And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users.
That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled.
For example take a gadget which runs unconditionally on a specific URL, like how the AJAX recent changes does, triggering a special view when on `Special:BlankPage?blankspecial=ajaxrc`. Now say the gadget happens to take user input from the URL, for example a page title, because the gadget wants per-page stuff and include a link inside the toolbox on every page that would link to the tool passing along the title of the page (title might be the most common, but there are plenty of other reasons to accept user input from the URL). If the gadget author decided to output this title into the page, they might accidentally do it in a way that amounted to raw html concatenation: Such as `+ userInput +`ing it into a block of html, passing it to a mw.message in a parameter that accepts raw html, using innerHTML in the wrong way, using some other interface that actually accepts HTML, etc... If this happened, a glaring XSS vector would suddenly become open. Anyone, anywhere on the internet could simply include an iframe pointed to the URL and use that parameter to inject any html and script they wanted creating a full-blown XSS attack. (And thanks to user scripts, etc... escalating any momentary XSS attack into a persistent on-site XSS attack is trivial)
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]