[wp-trac] [WordPress Trac] #22135: Special characters in caption lead to failure of inserting images

WordPress Trac noreply at wordpress.org
Wed Feb 12 20:22:19 UTC 2014


#22135: Special characters in caption lead to failure of inserting images
-----------------------------------+------------------------------
 Reporter:  TobiasBg               |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Media                  |     Version:  3.4.2
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+------------------------------
Changes (by TobiasBg):

 * keywords:  2nd-opinion => 2nd-opinion has-patch


Comment:

 I investigated this some more, and the problem is the argument that is
 passed to the JS `send_to_editor` function via PHP, in
 [https://core.trac.wordpress.org/browser/trunk/src/wp-
 admin/includes/media.php#L227 this line] of `wp-admin/includes/media.php`.
 Basically, `addslashes()` is not enough to protect against an input of
 {{{
 foo</script>bar
 }}}
 (in the Caption field in the old media uploader) prematurely ending the
 JS. This results in a script error, so that the remaining output is
 printed in the frame (as in the screenshot above).
 Compare this generated HTML/JS (some attributes from the `<img>` and
 `[caption]` stripped):
 {{{
 /* <![CDATA[ */
 var win = window.dialogArguments || opener || parent || top;
 win.send_to_editor('[caption]<img src=\"http://example.com/img.jpg\" />
 foo</script>bar[/caption]');
 /* ]]> */
 }}}
 `addslashes()` only escaped the `'` and `"` but leaves `/` untouched. This
 is then a problem for any input that contains `</script>`, as that ends
 the `<script>` block early. For other closing HTML tags (like `</em>`)
 this is no problem however.

 Now, the old media uploader is no longer used by Core, but it's still
 being used in several plugins. And although this an edge case that can
 only be triggered with `</script>`, the fix is very easy: Let's use
 `json_encode()` instead of `addslashes()`, as that also escapes all `/`.
 The attached patch [attachment:22135.patch] does that.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/22135#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list