Make WordPress Core

Opened 16 years ago

Closed 16 years ago

Last modified 6 years ago

#7220 closed defect (bug) (fixed)

Press This vulnerabilities

Reported by: xknown's profile xknown Owned by: ryan's profile ryan
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.6
Component: Security Keywords:
Focuses: Cc:


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


Attachments (1)

press-this-7-2-410am.diff (1.1 KB) - added by noel 16 years ago.
Fix for image src XSS injection

Download all attachments as: .zip

Change History (19)

#1 @ryan
16 years ago

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

#2 @ryan
16 years ago

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

#3 @ryan
16 years ago

  • Owner changed from anonymous to noel

#4 @xknown
16 years ago

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

#5 @noel
16 years ago

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

16 years ago

Fix for image src XSS injection

#6 @noel
16 years ago

  • Owner changed from noel to ryan

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

#7 @ryan
16 years ago

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

#8 @ryan
16 years ago

Perhaps we should run the img src through kses.

#9 @xknown
16 years ago

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.

#10 @xknown
16 years ago

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

#11 @ryan
16 years ago

Yeah, I think we need kses for that.

#12 @ryan
16 years ago

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

#13 @ryan
16 years ago

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

#14 @ryan
16 years ago

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

#15 @noel
16 years ago

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.

#16 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#17 @ryan
16 years ago

(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

This ticket was mentioned in Slack in #core-editor by talldanwp. View the logs.

6 years ago

Note: See TracTickets for help on using tickets.