WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#14648 closed defect (bug) (wontfix)

Flash Uploader security error in IDN domains

Reported by: dovydas Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.3
Component: Media Keywords:
Focuses: Cc:

Description

How to recreate:

  1. Install wodpress on site with IDN domain name.
  2. Try uploading image using Flash Uploader.
  3. Your upload will fail with "Security Error".

This problem also reffered on support forums:
http://wordpress.org/support/topic/flash-uploader-security-error-problem?replies=8
http://wordpress.org/support/topic/image-uploader-and-internationalized-domain-names-idn?replies=1

Change History (10)

comment:1 follow-up: hakre4 years ago

Is the 2.8.3 Blog where you get this working running on a IDN domain as well?

Slightly Related: #10825

comment:2 in reply to: ↑ 1 dovydas4 years ago

Replying to hakre:

Is the 2.8.3 Blog where you get this working running on a IDN domain as well?

2.8.3 blog that has Flash Uploader working is ASCII domain.

I have just made fresh 2.8.3 installation on new IDN domain to test Flash Uploader.
Flash Uploader on 2.8.3 on an IDN domain failed with "security error" the same as in wordpress 3.0.1 on an IDN domain.

To summarize:
2.8.3 on ASCII domain = working
3.0.1 on ASCII domain = working

2.8.3 on IDN domain = not working
3.0.1 on IDN domain = not working

All plugins were switched off and default theme was used (fresh installation).

comment:3 nacin4 years ago

From SWFUpload's site: SECURITY_ERROR - The upload violates a security restriction. This error is rare.

I believe this has to do with the browser thinking this is a cross-domain upload. Do you have a crossdomain.xml at the root of your server? That should solve it.

Unfortunately there's not much we can do here, as there's no guarantee we're at the root of the server. We *could* potentially handle this the way we handle robots.txt, that if we do have rewriting and we are at the root, then we can serve something. But generating this file is a security issue, not to mention that we'd need to detect what I imagine are the two different domains, the IDNA and ASCII... Sounds like an unfortunate limitation of SWFUpload and Flash perhaps?

comment:4 dovydas4 years ago

I have created crossdomain.xml in server root with the following content:

# cat crossdomain.xml

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>

<allow-access-from domain="*" />

</cross-domain-policy>

Unfortunately that didn't change anything.
I still receive security error...
Please can anyone confirm that my crossdomain.xml syntax is correct?

comment:5 dkwo3 years ago

  • Cc dkwo added

This is the exact problem I'm having -- Security Error with WordPress 3.0.1 on IDN domain.

This is a confirmed bug in SWFUploader 2.2.0 (the one WordPress 3.0.1 is using,) and according to the dev home page of SWFUploader looks like it has been fixed from 2.2.0.1.

Also regarding crossdomain.xml, I've been researching about this and am pretty sure that my crossdomain.xml is legitimate, it seem to be SWFUploader's issue. For reference purpose this is my crossdomain.xml:

<?xml version="1.0"?>
<!--           http://ブログ.牙.jp/crossdomain.xml -->
<!-- http://xn--qckyd1c.xn--z1x.jp/crossdomain.xml -->
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <site-control permitted-cross-domain-policies="all" />
  <allow-access-from domain="*.牙.jp" />
  <allow-access-from domain="*.xn--z1x.jp" />
  <allow-access-from domain="59.106.171.76 " />
</cross-domain-policy>

It would be really helpful that issue can be solved.

comment:6 dovydas3 years ago

  • Cc dovydas added

Here is the WORKAROUND that helped me:

  1. Download. I have downloaded SWFUploader 2.2.0.1 (from here: http://code.google.com/p/swfupload/downloads/detail?name=SWFUpload%20v2.2.0.1%20Core.zip) and I have extracted zip archive.
  1. Backup. In the Wordpress directory wp-includes/js/swfupload/ I have renamed files swfupload.swf and swfupload.js to swfupload.swf.old and swfupload.js.old. Also I have renamed all *.js files in wp-includes/js/swfupload/plugins/ directory to *.js.old.
  1. Replace. Then I have copied new files swfupload.js and swfupload.swf to wp-includes/js/swfupload/ directory. Also I have copied all *.js files from SWFUploader 2.2.0.1 package /plugins/ directory to wp-includes/js/swfupload/plugins/ directory.

Flash uploader works for my IDN site now'''

Please note, hat you have to clear your browser cache. I thought it didn't work at first. I still received "security error". But then I tried a different browser with a clear cache and all of sudden I get my files uploaded!

Thank you dkwo for the tip.

comment:7 nacin3 years ago

  • Version set to 2.8.3

comment:8 SergeyBiryukov3 years ago

Looks like we're already using SWFUploader 2.2.0.1 since [11372].

I've compared the files in wp-includes/js with the ones from SWFUpload v2.2.0.1 Core.zip and they seem to be identical, except for SWFObject (2.2 vs 2.1).

I've tested Flash Uploader on IDN domain with Firefox 3.6.13, Chrome 9.0.597.84, IE 8.0.6001.18702 and Opera 11.01, all on Windows XP SP3. It works in Chrome and Opera, but throws “Security Error” message in Firefox and IE.

Presense of crossdomain.xml doesn't seem to have any difference. The suggestion by dovydas didn't work for me even after clearing the cache.

comment:9 codestyling3 years ago

  • Cc codestyling added
  • Keywords needs-patch dev-feedback added

IDN handling is different related to Browsers! WebKit based browser like Safari and Chrome work with PunyCode URL's but others like IE, Firefox and Opera doesn't.
This is a problem of Cross Site Scripting detection and can be realize and tested, if the Blog is configured to an PunyCode Url.

example out of a case I did investigate:
IDN: http://с-проект.рф
PunyCode: http://xn----jtbpoegeo.xn--p1ai

If you try to call a JSON request like this example with the generated admin_url() out of WordPress, which would become the PunyCode one:

	new Ajax.Request('http://xn----jtbpoegeo.xn--p1ai/wp-admin/admin-ajax.php' ?>', 
		{  
			parameters: {
				action: 'get_download_section'
			},
			onSuccess: function(transport) {		
				elem.title=transport.responseJSON.title;
			},
			onFailure: function(transport) {
				alert('JSON security bug')
			}
		}
	);

and the answer is correct 'application/json' with correct JSON content, than this fails on all browsers except WebKit based!
If you try it with the original IDN Url like:

	new Ajax.Request('http://с-проект.рф/wp-admin/admin-ajax.php' ?>', 

it works now for all other browsers but fails now on WebKit based.

My suggestion will be a conditional convertion back to IDN, if browser is not WebKit based.
I did this inside my WordPress plugin "Codestyling Localization" and it works now in any case. I did use the class idna_convert from Matthias Sommerfeld for easy decode of PunyCode admin url's in such a case.

Please check it also in relation to #11734 / #10690 / #14648 because this may also affect the flash uploader feeded with PunyCode url's instead of IDN for some browser!

comment:10 ocean903 years ago

  • Keywords needs-patch dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

WordPress is now using Plupload. Plupload uses HTML5 first and should fall back to flash only in IE if silverlight is not installed.

Please test if you still have issues with the media uploader in trunk.

See #18206 for the new file uploader.

Note: See TracTickets for help on using tickets.