I spent a couple of hours yesterday trying to debug an issue that made me hit my head against the wall while it lasted.

I run multiple instances of WordPress, and with it, comes a nice little editor bundled called TinyMCE. But on my main WordPress installation (this very blog, dear reader, where you are reading this from), TinyMCE wouldn't come up, it wouldn't render properly on the browser, it didn't matter if it was my main browser, Chrome, or Firefox, Safari, cached, uncached, it was just broken. Since I hadn't have the time to go through this issue before, I was using a different editor installed as a plugin. LAME. And coward.

Anyway, I found out that one of the scripts wp-tinymce.php was being returned truncated. Because of that, Firebug would report that some TinyMCE bullshit wasn't defined (JavaScript, oh I'm not very fond of you). Oh, well. I tested calling that script under curl separately and in fact, it was only returning a fraction of the script, 44K out of the actual 200+K. I also found out that even though my nginx installation had gzip compression enabled and the PHP had zlib as well, the script wouldn't process the tinymce.js.gz but it was returning directly tinymce.js. It's alright, I just wanted it to work, no matter if it wouldn't go through gzip, that'd be a matter of some other day.

After a lot of googling I ended up reading this blog post (in Portuguese), suggesting to make sure the file permissions for both the client_body_temp and fastcgi_temp directories allowed the user running nginx (www-data in my case) to write in them. Apparently large scripts would start writing to disk on them temporarily while processing the shit. Of course, you wouldn't have this issue if you are running an nginx from your operating system package manager (like Debian's), but this might very well happen when you are running a custom nginx with separate modules and all sorts of crap on top of it:

chown www-data:www-data -R /usr/local/nginx/fastcgi_temp/;
chmod -R 777 /usr/local/nginx/fastcgi_temp/;
chown www-data:www-data -R /usr/local/nginx/client_body_temp/;
chmod -R 777 /usr/local/nginx/client_body_temp/;

Obrigado, republicavirtual.com.br

Continuing with my WordCamp NYC talks review, I'd like to point out the notes I took attending the talk Caching and Optimization for WordPress, by Jeremy Clarke.

I believe this was a great topic to be covered for people who actively maintain WordPress installations and have to deal with upgrades, stability and reliability. However, I also think Jeremy took a much more basic approach for this topic the way it shouldn't have to be. He would describe all the tools that he was showcasing from the most basic parts of it, like what's a terminal or why you should use it, to an audience attending the advanced development track.

Anyway, here are my notes:

• Expect a lot of traffic for your websites.
• First point of review, slow database queries.
• Caching.
  • Serving already fetched data.
• WP Super Cache (mandatory cache plugin).
• WP Tuner (resources information).
• YSlow, Yahoo's Firebug plugin.
• If necessary, use Gravatar.
• Memcached for WordPress.
• "CLI: The DOS-style of using a computer". What a quote.
• htop, a much more intuitive top.
• apachetop, an Apache processes visualizer.
• MySQL Tuning Primer Script.
• Use either APC, memcached or XCache.
• Monit, triggering commands.

After the talk I prompted him to whether he would consider also moving away from Apache and trying much faster alternatives like FastCGI PHP on nginx or Cherokee. He mentioned that he had considered it, but he preferred to stick with the most conventional and commonly used software for his installations. That's his opinion, of course. On mine, based on my own experience, dropping Apache is usually one of the best ways to workaround most of the issues around a slow WordPress.

Now thanks to WordPress.tv, we have a video of the talk that Jeremy delivered on a previos event:

And his slides:

Continuing my notes and remarks from WordCamp, I attended Writing Secure Plugins, which was given by Mark Jaquith (@markjaquith on Twitter). I found the talk to be also slightly introductory on security matters but nicely oriented to WordPress plugins and general PHP Web app development. I believe most of the tips given should be taken into consideration by every PHP coder out there, not just WP people.

The talk was split into the different attacks that are common on Web applications and mainly pointing to functions and actions to be taken. Here are my notes:

SQL injection

• esc_sql(), allows you to escape SQL queries.
• absint(), allows to convert an ID value to its positive integer value to prevent ID injection.
• $wpdb->update(), a WordPress API method to update data.
• $wpdb->insert(), a WordPress API method to insert new data rows.
• compact(), PHP core function that lets you use variable names as strings.
• $wpdb->prepare(), crafts a secure SQL statement with placeholders.
• $wpdb->get_var(), returns a single variable from WordPress data.

Cross-site scripting (XSS)

• "Everything is suspicious".
• esc_attr_e(), escapes a translated string to be used as an HTML tag attribute.
• esc_html(), escapes general HTML.
• esc_attr(), escapes a string for tag attribute.
• esc_url(), encodes URL.
• esc_url_raw(), encodes URL without HTML entities to be encoded.
• esc_js(), encodes JavaScript code.

Cross-site request forgery (CSRF)

• Understand the difference between authorization and intention.
• Nonces (token handling).
• wp_nonce_field() and then, check_admin_referer().
• current_user_can(), API capability checking.

AJAX CSRF

• &_ajax_nonce = NONCE

Privilege escalation

Stupid shit!

• Avoid exec() at all costs!
• Use blank or hardcoded paths instead of $_SERVER['REQUEST_URI'] on form submission.

Presentation

Here I start a series of posts with my comments, notes and remarks on the talks that I attended at last weekend's WordCamp in NYC.

