WP_HTML_Tag_Processor overview issue

[adamziel]

• Part of Block API #41236.

The follow-up work once the #42485 is merged:

• Handle HTML entities for the purposes of get_attribute and set_attribute. Define what should happen in cases such as $p->set_attribute( 'id', 'My‐id' ); and $p->get_attribute( 'id' ) when id="My‐id".
  • Add/html character reference decoder #47040
  • Tag Processor: Document and test XSS prevention in set_attribute #44447
  • Tag Processor: throw when supplied unacceptible attribute names. #44431
  • Decide whether on* attributes should be banned in set_attribute( ) to make adding inline JavaScript harder (see @peterwilsoncc's comment and the reasoning behind not banning them).
• Improve the documentation
  • A handbook page
  • New HTML Tag Processor - An in-depth tutorial developer-blog-content#75
  • Review the documentation blocks.
  • Improve description for keys in test data providers that use numeric values (example).
  • Tag processor: update @since version tags to 6.2.0 #44432
  • Expand class-level documentation for WP_HTML_Tag_Processor #44478
• New APIs
  • WIP: Introduce class for sourcing block attributes from HTML #46345
  • Tag Processor: Add bookmark invalidation logic #47559
  • WP_HTML_Processor: Add set_content_inside_balanced_tags #47036
  • Explore HTML parsing and Adoption Agency Algorithm adamziel/wordpress-develop#1
  • WP_HTML_Tag_Processor: Allow non-attribute lexical updates #47068
  • Explore adding a has_next_tag method
  • Tag Processor: Add bookmark system for tracking semantic locations in document #46018
• Basic API
  • Tag Processor: Remove the shorthand next_tag( $tag_name ) syntax #45082
  • Tag Processor: Add get_updated_html as a non-toString method of stringifying the markup #44597
  • Add a has_class method to the public WP_HTML_Tag_Processor API #46232 (rationale)
    (Try adding layout classnames to inner block wrapper #44600 (comment)))
• HTML Tag Processor: Add WP 6.3 compat layer #47933
• Find a canonical way of stringifying the processor. One that's different from (string) $w (related comment). Done: @w->get_updated_html()

Code is located in two folders:

• https://github.com/WordPress/gutenberg/tree/trunk/lib/experimental/html
• https://github.com/WordPress/gutenberg/tree/trunk/phpunit/html

cc @gziolo @dmsnell @georgeh

[azaozz]

Frankly I think #42485 was not ready for merging. Seems it lacks any security features, references, docs, how-to's, etc. Even doesn't mention what security and escaping requirements it has. It seems open to exploits in its current state.

This issue mentions some of that, but misses few things. For example validity of new attribute names. Also, it doesn't mention the needed security related inline docs and examples which are crucial for new APIs.

As I commented on #42485 (comment) the security side of this API still awaits a decision. Imho it needs to implement some restrictions that will make is much more robust and problems-free in the future, and now is the time for these restrictions. If this is not done (in time) there is a risk that WP will end up with another exploits-prone API just like the shortcodes. If you don't believe me please see the huge, slow, cumbersome regex-based shortcodes sanitization functions that had to be added in order to try to secure badly written, exploitable code in plugins. Please consider restricting the illegal chars in attribute names and html-entity encoding the htmlspecialchars in attribute values!

Also see #42485 (comment).

[adamziel]

@azaozz – #42485 was merged to continue iterating in smaller PRs, not because every kink was worked out. I agree with your points about html-entity encoding and restricting illegal chars. The former is now merged, the latter is in motion. The list of todos also reflects updating the docs.

About this point:

Decide whether on* attributes should be banned in set_attribute( ) to make adding inline JavaScript harder (see @peterwilsoncc's comment).

I don't think there's an effective way to do that. Say we restrict onclick. The developer can just work around it like this:

$p->set_attribute( '__onclick', 'alert()' );
$markup = str_replace( '__onclick', 'onclick', $p );

Notably, the processor does not allow injecting new tags, so there's no risk of injecting a rogue <script> tag. I'll mark that todo as completed for now – if anyone disagrees please speak out.

[adamziel]

Find a canonical way of stringifying the processor. One that's different from (string) $w.

A getter like $p->getUpdatedHTML() or a magic property like $p->updatedHTML could do the trick here. I mean that in addition to having __toString(), not as a replacement.