(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
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?

Attached:

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.

fut.perf wrote:

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?

fut.perf wrote:

@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.