Edit tokens shown in frames using api
Closed, ResolvedPublic

Description

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


Version: 1.19.1
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz39180.
csteipp created this task.Via LegacyAug 8 2012, 10:31 PM
Catrope added a comment.Via ConduitAug 9 2012, 6:29 PM

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

csteipp added a comment.Via ConduitAug 10 2012, 12:52 AM

Even better. I'll do that.

csteipp added a comment.Via ConduitAug 14 2012, 12:03 AM

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: framedeny.patch

csteipp added a comment.Via ConduitAug 17 2012, 7:28 PM

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/

Bawolff added a comment.Via ConduitAug 31 2012, 4:19 PM

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

Bawolff added a comment.Via ConduitAug 31 2012, 6:04 PM

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.

bzimport added a comment.Via ConduitSep 18 2012, 4:08 PM

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?

csteipp added a comment.Via ConduitSep 18 2012, 5:14 PM

Fut.Perf, is this the same issue issue as Bug 39877?

bzimport added a comment.Via ConduitSep 18 2012, 5:25 PM

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.

csteipp added a project: Security.Via WebMar 26 2015, 8:39 PM

Add Comment