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: wikibugs-l.
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 WebThu, Mar 26, 8:39 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.