The first talk I attended was Securing WordPress, by Brad Williams (@williamsba on Twitter). First off, this talk wasn't too technical since it was focused to beginning developers whose background wouldn't be completely into systems administration, it was intended to a broader audience, which is exactly why I liked it so much and started taking notes. You need some mild level of expertise on WordPress for most of what Brad mentioned but you don't have to be an expert.

So, most of the notes I took were taken directly from the slides (that you can browse below in the Slideshare widget), but I also add some homebrewed comments myself:

Don't use the admin account: Change it

Hackers will most likely target to the most privileged account on a WordPress that by default goes by the name of "admin" and you don't seem to be able to change it easily from the administration panel. Go ahead and do it on the MySQL shell yourself:

UPDATE wp_users SET user_login="notadmin" WHERE user_login="admin";

Change your files' permissions

This is what Brad called "The Great Permission Debate". You are basically fine if you leave all files under 0644 and directories under 0755.

$ find wordpress_root/ -type f -exec chmod 644 {} \;
$ find wordpress_root/ -type d -exec chmod 755 {} \;

Take wp-config.php out of WordPress

Starting in 2.6, WordPress will also look for the wp-config.php configuration file on the parent directory of your WordPress directory, which depending on your setup, might be not reachable to your web server's public files.

Move plugins and uploads directory out of WordPress

Also since 2.6, WordPress can be configured so that you don't have your plugins and uploads directory (where you upload files from the administration panel) to point somewhere else. You can do it by setting the constants WP_CONTENT_DIR, WP_CONTENT_URL, WP_PLUGIN_DIR and WP_PLUGIN_URL:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/your/blog/contents');
define('WP_CONTENT_URL', "http://myblog.com/contents");
...

Remove the WordPress version from the META head

WordPress apparently uses the generator META tag to scan for WordPress installations and create statistics of usage. That also enables possible attackers to discover what version of WordPress you are using, and if you are using an old vulnerable one, you might get hit. You can use the WordPress function, wp_head() instead.

Stay current on updates

Of course, always focus on getting the latest updates installed.

Secure passwords

Don't use "password" or "a" or "123" as a password for your installations. I recommend generating your password with a little tool called pwgen.

Secret keys

You can add some salt to your password by setting values for a few secret key constants. This will make a better encryption on the information stored on the user's cookies. Codex puts this as an example:

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh j>k[.Nf$y7iGKdJ3c*[Kr5Bg');
define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\\`39m_(');
define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS<2V^$T])=8Xh2a:b:}U_E');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fFP_!K$JCEkLuy ={x{0');

For more information on each of these secret keys, go to read their documentation.

Change the WordPress tables prefix

The database for a WordPress installation uses a prefix on each of the tables it uses, by default "wp_". You can change it to be a custom value.

Make sure you have HTTPS and force login and admin access through it

If it's possible, enable SSL on your host and configure WordPress to pass all login information and administration access through it. You can do it by setting the constants FORCE_SSL_LOGIN and FORCE_SSL_ADMIN to true.

IP lockdown

If you are using the Apache webserver, you can configure it so that it only allows  access to /wp-admin from a given IP (work or home only). You can do just about the same with any other webserver available (namely, nginx).

Security Plugins

Some of the following plugins will make your life easier. I recommend taking a look at them, they are worthwhile!

WP Security Scan

Scans your WordPress installation for security vulnerabilities and suggests corrective actions.

WordPress Exploit Scanner

This plugin searches the files and database of your website for signs of suspicious activity.

WordPress File Monitor

Monitors your WordPress installation for added/deleted/changed files. When a change is detected an email alert can be sent to a specified address.

Login Lockdown

Login LockDown records the IP address and timestamp of every failed login attempt. If more than a certain number of attempts are detected within a short period of time from the same IP range, then the login function is disabled for all requests from that range.

Finally

Some of the actions here are just preventive or simple security by obscurity. Truth is, you will never be 100% secure and you have to be certain that you understand that.

Presentation

This is Brad's presentation:

I had a blast on Saturday. Let me put it again in bold, I had an awesome experience yesterday at WordCamp NYC. If you ever have the opportunity, you shouldn't miss the chance to attend one of them, it's really inspiring, people is very, very welcome and I loved the fact that there's so many people with all sorts of backgrounds and focused on many fronts on the Web and blogging world, not just technical.

During the course of this starting week, I'll be posting my notes and remarks on each one of the talks I attended, I believe they do require their own attention. With as much as eight simultaneous tracks, it was pretty much impossible to hear them all, so I focused on technical talks (go figure) and on the "beginning developer" track, since I pretty much knew close to nothing when it comes to WordPress core development.

Unfortunately I couldn't attend Sunday sessions due to health issues. I'm seriously sorry about that. Anyhow, to be honest, I cannot easily recall another conference that left me with such a nice feeling after attending it.

Also, expect more blogging here.

I'll be attending WordCamp NYC this upcoming weekend. There's a lot of very interesting talks and people speaking at the conference, so it was basically a no-brainer since it's being held in Manhattan. Plus, WordPress is one of the platforms I've always liked and admired on how they have achieved to become a mainstream product with a huge amount of active users and developers. I started using it way back in 2004 when it was b2/cafelog, so it's been a long ride.

If you'll be around, poke me.