[wp-trac] [WordPress Trac] #48955: WP 5.3.1 changes cause potential backwards compatibility breakage with kses

[WordPress Trac]

#48955: WP 5.3.1 changes cause potential backwards compatibility breakage with kses
--------------------------+---------------------
 Reporter:  iCaleb        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.3.3
Component:  Security      |     Version:  5.3.1
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by aduth):

 Replying to [comment:17 RyanNovotny]:
 >does block parsing on it (bad)

 Can you elaborate on this? While "block parser" might seem worryingly
 opaque as an apparently expensive process, the actual implementation does
 pretty well to treat non-block HTML as a trivial operation. It effectively
 amounts to a single
 [https://github.com/WordPress/WordPress/blob/5d5bf01d12f7707c3844e3142b18e0c479f019e1
 /wp-includes/class-wp-block-parser.php#L404-L428 regular expression match]
 and
 [https://github.com/WordPress/WordPress/blob/5d5bf01d12f7707c3844e3142b18e0c479f019e1
 /wp-includes/class-wp-block-parser.php#L265-L269 string concatenation].

 The reason for running all HTML through the parser is a combination of:

 - Lack of context in knowing how the HTML will be used, deferring to the
 safest, widest application of the block escaping.
 - Mirroring the exact treatment of markup as it is processed via the
 `the_content` filter (which already also
 [https://github.com/WordPress/WordPress/blob/5d5bf01d12f7707c3844e3142b18e0c479f019e1
 /wp-includes/blocks.php#L524-L548 parses all incoming HTML] using the
 block parser)

 Whether the application of escaping could be scaled back based on certain
 conditions would need to be evaluated very carefully in consideration of
 the security implications in allowing a regression of the previous
 abusable behavior. Since discussion of these improvements are not directly
 related to this ticket in question, a separate ticket would be most
 appropriate.

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