Generalizations are fun, they always are because they tend to offend people and offended people by stupid shit is usually lots of fun.

Here Debian, as a whole, fails; it sucks. Here Debian blows ass, the entire project is whack.

My good friend Chris Lee sent me this:

If you can't see the above iframe, go here.

Debian, full of fail. Wasn't this generalization fun?

Let the non-sense bullshit horses be released.

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 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

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.

Situation

You need to run a time consuming task after a PHP script is run. The task will have to reuse the POST/GET data that is being sent to the service. The task would have to be done once the client has gone away.

Solution

Use mod_perl's PerlFixupHandler to take the POST data, set the handler to be run by mod_php (or whatever else you are running it). Finally, use PerlCleanupHandler to run that task since that's exactly what that phase is for, once the client went away.

Explanation

<Files ~ "myscript\.php$">
  SetHandler modperl
  PerlFixupHandler My::App::Fixup
</Files>

Now, we are just indicating that we want a Fixup handler which is going to be run by My::App::Fixup. The Fixup phase runs right before content generation and delivery starts, which is the perfect moment to pass the execution of the PHP script.

So our handler would look like this:

package My::App::Fixup;

use strict;
use warnings;

use Apache2::Const -compile => qw/:common/;
use Apache2::Request;
use Apache2::RequestIO ();
use Apache2::RequestRec ();
use Apache2::RequestUtil ();
use Apache2::ServerUtil ();

Up to this moment, usual regular module-loading.

sub handler {
  my($r) = shift;

Now, we'll take the request object and assign it to $req.

  my $req = Apache2::Request->new($r);

We now register a subroutine, cleanup, to be hooked with the Cleanup phase. PerlCleanupHandler is great, it's the very last phase of a mod_perl execution, it will basically run after the client that made the request has gone away, once the connection with it has been terminated with the server. It's because of that nature, that it makes it the best place to make any kind of time consuming task, since we wouldn't want the client to wait for termination of that job. This phase is also not implemented in Apache, this is mod_perl specific.

  $r->push_handlers(PerlCleanupHandler => \&cleanup);

Now, we set the handler for the next Apache phase to be handled as PHP:

  $r->handler("application/x-httpd-php");

In this point, I will have to start reading the POST information that was sent, since that will be gone when the Cleanup is reached:

  my $body = $req->body;

  my $st = {};

  for my $key ( keys %$body ) {
    $st->{$key} = $req->body($key);
  }

All the key-value pairs of the POST data are on the $st hash reference and I record it now on a "pnote", so I can catch it later:

  $r->pnotes("POST", $st);
  return Apache2::Const::OK;
}

So, this is the cleanup subroutine I registered previously. I prefered to do it this way, I could also have set an specific handler for PerlCleanupHandler on the Apache configuration, but I just wanted to do it this way.

sub cleanup {
  my($r) = shift;

I take now the request object again. The POST data is gone already, this is only for GET.

  my $req = Apache2::Request->new($r);
  my $table = $req->param;

I retrieve the information that I left before on the pnote.

  my $st = $r->pnotes("POST");

  for my $key ( keys %$table ) {
    $st->{$key} = $req->param($key);
  }

In this moment, $st has all POST and GET data on a hash reference. It's according to your application needs how to have proceeded with this.

  # All your time-consuming work
  # sleep 600;
  # or whatever you want 
  # for the sake of this example, I'll just write the values to a file:
  open my $fh, ">/tmp/myexample" or die $!;
  while(my($k, $v) = each %$st) {
    print $fh "$k ->$v", "\n";
  }
  return Apache2::Const::OK;
}
1;

The good thing about this is that, you can run arbitrary time-consuming code from a Cleanup phase, and that it doesn't matter if you have to set the handler for the response phase to something else, like PHP, mod_perl will be able to handle it.

Now, myscript.php would look like this:

<?php
print "<pre>";
print_r($_REQUEST);
print "</pre>";
?>

So, let's test it:

cerdo ~ $ curl -d 'name=david&skill=lousy' http://localhost:82/damog/php/myscript.php?arg1=1
<pre>Array
(
[arg1] => 1
[name] => david
[skill] => lousy
)
</pre>
cerdo ~ $ cat /tmp/myexample
arg1 -> 1
skill -> lousy
name -> david
cerdo ~ $

As you can see, I'm sending both POST and GET parameters with curl. PHP displays it just fine, but also my temporary test file.

How are you using PerlCleanupHandler?