Last modified: 2012-09-18 17:25:01 UTC
Using some ui redressing like [1], our edit token can be stolen when it's shown on api result pages. It would be good to respect $wgEditPageFrameOptions on api result pages that show an edit token, if possible. [1] - http://blog.kotowicz.net/2011/07/cross-domain-content-extraction-with.html
(In reply to comment #0) > Using some ui redressing like [1], our edit token can be stolen when it's shown > on api result pages. > > It would be good to respect $wgEditPageFrameOptions on api result pages that > show an edit token, if possible. > Why wouldn't we just go all the way and set X-Frame-Options: disallow (or whatever the most restrictive setting is) on all API responses? I don't think there's ever a good reason to load API responses in iframes unless you're trying to creatively circumvent same origin restrictions.
Even better. I'll do that.
Created attachment 10961 [details] Add x-frame-options: DENY to api pages Simple patch to deny framing api responses. This will not prevent using the api within an iframe (tested in firefox/chrome) only iframing a direct api result. Is this a big enough change that we would want a $wgBreakFramesApi, that defaults to true?
Patch added in gerrit. I decided to use a $wg variable so it can be disabled (in case there's someone using the api in an iframe), but it's enabled by default. https://gerrit.wikimedia.org/r/#/c/20472/
(In reply to comment #4) > Patch added in gerrit. I decided to use a $wg variable so it can be disabled > (in case there's someone using the api in an iframe), but it's enabled by > default. > > https://gerrit.wikimedia.org/r/#/c/20472/ For the record, I was using the api output in an iframe.... (As part of a js thing to allow people to double click on a word, and get the wiktionary definition using the xslt parameter of the API)
> > For the record, I was using the api output in an iframe.... (As part of a js > thing to allow people to double click on a word, and get the wiktionary > definition using the xslt parameter of the API) Specifically I was embedding things like https://en.wiktionary.org/w/api.php?action=parse&redirects&prop=text&format=xml&xslt=MediaWiki:extractFirst.xsl&page=double-click&lang=en&count=1&showWord=bold in iframes when people double clicked words. (OTOH I stopped maintaining said thingy several years ago on account of it being such a kludge, so I'm not even sure if anyone uses that) Could we perhaps make the x-frame-options: deny, only go on things that would be prevented from doing format=json&callback=foo - after all, anything that could be gleaned from this attack could be much more easily done if one is allowed to do json-with-callback.
This has also broken the file upload script used at en-WP (https://en.wikipedia.org/wiki/Wikipedia:File_Upload_Wizard). Correct me if I'm wrong, but it was my impression that directing API output to an IFrame was pretty much a standard strategy in scripting file uploads. How else is one supposed to do it?
Fut.Perf, is this the same issue issue as Bug 39877?
@Chris Steipp: yes, looks like it (i.e. it seems to be the same technical problem, though we're talking about two different upload scripts – the en-wp wizard is not the same thing as the Commons wizard.) Thanks for pointing this out.
