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.