Day: May 22, 2005

While I struggle with my own security demons, Thomas Waldegger emailed to let me know that the BugTraq security alert for WordPress has gone live. I am still getting requests for a patch file for this issue, and would rather that the WordPress team respond to these since the notice has gone public.

This alert does demonstrate how difficult it is to ensure that an application is secure. What happened is that the ping identifier that was sent with a trackback ping was not checked to ensure that it was, indeed, an integer. Based on this, a person could attach a separate subquery to the ping, and use this to, as Thomas put it, be able to re-construct values in the database.

This is something I never would have spotted myself, though I am now alert to the vulnerability. The only problem is that once you’re aware of one type of vulnerability, others are discovered.

You never stop dancing in the open source world. Even when your steps falter, you just got to dance. Most of the time, the crowd doesn’t even see your footwork; about the only time they do, is when you’re dancing out of tune.

Wordform’s metadata extensions require form elements with a minimum of a button to push — usually with fields to fill in. These form elements are incorporated into the general gen_metadata.php page, depending on which extension is currently being invoked.

The gen_metadata.php (see source) file accesses the extension directory and outputs a list of available extensions — similar to how plugins work in WordPress. When you click on an option, the file name and post ID is sent, using GET, back to the same page. This is valid REST, as all that’s happening at this point is a query.

The extension file, (see source for one of the extensions) is then included in the page. In this file is the form processing code, and the rest of the form elements necessary to access the appropriate metadata.

The form begins and ends in gen_metadata.php. This file also has several hidden fields for the filename of the extension, the post identifier and URI, as well as a secret token that is also added as a SESSION variable.

How the security for this is all set up:

The register globals variable is turned off, ensuring that I properly pull the values from $_POST or $_GET.

The update is handled through a form POST, so that a GET cannot be triggered by a bot accessing the page contents.

The original page, gen_metadata.php calls code that validates the person’s authentication to access the page, as well as start the session. With this in place, you have to be logged in to access the page.

To prevent a cross-site scripting (XSS) attack, in the metadata files a check is made to ensure that the script is actually included in the gen_metadata.php file located within the application’s admin directory. I then checked this myself using a spoof, as well as cross-site script, and the security worked.

Finally, today, I added a form security token. The code for this is added after the included extension script (so that the session variable is only reset after it’s used to test the validity of the post); the value is added to a form field that’s passed with the other data when the form is submitted.

Question to the PHP developers — what have I missed? What gaps did I leave. Where is the code more complicated, or less, than needed?

Feedback would be appreciated. I would prefer the kind in writing, rather than the kind I have been getting, which has been actual XSS attacks, usually every time I post to the Wordform weblog. These have become a bit wearisome.