Ticket #7220 (closed defect: fixed)

Opened 5 months ago

Last modified 5 months ago

Press This vulnerabilities

Reported by: xknown Assigned to: ryan
Priority: normal Milestone: 2.6
Component: Security Version: 2.6
Severity: normal Keywords:
Cc:

Description

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

Attachments

press-this-7-2-410am.diff (1.1 kB) - added by noel on 07/02/08 08:18:18.
Fix for image src XSS injection

Change History

07/02/08 02:23:13 changed by ryan

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

07/02/08 02:24:36 changed by ryan

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

07/02/08 02:24:47 changed by ryan

  • owner changed from anonymous to noel.

07/02/08 04:04:14 changed by xknown

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>">

07/02/08 08:04:36 changed by noel

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

07/02/08 08:18:18 changed by noel

  • attachment press-this-7-2-410am.diff added.

Fix for image src XSS injection

07/02/08 08:19:02 changed by noel

  • owner changed from noel to ryan.

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

07/02/08 15:26:56 changed by ryan

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

07/02/08 15:27:22 changed by ryan

Perhaps we should run the img src through kses.

07/02/08 16:47:42 changed by xknown

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.

07/02/08 17:09:40 changed by xknown

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">

07/02/08 19:21:26 changed by ryan

Yeah, I think we need kses for that.

07/02/08 22:40:53 changed by ryan

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

07/02/08 22:56:57 changed by ryan

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

07/02/08 22:58:00 changed by ryan

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

07/02/08 23:24:44 changed by noel

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.

07/08/08 17:35:43 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

07/09/08 19:51:53 changed by ryan

(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