Protect Yourself

Some people (I cannot bring myself to call them ‘programmers’) amuse themselves by conducting injection attacks. Even in a PHP/MySQL site with no value other than its own informative functionality, they get their kicks by screwing with it. I sort of knew about them, but since I’m not particularly interested in security issues, I didn’t pay much attention. However, when writing Learning PHP Design Patterns, Robin Nixon (author of Learning PHP, MySQL, JavaScript, and CSS, 2nd Edition) pointed out that when passing data from HTML to PHP using the $_POST or $_GET superglobal variables, the program was subject to an injection attack. Robin then provided some tips on avoiding them by using mysqli::real_escape_string. I took Robin’s advice, and it is reflected in Chapter 11 use of the Proxy design pattern. (Let me note that I’ve read numerous articles on injection attacks since the publication of Learning PHP Design Patterns, and I am aware that there are several different approaches to preventing injection attacks. As far as this post goes, an Adapter can be used to insert any kind of protection against injection attacks; so if you have another technique you prefer; go ahead and use it in the Adapter.)

A General Defense Pattern?

Recently, I’ve been thinking about using a design pattern as a general way of escaping data passed from HTML. The Proxy pattern is fine, but I tend to use it for login security (even though it has other uses). Also, I was thinking that a design pattern that could be used as a “patch” to an older application to make it “injection attack proof” would be an interesting and useful pattern. For this task, the Adapter pattern immediately came to mind. It could be used to change the passing of data from HTML to PHP and prevent injection attacks. (See Chapter 7 for a full discussion of the Adapter pattern—using both inheritance and composition.) Since this example has quite a bit of code, you might want to download all the files before getting started:

The Defenseless Data Entry Module

Let’s start with a typical OOP setup for a PHP data entry module. We’ll start with the code for the HTML, its CSS and the table for entering the data. It’s all pretty standard, but you need it to proceed. (You will need to click on the View Code button in the following listings to see the code.) The two connection classes (in the download) are described in detail in another post on this blog.

 
//HTML
< !doctype html>





 

Send Information

  
    Name Please 

  
    Email address 

  
    Web Site address (URL) 

  

//inject.css
@charset "UTF-8";
/* CSS Document */
/* 292929,5B7876,8F9E8B,F2E6B6,412A22 */
 
body
{
        background-color:#f2e6b6;
        color:#292929;
        font-family:Verdana, Geneva, sans-serif;
}
 
h1
{
        background-color:#8F9E8A;
        color:#412A21;
        text-align:center;
        font-family:"Arial Black", Gadget, sans-serif;
}

< ?php
//ini_set("display_errors","1");
//ERROR_REPORTING( E_ALL | E_STRICT );
include_once("UniversalConnect.php");
class CreateTable
{
        private $tableMaster;
        private $hookup;
 
        public function __construct()
        {
                $this->tableMaster="injectAdapt";
                $this->hookup=UniversalConnect::doConnect();
 
                $drop = "DROP TABLE IF EXISTS $this->tableMaster";
 
                if($this->hookup->query($drop) === true)
                {
                        printf("Old table %s has been dropped.
",$this->tableMaster);
                }
 
                $sql = "CREATE TABLE $this->tableMaster (
                        id SERIAL,
                        cusname NVARCHAR(25),
                        cusemail NVARCHAR(40),
                        cusurl NVARCHAR(40),
                        PRIMARY KEY (id))";
 
                if($this->hookup->query($sql) === true)
                {
                        printf("Table $this->tableMaster has been created successfully.
");
                }
                $this->hookup->close();
        }
}
$worker=new CreateTable();
?>

Once all the preliminaries are finished, the following interface and class are simple ones to deal with data entry in a MySQL environment. It is ripe for an injection attack!

< ?php
//Client.php -- this client is only used with the PlainDataEntry
//object. A different Client object is used with the
//Adapter pattern
function __autoload($class_name) 
{
    include $class_name . '.php';
}
class Client
{
   private $plain;
 
   public function __construct()
   {
      $this->plain=new PlainDataEntry(); 
   }
}
$worker=new Client();
?>
 
< ?php
//IDataEntry.php
interface IDataEntry
{
    function getData();
    function insertData();
}
?>
 
< ?php
//PlainDataEntry.php
class PlainDataEntry implements IDataEntry
{
    private $cusname;
    private $cusemail;
    private $cusurl;
    private $sql;
    private $tableMaster;
    private $hookup;
 
    public function __construct()
    {
        $this->tableMaster="injectAdapt";
        $this->hookup=UniversalConnect::doConnect();
    }
 
    function getData()
    {
        $this->cusname = $_POST['cusName'];
        $this->cusemail = $_POST['cusEmail'];
        $this->cusurl = $_POST['cusUrl'];
    }
 
    function insertData()
    {
        $this->sql="INSERT INTO $this->tableMaster (cusname,cusemail,cusurl)VALUES ('$this->cusname','$this->cusemail', '$this->cusurl')";
        $this->hookup->query($this->sql);
        if ($result = $this->hookup->query($this->sql))
        {
            printf("Customer: %s email %s and URL: %s 
 have been inserted into %s.",$this->cusname,$this->cusemail,$this->cusurl,$this->tableMaster);
        }
        else
        {
            printf("Here's what went wrong: %s\n", $this->hookup->error);
        }
        $this->hookup->close();       
    }
}
?>

The call to the Client class from the HTML data entry module is a simple one that instantiates an instance of the PlainDataEntry class. At this stage, think of the Client as little more than a trigger script. Figure 1 shows this simple OOP arrangement:

Figure 1: Class implements interface

The Client is an integral part of the Adapter pattern; especially when using composition. Figure 2 shows the role of the Client object in relation to the other objects in the Adapter. (The top diagram is generic and the bottom one is what has been implemented for this example.) Note that the identical interface is used as the one shown in Figure 1. This is important because one of the key features of the Adapter pattern is that incompatible interfaces can be used in composition. Specifically, the adapter participant of the design allows incompatible interfaces to work together in a composition. (Keep in mind that this blog focuses on PHP design patterns and getting incompatible interfaces working together is the focal point, and the issue of preventing injection attacks is an illustration of how the Adapter might be used.)

Figure 2: Generic and applied composition Adapter class diagrams

The main participant in all of this is the CleanupAdapter class, and so that is where we’ll start.
Continue reading ‘PHP Adapter Pattern for Defense against Injection Attacks’