[wp-trac] Re: [WordPress Trac] #8767: Refactored filters to avoid potential XSS attacks

[WordPress Trac]

#8767: Refactored filters to avoid potential XSS attacks
-------------------------------------------+--------------------------------
 Reporter:  sambauers                      |        Owner:  ryan 
     Type:  defect (bug)                   |       Status:  new  
 Priority:  high                           |    Milestone:  2.7.1
Component:  Security                       |      Version:  2.7  
 Severity:  major                          |   Resolution:       
 Keywords:  has-patch, needs-testing, XSS  |  
-------------------------------------------+--------------------------------
Comment (by link92):

 Replying to [comment:16 sambauers]:
 > Replying to [comment:14 link92]:
 > > Off the top of my head, any PCRE just silently fails to match
 anything, which without iconv would make this patch a huge void hole.
 >
 > Sorry, I misread your last comment.
 >
 > Yes, PCRE fails silently when it encounters bad UTF8. The
 wp_check_invalid_utf8() function exploits that to "detect" the bad UTF8.
 So if the preg_match() passes, it's not a bad string and it is returned.
 There is a "strip" option which will attempt to use iconv() but it is not
 utilised in any of the changes in this patch.
 >
 > From the patch...
 >
 > {{{
 >         // preg_match fails when it encounters invalid UTF8 in $string
 >         if ( 1 === @preg_match( '@^. at us', $string ) ) {
 >                 return $string;
 >         }
 > }}}

 Yeah, sure, but see [comment:6 link92] for shortcomings with even this.

 > Yes, if the installed PCRE doesn't support UTF8 then it will fail and
 the string will be blanked.
 >
 > We already require PCRE with UTF8 in at least one other place, but I
 could potentially detect for it's absence and return the string unscathed.
 >
 > Something like...
 >
 > {{{
 >         // Check that PCRE handles UTF8 - if not they are on their own
 >         if ( !@preg_match( '@^. at u', 'utf-ate nom nom nom' ) ) {
 >                 return $string;
 >         }
 > }}}
 >
 > ... then the test.

 Ah, I'm probably just confused because according to
 [[http://wordpress.org/about/requirements/]] WP doesn't even require PCRE,
 yet alone PCRE-with-Unicode-support (and there are plenty of copies of
 PCRE-without-Unicode-support out there). Either the patch needs changing,
 or the requirements need to be changed. I would not be surprised if
 requiring PCRE-with-Unicode cut out a larger number of users than
 requiring PHP 5 would cut out.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/8767#comment:17>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software