I've got a wordpress theme by having an options page. I've incorporated a fundamental export/import options feature. The export feature enables the customers to download the choices to some text .dat file and store them by themselves computer. The import options button reads b .dat file and overwrites the present options within the database. Then your file is erased in the finish of script execution (not saved within the server).

You will find no separate uploads.php files, everything occur in one script (the export, import, etc).

I attempted posting some php files, and other kinds of files, and also the only factor that happened was the choices were destroyed. But that is what's designed to happen, the imported file should really replace whatever is incorporated in the database.

The consumer are only able to access this type if they're drenched to the WordPress Dashboard with admin access.

So there's you don't need to have extensive security measures about this import form, can there be? Except, maybe I ought to check it out with .sql files and find out what might happen? Could someone potentially create an .sql file and wipeout the whole database? Must I blacklist .sql files safe?

Here's my import code:

   if ( $_GET['page'] == basename(__FILE__) ) {
        if ( 'export' == $_POST['action']) {
        cpress_export();
    }   
    if (isset($_FILES['settings'])){
        if ($_FILES["settings"]["error"] > 0){
            echo "Error: " . $_FILES["settings"]["error"] . "<br />";
          } else{
            $rawdata = file_get_contents($_FILES["settings"]["tmp_name"]);
            $cp_options = unserialize($rawdata);
            update_option('cpress_options', $cp_options);
            header("Location: themes.php?page=options_page.php&import=true");
          }
    }

Here is my export code (within the same file):

function cpress_export(){
$settings = get_option('cpress_options');
$file_out = serialize($settings);
header("Cache-Control: public, must-revalidate");
header("Pragma: hack"); 
header("Content-type: text/plain; charset=ISO-8859-1");
header('Content-Disposition: attachment; filename="cpress-options-'.date("Ymd").'.dat"');
echo $file_out;
exit;}

If you're reading through from the file and loading that file in to the database, then there's an chance for exploitation, sure. However, if this sounds like only enabled for admins, then I'm not sure just how much effort ought to be place in to safeguarding against malicious activity. If they're admins, you will find much simpler things they might do in order to eliminate the database.

Typically, it's most likely worth some effort to which makes it so customers can't accidentally screw anything up, but keeping your admin customers from doing malicious things is neither well worth the effort nor in conjuction with the concept of an "admin" role. It is just like giving someone su rights on the Linux box and seeking to make certain they cannot install malicious software onto it.

edit:I checked the Wordpress paperwork, and also the update_option() function escapes the string prior to the totally run. You ought to be protected from SQL injections.

A few enhancements I'd recommend

  1. Use if (!defined('ABSPATH')) die() at the outset of your wordpress plugin - if your malicious user attempted to load your script directly, it might fail, because the WordPress constant ABSPATH is not defined.

  2. Use WordPress nonces - this can a minimum of create a nasty person's existence just a little harder :)

  3. Make sure that unserialize() doesn't fail (the end result is going to be boolean false whether it does) - this can happen when the serialized data was malformed (or wasn't serialized to start with). Whether it fails, don't proceed using the update.

  4. Use [cde] rather than wp_safe_redirect() for the redirect (actually, you need to always make use of this function when redirecting with other Wordpress admin pages - otherwise use header()).