My plugin removed from WP.org extend directory

[Ryan]

Hmm can the users write > then?

They can with wp_filter_nohtml_kses(). And since using > characters in CSS is useless I'll go filter those out too.

EDIT: I'm now using htmlspecialchars( wp_filter_nohtml_kses()) which seems to be doing a good job of stripping out all the stuff I don't want, while still allowing legit CSS to stay.

EDIT 2: I'm using those functions on input to the database and when echo'd into the admin page and on the front-end of the site, so hopefully that covers all my bases.

EDIT 3: Actually > and < characters are useful in CSS, so I guess I can't do that after all :( Damnit!

EDIT 4: All Google searches I try to do on validating CSS, keep showing up information about direct CSS validation, eg: the W3C CSS validator :(

[andreasnrb]

> is a css selector

[Ryan]

> is a css selector

Yup. I forgot about that :P I must have edited my post just before you replied.

I now have to go back and undo it all :(

EDIT: Fixed back the way they were :) I did add htmlspecialchars() to a bunch other stuff that needed it though so it wasn't all a waste of time thankfully :)

EDIT 2: Dangnabbit! I was looking at the output on screen and didn't click that the > and < characters were converted to their entity form. Damnit!!!! Back to the drawing board ...

[Utkarsh]

Ah, that makes sense based on it's name. The codex page just says what it strips out and it seems that the fixes for the LightSEO plugin uses it to filter out a textarea's content, which is what I'm using it for here, specifically for entering CSS code.



No, but you can in CSS which is what I'm trying to filter.


I think wp_filter_nohtml_kses() is what I need to use, so I'll plow ahead and use that unless anyone suggests otherwise.

If you want to filter css, why don't you see how the plugin WordPress.com team released (custom css plugin) does it?
Edit: This one http://wordpress.org/extend/plugins/safecss/

[andreasnrb]

Damned if you do damned if you don't =). But stripping out javascript and making sure " and ' are closed is all you need I suppose.
EDIT
They use CSSTidy http://csstidy.sourceforge.net/

[Ryan]

CSS Tidy is a little overkill. That's more for optimisation of the CSS code, rather than the just doing security checks.

That Automattic plugin was a darn good suggestion to look at though!

I've only had a quick flick through the code, but from what I can see, they are actually using wp_kses() and then rewriting the entities back intto their corresponding characters.

         $css = str_replace( '<=', '&lt;=', $css );
        // Why KSES instead of strip_tags?  Who knows?
        $css = wp_kses_split($prev = $css, array(), array());
        $css = str_replace( '&gt;', '>', $css ); // kses replaces lone '>' with &gt; 
  

[andreasnrb]

I like the comment // Why KSES instead of strip_tags? Who knows?

[chipbennett]

So, can someone tell me why an un-patched version of AIOSEO Pack is still available in the repository?

Have we been given any justification for removing Alden's plugin without notice, yet leaving AIO SEO available, even after weeks of notice of the vulnerabilities?

[andreasnrb]

We can't disclose such information =).

[Otto]

Ummm, well that's interesting ...

That would certainly explain why there is next to no documentation whatsoever on how to use white listing.

Yep. register_setting adds the option being registered to the whitelist. That's actually the main purpose of it. A secondary purpose is to add the sanitize callback function to it. The way this works is surprisingly simple.

register_setting is just a wrapper around add_option_update_handler.

add_option_update_handler adds the option to the "new_whitelist", and adds the callback to the sanitize_option_{$option_name} filter.

In the wp-admin/option.php file, where options get processed and saved, the whitelist_options filter gets applied. This calls the option_update_filter function, which goes through that list of options added to the "new_whitelist", and adds them to the real whitelist.

That whitelist is used, on the submit of the options page, to eliminate invalid options. Basically, it loops through the whitelisted options for the given page and only pulls those out of the $_POST array, discarding everything else.

Oh, and sanitize_option_{$option_name} is one of the first things that gets called on any update_option. Basically, it protects your options against even internal updates.

So, short version: If you use the Settings API properly, you don't have to screw with whitelisting and update_option and nonces and all that other crap. It's all handled for you transparently. All you have to do is to register your settings and provide the necessary callbacks to a) produce the input fields and b) validate the incoming values.