2009/8/15 Daniel Friesen lists@nadir-seen-fire.com:

Add a &ctype= param?

That would require sanitization anyway. I haven't forgotten why &format=txt and &format=dbg use text/text instead of text/plain : if the MIME type is text/plain and IE thinks it looks like HTML, it'll parse it as HTML, triggering some nice HTML and JavaScript injection vulnerabilities.

Roan Kattouw (Catrope)

Turns out IE prompts the user to save the file irregardless of "application/json" to 'text/javascript' format. (if its not include via script tag )

Instead of witting or integrate an XML -> json converter that matches the xml output with the json output ... I am inclined to just quickly add a param that lets us output the json to "text/plain" purely because its faster to integrate. added in r55113

for now this just solves the specific issue of submitting a enctype="multipart/form-data" form to an iframe target and getting the response in similar way that you grab other json api request.

Also added type output per: http://simonwillison.net/2009/Feb/6/json/#c43376

I don't see this as posing security risk as its just a mime type interpretation issue the normal cross site ajax restrictions are still in place. (ie you cant do an cross site iframe and view the result of the output)

On the topic... I eventually I do want to support a iframe api proxy system. Initially just for inner-site uploading ie uploading an image to commons while editing a wikipedia article. But after that want to think more broadly about iframe proxies so we can do all the fancy "facebook connect" type systems and full editable mediawiki api engagement from user-trusted external sites and participation contexts. (ie imagine a /volunteerlet/ that use give you a 10 second task based on your user profile ie translate x know user proficient language to y proficient language ) embeddable in any web context. (will follow up with more detailed proposal to wikitech-l and of-course more code ;)

peace, --michael

Roan Kattouw wrote:

2009/8/15 Michael Dale mdale@wikimedia.org:

...

Would anyone object to changing the output mime type of ApiFormatJson.php from "application/json" to 'text/javascript' ? committed in r55084

This is needed for iframe target background upload tasks. ie you upload a file and then you want to take the name of the file you uploaded and use that to insert the image into the edit window. With mime as "application/json" the browser promts the user to "save" the file and we can't eval the document text result in the iframe.

A good suggestion I read at http://simonwillison.net/2009/Feb/6/json/#c43376 is to use text/javascript only for &format=json when a callback is used, and use application/json when it's not (&format=jsonfm uses text/html in all cases, of course).

Roan Kattouw (Catrope)

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Michael Dale wrote:

Turns out IE prompts the user to save the file irregardless of "application/json" to 'text/javascript' format. (if its not include via script tag )

Instead of witting or integrate an XML -> json converter that matches the xml output with the json output ... I am inclined to just quickly add a param that lets us output the json to "text/plain" purely because its faster to integrate. added in r55113

for now this just solves the specific issue of submitting a enctype="multipart/form-data" form to an iframe target and getting the response in similar way that you grab other json api request.

Also added type output per: http://simonwillison.net/2009/Feb/6/json/#c43376

I don't see this as posing security risk as its just a mime type interpretation issue the normal cross site ajax restrictions are still in place. (ie you cant do an cross site iframe and view the result of the output)

The problem is not the expected usage.

Can you confirm that viewing something like http://test.wikipedia.org/w/api.php?action=query&prop=revisions&titl... on Internet Explorer won't get the javascript executed?

Because we need to upload a file. Only firefox 3.5 support XHR file uploads. The rest of the browsers have to target an iframe to not cause the page to refresh.

--michael

Roan Kattouw wrote:

2009/8/15 Michael Dale mdale@wikimedia.org:

...

This is needed for iframe target background upload tasks. ie you upload a file and then you want to take the name of the file you uploaded and use that to insert the image into the edit window. With mime as "application/json" the browser promts the user to "save" the file and we can't eval the document text result in the iframe.

Why use an iframe? Why not something like $.post(), or if that doesn't upload properly, build a form and submit it?

Roan Kattouw (Catrope)

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

On Sun, Aug 16, 2009 at 12:01 AM, Roan Kattouwroan.kattouw@gmail.com wrote:

So you're putting a form in an iframe and submitting that? Then you could consider using jsonfm instead and screenscrape it (getting the contents of the <pre> and stripping all tags from it should work), which is ugly as hell but will at least give you a nice and harmless text/html.

You're not serious in that right? That sounds like a horrible solution.

Better would be to run the output of the JSON module through IEContentAnalyzer and force application/json if the content is deemed dangerous.

Bryan

On Sun, Aug 16, 2009 at 12:11 AM, Roan Kattouwroan.kattouw@gmail.com wrote:

...

Better would be to run the output of the JSON module through IEContentAnalyzer and force application/json if the content is deemed dangerous.

On the server side? We do some stuff to stop IE from screwing up, but that's over the top IMO.

It's way more sane than requiring the user to do some kind of screen scraping. And after all, that is why Tim actually wrote the IEContentAnalyzer.

Bryan

2009/8/16 Michael Dale mdale@wikimedia.org:

the scraping the jsonfm solution actually worked pretty well  (tested in Firefox and IE6-8 )

var doc = iframe.contentDocument ? iframe.contentDocument : frames[iframe.id].document; json_str = $j(doc.body).find('pre').html(); return window["eval"]("(" +json_str + ")");

Yay!

The IEContentAnalyzer looks like an interesting solution as well... but this seems to work reasonably well for the time being.

If your backend wasn't already relying on JSON output, you could've requested XML output instead and that would've worked just fine without any security issues. Running stuff through IEContentAnalyzer just so we can put a wrong MIME type on it (text/plain is not appropriate for JSON, should be either application/json or text/javascript) is a bad idea. I see you've already removed the text/plain option, so it's now back to using text/javascript for callbacks and application/json instead.

Roan Kattouw (Catrope)