[wp-trac] [WordPress Trac] #33121: wp_kses_attr_check fails to process html data-* attributes

[WordPress Trac]

#33121: wp_kses_attr_check fails to process html data-* attributes
--------------------------------------+-----------------------
 Reporter:  isoftware                 |       Owner:  (none)
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  5.0
Component:  Editor                    |     Version:  4.2.3
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------

Comment (by azaozz):

 Replying to [comment:17 peterwilsoncc]:
 > This (two hyphens or end hyphen) is true but it does some strange things
 to the `element.dataset` property available in JavaScript

 Good point. Lets not allow it :)

 > I'm not sure this (overriding of unset attributes) is the case if we
 require the hyphen following any prefixes, so a developer won't be able to
 add `href-*` and bypass checking.

 Ah, I see, my error. The regex matches only attribute names that have a
 hyphen.

 I'm still not sold on supporting all of these attribute names "globally"
 with no possibility to check the values. Except `data-*`, none of them
 have variable names and imho should be added the same way like the rest of
 the attributes are added: by full name.

 In any case, what is the purpose of allowing all attributes with a hyphen?
 - It would support `data-*` which we should have.
 - It would also support `aria-*` which would be nice to have. There are
 about 45 aria attributes and many of them have a list of possible values,
 like:
 {{{
     aria-busy ( true | false ) 'false'
     aria-checked ( true | false | mixed | undefined ) 'undefined'
     aria-disabled ( true | false ) 'false'
     aria-expanded ( true | false | undefined ) 'undefined'
     aria-grabbed ( true | false | undefined ) 'undefined'
     aria-hidden ( true | false ) 'false'
     aria-invalid ( grammar | false | spelling | true ) 'false'
     aria-pressed ( true | false | mixed | undefined ) 'undefined'
     aria-selected ( true | false | undefined ) 'undefined'
 }}}

 (see http://www.w3.org/MarkUp/DTD/aria-attributes-1.mod)

 For a security/sanitizing function I'd expect all of these to be hard-
 coded, both the attribute name and possible values, after a security audit
 of whether any of the values may be misused. Again, this is inline with
 how KSES works.

 Apart from `data-*` and `aria-*` there are `accept-charset` and `http-
 equiv` (see https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes).
 Don't think it makes sense supporting these.

 Am I missing something? Are there other user cases for allowing attributes
 with a hyphen and not support checking of their values?

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