Press This vulnerabilities

[xknown]

After the lasts commits, Press This is again vulnerable to XSS.

http://localhost/wp/wp-admin/press-this.php/?ajax=video&s=%3C/textarea%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
http://localhost/wp/wp-admin/press-this.php/?ajax=thickbox&i=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

(In [8235]) Escaping for Press This. see #7220

Committed a quick fix. Might need to pass true to format_to_edit() or use wp_richedit_pre() when dealing with the rich editor.

Take a look to photo_images, the pattern to retrieve images should be more restrictive or the result of that action should be urlencoded. For example, if a page contains the following text it makes WP vulnerable:

<img src="demo<script>alert(document.cookie)</script>">

I'll take a quick look at this, but will be out until next week. (Getting married!)

Fix for image src XSS injection

The newest regex should be sufficient to keep out any injection attacks.

(In [8237]) Don't match images with tags in them. Props noel. see #7220

Perhaps we should run the img src through kses.

Another problem I recently found is that users without unfiltered_upload capability are able to download any file via the media_sideload_* to the tmp dir (get_temp_dir() will return WP_CONTENT_DIR if it's writable), so when wp_handle_sideload fails (because of wp_check_filetype check) it will not delete the temporary file that was downloaded in the previous step.

Steps to reproduce the problem:

• Log in as an unprivileged user, but with publish_post capability and go to http://localhost/wp/wp-admin/press-this.php.
• Select "Photo" tab, after that click on "Add from URL +" and then enter any url. ie http://localhost/dummy.php
• Now insert a link into the content box <a href="http://localhost/dummy.php">dummy</a> -- it's used to ensure that there is a reference to the fake image.
• Click on "Publish" button.

The post won't be inserted but like I said, if WP_CONTENT_DIR is writable the temporary file won't be deleted.

By the way, [8237] still doesn't solve the issue, you can actually execute JS if a page contains something like:

<img src="');alert(document.cookie);///.jpg">

Yeah, I think we need kses for that.

(In [8240]) Clean image urls in get_images_from_uri(). see #7220

(In [8241]) Unlink temporary file if sideload fails. see #7220

Temp file is now unlinked on failure. I'm not really sure what the point of the sideload is though.

The sideload is to connect with the media library even if you can't do a POST. Faking a POST was an option, but not an elegant one. Andy and Andrew nudged me in the direction of creating a sideload function for ajax type loading.

I'm out till mid-next week.

(In [8302]) Don't format_to_edit TinyMCE inserts. Don't turn selection into a link. Restore editor contents when switching back to text tab. see #7261 #7220