Tag Archives: security

Thoughts on “Too Much Escaping” in WordPress

While sanitizing and escaping everything is very important when dealing with websites, I think there are times when we need to back off a little bit, and trust the functions that have been given to us by WordPress.

<a href="<?php echo esc_url( get_permalink( get_the_ID() ) ); ?>" title="<?php echo esc_attr( sprintf( __( 'Permanent Link to %s', 'domain' ), the_title_attribute( array( 'echo' => false ) ) ) ); ?>" >

I call that paranoia (and I see it in a lot of themes.) Dirty, difficult to read and understand, and even more difficult to spot an error. The permalink and the title attribute are never going to break out of the attributes syntax and escaping them a billion times doesn’t really help. Here’s a cleaner version for comparison:

<a href="<?php the_permalink(); ?>" title="<?php the_title_attribute( array( 'before' => __( 'Permanent link to ', 'domain' ) ) ); ?>" >

Quite straightforward and easy to understand. You don’t even need to worry about escaping the “before” text, because the_title_attribute will escape it for you. One might argue that explicit escaping (right at the output) is more secure than implicit escaping, but since functions prefixed with the_ are meant for output, I tend to trust their output. You just need to know where each one should go.

With that said, if you have a super hi-jacked WordPress installation with a malicious plugin overwriting the output of the functions mentioned above, there’s really not much you can do. Even if you triple espace with get_permalink, a plugin might just filter in on post_link and output whatever it needs to output by-passing all escaping.

Thoughts?



Just a reminder, since this weekend I had to help out with yet another TimThumb-powered WordPress theme, broken by a “security patch” at the web hosting provider. This time it was Acquisto by Press75. The problems of Acquisto are not limited to thumbnails.



Protected Meta in WordPress

I was doing a few tweaks to the Twitter Embed plugin earlier today and found out that authors that access to the custom fields interface could exploit them to print unfiltered HTML. This happened because I cached the HTML retrieved from the Twitter API in an unprotected meta field to the post.

The easiest workaround was to add an underscore prefix to the meta key, so my_meta_key for example, would become _my_meta_key. For a second though, I thought that somebody might type in the underscore in the custom fields interface too, so I spent a few minutes reading the admin ajax source code.

It turns out that there is a call to a function called is_protected_meta defined in meta.php, which does the check for the preceding underscore, so the custom fields interface will not allow working with protected meta fields no matter on what user level, which is good! It still allows themes and plugins to use get_post_meta and update_post_meta.

So the lesson learned today — if you’re storing sensitive data in your post meta fields, don’t forget to protect them from eyes by prefixing your meta keys with underscores.



Wired News & Twitter

I’ve read an entry in the livejournal webdev community today – a link to a great blog post on Wired News about “the battle of the browsers”. Following the link I got onto the Wierd News Blogs website, and with a timeout of about 5 seconds I received a javascript popup message asking for my Twitter username and password. This looks like scam. Why the heck would a PR9 news resource do this?

Wired News Twitter