[wp-trac] [WordPress Trac] #33102: Shortcodes with Quoted Attributes Break Inside of Quoted HTML Attributes

WordPress Trac noreply at wordpress.org
Fri Jul 24 11:50:08 UTC 2015


#33102: Shortcodes with Quoted Attributes Break Inside of Quoted HTML Attributes
--------------------------+------------------------------
 Reporter:  cgrymala      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Shortcodes    |     Version:  4.2.3
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------

Comment (by georgestephanis):

 Replying to [comment:15 dnavarrojr]:
 > Regular Expressions have never been a strong suite, however I have
 written dozens of mathematical parsers and based on what I know from that
 process, I would have to agree with your assessment.  The correct way to
 handle this is to parse the shortcodes first and ignore the HTML, which is
 how I *think* it worked before the patch.  In fact, I'm not sure why it's
 doing ANY HTML parsing at all.

 I believe some of the problem on that is a question of the kses'ing.
 Either you scan for nasty script injections before or after processing the
 shortcodes.  Scanning after doesn't work, as many plugins and oembeds are
 written explicitly to convert shortcodes into safe, known quantities with
 safe script tags and such.  Scanning before is the problem that you seem
 to be having here.  After all, someone may actually want to do something
 like ...


 {{{
 <img src="#" title="[foo bar=" baz=" nope]">
 }}}

 Which is totes ambiguous, and could be parsed reasonably as either


 {{{
 <img
     src="#"
     title="[foo bar="
     baz=" nope]"
 >
 }}}

 an image with three attributes -- src, title, baz -- or:

 {{{
 <img
     src="#"
     title="
         [foo bar=" baz=" nope]
     "
 >
 }}}

 An image with two attributes, the second containing a shortcode `foo` with
 two attributes -- `bar` being set equal to ` baz=` and `nope` which is
 just present.

 Using different quotes is how to resolve the ambiguity.  I don't think
 it's possible for WP to automatically resolve such ambiguity correctly and
 safely.  (happy to be proven wrong, just trying to explain it in a way
 that I'm not sure I'd seen up above)

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


More information about the wp-trac mailing list