[theme-reviewers] Why Rigorous Review of Theme Functional Files is Important

[Chip Bennett]

And kses doesn't catch that? Hmm... I'll have to take a look at what
JetPack does. :)


On Thu, Jan 30, 2014 at 1:45 PM, Konstantin Kovshenin
<kovshenin at gmail.com>wrote:

> It's not just the HTML you have to be worried about, but something
> like this
> http://www.thespanner.co.uk/2007/11/26/ultimate-xss-css-injection/
>
> On Thu, Jan 30, 2014 at 10:39 PM, Chip Bennett <chip at chipbennett.net>
> wrote:
> > Really dumb question, but if you're just talking about the CSS itself
> (and
> > not the <script> wrappers), why can't you just pass it through
> > wp_filter_nohtml_kses()?
> >
> >
> > On Thu, Jan 30, 2014 at 12:36 PM, Otto <otto at ottodestruct.com> wrote:
> >>
> >> On Thu, Jan 30, 2014 at 11:20 AM, Chip Bennett <chip at chipbennett.net>
> >> wrote:
> >>>
> >>> It is true that a good custom CSS Plugin will save settings on a
> >>> per-Theme basis. But the critical criterion isn't whether a Plugin
> *can* do
> >>> something; rather, it is whether the *something* is functional or
> >>> presentational. After all, technically speaking, a Plugin *can* add
> Theme
> >>> support for custom headers and custom backgrounds. Should we force
> Theme
> >>> developers then to use a custom header/background Plugin, simply
> because one
> >>> exists and can accomplish the task?
> >>>
> >>> Custom CSS is presentational, and specific to the Theme. As such, I
> >>> believe it falls squarely within the purview of Themes, and if Themes
> want
> >>> to provide a custom CSS Theme option, such an option would be
> appropriate.
> >>
> >>
> >>
> >> Note: Sanitizing CSS is friggin' hard. A mere strip_tags isn't good
> >> enough.
> >>
> >> The custom CSS module in Jetpack uses csstidy and a few pre-processors,
> >> among other things. But the basic sanitization function would look like
> >> this:
> >>
> >> function dumb_css_sanitize( $css ) {
> >> $css = str_replace( '<=', '<=', $css );
> >> $css = wp_kses_split( $css, array(), array() );
> >> $css = str_replace( '>', '>', $css );
> >> $css = strip_tags( $css );
> >> return $css;
> >> }
> >>
> >> I named it dumb_css_sanitize because it's kinda dumb. ;)
> >>
> >> It allows <= patterns through as LT entities, runs kses over the thing
> to
> >> strip tags, converts the > symbols back from what kses did, and then
> runs
> >> strip_tags over it again, just in case. It's fairly safe in that you
> >> couldn't close the style tag with content run through it and therefore
> get
> >> your content parsed as html or script code. Probably.
> >>
> >> This is sort of a minimalistic case. Better to use a real parser if
> you're
> >> going to do that sort of thing.
> >>
> >> -Otto
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> theme-reviewers mailing list
> >> theme-reviewers at lists.wordpress.org
> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >>
> >
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
>
>
>
> --
> Konstantin
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140130/164cb285/attachment.html>