[Wikitech-l] X-Frame-Options DENY / SAMEORIGIN and cross-wiki userscripts
Jérémie Roquet
Following #26561 [1] and the MediaWiki security release 1.16.1 [2],
some cross-wiki userscripts of mine do not work anymore.
Namely, these scripts are:
- iKiwi [3] which is used to retrieve all interwikis of a local
article from another wiki and is extensively used by the French
interwikification project [4];
- xmsg [5] which is used to check new messages on other wikis when
login on (and I'm probably the only person to use).
Both of them use a trick with an iframe to allow javascript requests
across the wikipedia.org subdomains (something that is not possible
using AJAX).
So, my question are:
- Does anybody know if having X-Frame-Options set to SAMEORIGIN would
allow such tricks while still preventing clickjacking attacks from
other domains (the actual question is: `would it work'?)
- If so, is there any reason to use DENY instead of SAMEORIGIN, ie.
is there any pragmatic reason to forbid frames from the very same
domain (wikipedia.org)?
Any other idea on how to make such tools work again would of course be
highly appreciated.
Thanks in advance,
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26561
[2] http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-January/000093.html
[3] http://en.wikipedia.org/wiki/User:Arkanosis/iKiwi.js
[4] http://fr.wikipedia.org/wiki/Projet:Interwikification
[5] http://fr.wikipedia.org/wiki/User:Arkanosis/xmsg.js
--
Jérémie
_______________________________________________
Wikitech-l mailing list
Wikit...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aryeh Gregor
> Both of them use a trick with an iframe to allow javascript requests
> across the wikipedia.org subdomains (something that is not possible
> using AJAX).
It would be possible if we started using CORS, at least in recent
enough browsers.
> - Does anybody know if having X-Frame-Options set to SAMEORIGIN would
> allow such tricks while still preventing clickjacking attacks from
> other domains (the actual question is: `would it work'?)
en.wikipedia.org is not the same origin as fr.wikipedia.org.
> Any other idea on how to make such tools work again would of course be
> highly appreciated.
I'm not very knowledgeable in this sort of thing, I'm afraid. HTML5's
postMessage() might be useful.
Jérémie Roquet
2011/1/9 Aryeh Gregor <Simetrica...@gmail.com>:
> 2011/1/8 Jérémie Roquet <arka...@gmail.com>:
>> Both of them use a trick with an iframe to allow javascript requests
>> across the wikipedia.org subdomains (something that is not possible
>> using AJAX).
>
> It would be possible if we started using CORS, at least in recent
> enough browsers.
It would be awesome to have this enabled to allow AJAX requests across
all the Wikimedia projects.
I mean, not only it would allow to make my tools work again without
the iframe hack, but I have many other ideas of really cool new tools
that could be built upon CORS (including interactions between
Wikipedia and Wikimedia Commons, which I could not achieve with the
iframe trick).
Sure, it wouldn't work in as many browsers as the iframe trick did,
but I really prefer something that requires a modern browser to work
to something that requires an old one ;-)
>> - Does anybody know if having X-Frame-Options set to SAMEORIGIN would
>> allow such tricks while still preventing clickjacking attacks from
>> other domains (the actual question is: `would it work'?)
>
> en.wikipedia.org is not the same origin as fr.wikipedia.org.
True, but it appears that setting document.domain to the same value
for both subdomains (ie. 'wikipedia.org') is enough to have the same
origin. [1]
That's what I was already doing for iKiwi and xmsg to work, because
without this, most browsers already enforce the same origin policy for
DOM manipulations inside (i)frames. With it, it works fine, even with
the NoScript addon.
>> Any other idea on how to make such tools work again would of course be
>> highly appreciated.
>
> I'm not very knowledgeable in this sort of thing, I'm afraid. HTML5's
> postMessage() might be useful.
Thanks for the tip, I never heard about this before. However, reading
the description at MDN [2], I'm afraid it doesn't address the current
issue at all because it requires two windows to communicate together
(which is exactly what X-Frame-Options forbids).
That would have allowed to make cross-domain requests (eg. between
Wikipedia and Wikimedia Commons), but with X-Frame-Options I'm afraid
it's just as useless as the iframe hack.
That said, my questions now are:
- It would be very nice to have CORS enabled across the Wiki[mp]edia
subdomains (I see it has been mentioned by Brion in the `JavaScript
access to uploaded file contents' thread [3][4] for
upload.wikimedia.org) ⇒ is it something that can be done / discussed?
I looks like the code for this is already there [5], maybe I should
open a new bug right now?
- Taking the document.domain trick into account ⇒ would setting
X-Frame-Options to SAMEORIGIN instead of DENY allow frames between
/sub/domains?
Thanks again! Best regards,
[1] http://en.wikipedia.org/wiki/Same_origin_policy#Additional_document.domain_logic
[2] https://developer.mozilla.org/en/dom/window.postmessage
[3] http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/050972.html
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=25886
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=19907
--
Jérémie
Roan Kattouw
> - It would be very nice to have CORS enabled across the Wiki[mp]edia
> subdomains (I see it has been mentioned by Brion in the `JavaScript
> access to uploaded file contents' thread [3][4] for
This has been discussed in a few contexts now, and we all seem to
agree that this is a good idea and should definitely be enabled. I'd
propose doing this after we deploy 1.17wmf1 and stuff has calmed down
a bit (it's not uncommon for things to break after a major
deployment).
> I looks like the code for this is already there [5], maybe I should
> open a new bug right now?
Would be nice to track it in BZ, yes.
Roan Kattouw (Catrope)
Aryeh Gregor
> True, but it appears that setting document.domain to the same value
> for both subdomains (ie. 'wikipedia.org') is enough to have the same
> origin. [1]
> That's what I was already doing for iKiwi and xmsg to work, because
> without this, most browsers already enforce the same origin policy for
> DOM manipulations inside (i)frames. With it, it works fine, even with
> the NoScript addon.
Ah, right.
> Thanks for the tip, I never heard about this before. However, reading
> the description at MDN [2], I'm afraid it doesn't address the current
> issue at all because it requires two windows to communicate together
> (which is exactly what X-Frame-Options forbids).
> That would have allowed to make cross-domain requests (eg. between
> Wikipedia and Wikimedia Commons), but with X-Frame-Options I'm afraid
> it's just as useless as the iframe hack.
Hmm, right.
> - Taking the document.domain trick into account ⇒ would setting
> X-Frame-Options to SAMEORIGIN instead of DENY allow frames between
> /sub/domains?
I don't see any detailed documentation for X-Frame-Options anywhere.
It looks like IE8 made it up with no detailed spec and other browsers
copied the general idea still with no detailed spec. So I don't know,
sorry.
Ilmari Karonen
> Hello everyone, happy new year.
>
> Following #26561 [1] and the MediaWiki security release 1.16.1 [2],
> some cross-wiki userscripts of mine do not work anymore.
>
> Namely, these scripts are:
> - iKiwi [3] which is used to retrieve all interwikis of a local
> article from another wiki and is extensively used by the French
> interwikification project [4];
> - xmsg [5] which is used to check new messages on other wikis when
> login on (and I'm probably the only person to use).
>
> Both of them use a trick with an iframe to allow javascript requests
> across the wikipedia.org subdomains (something that is not possible
> using AJAX).
Use JSONP. The MediaWiki API supports it through the "callback" parameter.
--
Ilmari Karonen
Tim Starling
> - Taking the document.domain trick into account ⇒ would setting
> X-Frame-Options to SAMEORIGIN instead of DENY allow frames between
> /sub/domains?
No, SAMEORIGIN does not allow framing from say en.wikipedia.org to
fr.wikipedia.org. It only allows framing within the exact same domain.
http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
"For instance, if http://shop.example.com/confirm.asp contains a DENY
directive, that page will not render in a subframe, no matter where
the parent frame is located. In contrast, if the X-FRAME-OPTIONS
directive contains the SAMEORIGIN token, the page may be framed by any
page from the exact http://shop.example.com origin."
-- Tim Starling
Jérémie Roquet
> 2011/1/9 Jérémie Roquet <arka...@gmail.com>:
>> - It would be very nice to have CORS enabled across the Wiki[mp]edia
>> subdomains (I see it has been mentioned by Brion in the `JavaScript
>> access to uploaded file contents' thread [3][4] for
>> upload.wikimedia.org) => is it something that can be done / discussed?
> This has been discussed in a few contexts now, and we all seem to
> agree that this is a good idea and should definitely be enabled. I'd
> propose doing this after we deploy 1.17wmf1 and stuff has calmed down
> a bit (it's not uncommon for things to break after a major
> deployment).
Hi Roan. It's great if there's no major opposition to it :)
>> I looks like the code for this is already there [5], maybe I should
>> open a new bug right now?
> Would be nice to track it in BZ, yes.
Will do so and give the link there. Thanks!
2011/1/9 Aryeh Gregor <Simetrica...@gmail.com>:
> I don't see any detailed documentation for X-Frame-Options anywhere.
> It looks like IE8 made it up with no detailed spec and other browsers
> copied the general idea still with no detailed spec. So I don't know,
> sorry.
No worries :) Thanks again.
2011/1/9 Ilmari Karonen <nos...@vyznev.net>:
>> Both of them use a trick with an iframe to allow javascript requests
>> across the wikipedia.org subdomains (something that is not possible
>> using AJAX).
> Use JSONP. The MediaWiki API supports it through the "callback" parameter.
Hi Ilmari, great idea!
It's not as powerful as the iframe hack was (since it's limited to
the api), but I think it's enough for me to release a quick fix for
iKiwi (not for xmsg, unfortunately, because userinfo is not accessible
that way).
I didn't know about the callback parameter, so you just saved my
business ;-) Thanks a lot!
2011/1/10 Tim Starling <tsta...@wikimedia.org>:
> On 10/01/11 01:23, Jérémie Roquet wrote:
>> - Taking the document.domain trick into account ⇒ would setting
>> X-Frame-Options to SAMEORIGIN instead of DENY allow frames between
>> /sub/domains?
> No, SAMEORIGIN does not allow framing from say en.wikipedia.org to
> fr.wikipedia.org. It only allows framing within the exact same domain.
> http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
Hi Tim, thanks for the link and the explanations!
--
Jérémie
Platonides
> Hi Ilmari, great idea!
> It's not as powerful as the iframe hack was (since it's limited to
> the api), but I think it's enough for me to release a quick fix for
> iKiwi (not for xmsg, unfortunately, because userinfo is not accessible
> that way).
> I didn't know about the callback parameter, so you just saved my
> business ;-) Thanks a lot!
Why do you consider the api less powerful than "dom scraping" ?
What can't you do with it?
It fits perfectly for fetching the interwikis:
http://en.wikipedia.org/w/api.php?action=parse&page=Main_Page&prop=langlinks
And there's a handy property to determine if you have new messages:
http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
Jérémie Roquet
2011/1/10 Platonides <Plato...@gmail.com>:
> Jérémie Roquet wrote:
>> It's not as powerful as the iframe hack was (since it's limited to
>> the api), but I think it's enough for me to release a quick fix for
>> iKiwi (not for xmsg, unfortunately, because userinfo is not accessible
>> that way).
> Why do you consider the api less powerful than "dom scraping" ?
> What can't you do with it?
Well, it's not an issue about the api per se, but rather a weakness of
the jsonp approach:
- You can't fetch user-specific data [1]
- You can't send POST requests, meaning you can't edit or create pages [2]
Both limitations are of course fortunate because it would allow
malicious sites to know about their visitors or to edit Wikipedia on
their behalf.
> It fits perfectly for fetching the interwikis:
> http://en.wikipedia.org/w/api.php?action=parse&page=Main_Page&prop=langlinks
Yes, that's the good point. I'm very happy Ilmari came with the jsonp
idea as it's exactly what I need for iKiwi to work again.
And thanks for the langlinks idea!
> And there's a handy property to determine if you have new messages:
> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].
Hopefully, with CORS we'll have access to the whole api (including
userinfo and writeapi) (and to scrapping, if needed for any reason).
Thanks for your ideas! Best regards,
[1] « callback - If specified, wraps the output into a given function
call. For safety, all user-specific data will be restricted. » —
[2] « action=edit * Create and edit pages. [...] This module only
accepts POST requests. »
--
Jérémie
Ilmari Karonen
>> And there's a handy property to determine if you have new messages:
>> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
>
> Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].
>
> [1] « callback - If specified, wraps the output into a given function
> call. For safety, all user-specific data will be restricted. » —
Hmm, true. You might be able to emulate the functionality by using
prop=info on the user's talk page (and perhaps storing the last time the
user visited the page in a cookie).
(Ps. It strikes me that the simplest and most efficient way to implement
cross-wiki user talk notifications would be as a MediaWiki extension.
Why do we not have one already?)
--
Ilmari Karonen
Platonides
> On 01/11/2011 11:59 AM, Jérémie Roquet wrote:
>
>>> And there's a handy property to determine if you have new messages:
>>> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
>>
>> Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].
>>
>> [1] « callback - If specified, wraps the output into a given function
>> call. For safety, all user-specific data will be restricted. » —
>
> Hmm, true. You might be able to emulate the functionality by using
> prop=info on the user's talk page (and perhaps storing the last time the
> user visited the page in a cookie).
>
> (Ps. It strikes me that the simplest and most efficient way to implement
> cross-wiki user talk notifications would be as a MediaWiki extension.
> Why do we not have one already?)
Nobody has written it yet.
It would be like GlobalUsage. One big table listing data from all wikis.
Although it should be able to take advantage from CentralAuth, adding a
field into localuser table.
Jérémie Roquet
> On 01/11/2011 11:59 AM, Jérémie Roquet wrote:
>>> And there's a handy property to determine if you have new messages:
>>> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
>>
>> Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].
>>
>> [1] « callback - If specified, wraps the output into a given function
>> call. For safety, all user-specific data will be restricted. » —
>
> Hmm, true. You might be able to emulate the functionality by using
> prop=info on the user's talk page (and perhaps storing the last time the
> user visited the page in a cookie).
Hi again. Sorry for the late reply (as I read most of wikitech-l
threads in batch, I missed that one after the subject change).
Yes, that's a good idea and I think I'll do something like this. Thanks!
> (Ps. It strikes me that the simplest and most efficient way to implement
> cross-wiki user talk notifications would be as a MediaWiki extension.
> Why do we not have one already?)
Sure. It would be both far more efficient and easier to set up.
I guess I should really dive into MediaWiki development…
Best regards,
--
Jérémie
Platonides
> 2011/1/11 Ilmari Karonen <nos...@vyznev.net>:
>> On 01/11/2011 11:59 AM, Jérémie Roquet wrote:
>>>> And there's a handy property to determine if you have new messages:
>>>> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg
>>>
>>> Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1].
>>>
>>> [1] « callback - If specified, wraps the output into a given function
>>> call. For safety, all user-specific data will be restricted. » —
>>
>> Hmm, true. You might be able to emulate the functionality by using
>> prop=info on the user's talk page (and perhaps storing the last time the
>> user visited the page in a cookie).
>
> Hi again. Sorry for the late reply (as I read most of wikitech-l
> threads in batch, I missed that one after the subject change).
>
> Yes, that's a good idea and I think I'll do something like this. Thanks!
>
>> (Ps. It strikes me that the simplest and most efficient way to implement
>> cross-wiki user talk notifications would be as a MediaWiki extension.
>> Why do we not have one already?)
>
> Sure. It would be both far more efficient and easier to set up.
> I guess I should really dive into MediaWiki development…
>
> Best regards,
Feel free to send us patches. :)
See my previous message about using CentralAuth for that. CentralAuth
extension is not really an entry level extension, but you may have luck
since you would just be adding hooks.
Happy-melon
"Platonides" <plato...@gmail.com> wrote in message
news:4D34A033...@gmail.com...
> CentralAuth is not really an entry level extension, but you may have luck
> since you would just be adding hooks.
Now there's the understatement of the week...
:-D
--HM
George Herbert
>
> "Platonides" <plato...@gmail.com> wrote in message
> news:4D34A033...@gmail.com...
>> CentralAuth is not really an entry level extension, but you may have luck
>> since you would just be adding hooks.
>
> Now there's the understatement of the week...
>
> :-D
>
> --HM
"Glue! I need Glue!"
--
-george william herbert
george....@gmail.com
Daniel Friesen
> On Mon, Jan 17, 2011 at 3:58 PM, Happy-melon<happy...@live.com> wrote:
>> "Platonides"<plato...@gmail.com> wrote in message
>> news:4D34A033...@gmail.com...
>>> CentralAuth is not really an entry level extension, but you may have luck
>>> since you would just be adding hooks.
>> Now there's the understatement of the week...
>>
>> :-D
>>
>> --HM
> "Glue! I need Glue!"
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Jérémie Roquet
> Jérémie Roquet á écrit:
>> I guess I should really dive into MediaWiki development…
> See my previous message about using CentralAuth for that. CentralAuth
> extension is not really an entry level extension, but you may have luck
> since you would just be adding hooks.
Yeah, thanks for the clues :-)
--
Jérémie