2009/8/15 Daniel Friesen <lists(a)nadir-seen-fire.com>om>: 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:

Michael Dale wrote: 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&tit… 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:

On Sun, Aug 16, 2009 at 12:01 AM, Roan Kattouw<roan.kattouw(a)gmail.com> wrote: 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 Kattouw<roan.kattouw(a)gmail.com> wrote: 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(a)wikimedia.org>rg>: Yay! 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)