Archive for the 'Injection Attacks' Category

Design Patterns, Scope, Globals and Superglobals in PHP

localGlobalThe Problem with Globals

Earlier this summer I completed a course through Rice University on Python. It was an introduction to making games with Python, and the four professors who taught it, did so brilliantly. One of the nagging issues that came up early was the use of global variables. In a clear explanation of the difference between local and global variables, virtually identical to PHP, we went through several game development exercises. At the very end of the class, however, we were admonished not to use global variables.

Online, you will find plenty of reasons to avoid globals in every computer language, but the main reason is one of maintainability. Because globals are accessible to all functions, their state can be changed by all functions. As a result, you may get unexpected outcomes that can be very difficult to track down, especially in larger programs. It’s like having a wild hare running through your program.

Encapsulation and Global Variables

Let’s start off with a simple example of global troubles. The following two programs represent sequential/procedural listings with a global.

Simple Global

<?php
$gvar = "Hello everyone!";
function showOff()
{
    echo $GLOBALS['gvar'];
}
showOff();
?>

Global With Changes

<?php
$gvar = "Hello everyone!";
function showOff()
{
    echo $GLOBALS['gvar'];
}
function fixUp()
{
    $GLOBALS['gvar']="If it weren't for treats, dogs would rule the world.";
}
fixUp();
showOff();
?>

The ouput is wholly different for these two programs when the function showOff() is called:

  • Hello everyone!
  • If it weren’t for treats, dogs would rule the world.

As programs grow in size and complexity, the problem of globals grows proportionately. (If multiple programmers are involved, the problem grows exponentially!).

Now let’s look at the same issue in a class with a global variable.

<?php
class Alpha
{
    public $gvar = "Hello everyone!";
 
    public function __construct()
    {
	echo $GLOBALS['gvar'];
    }
}
$worker1 = new Alpha();

It throws an error:

    Notice: Undefined index: gvar in ….

Rather than trying to find a clever way to get globals into classes, using either the keyword global or the associative array $GLOBALS, let’s just say that a focus on visibility in classes will better serve further discussion of global scope when it comes to OOP encapsulation. (Visibility will be discussed in an upcoming post.)

Local Variables in Classes and Methods

Local variables work with methods in the same way as they do in unstructured functions. The locality of the variable does not matter in terms of return to a call or request. As with all other visibility, that depends on the method. The following example shows a local variable named $local in multiple methods with different content and different visibility. The Client class has a local variable in the constructor function, $runner. The following listing shows a request from within a class and by an external client.

<?php
ini_set("display_errors","1");
ERROR_REPORTING( E_ALL | E_STRICT );
 
class LocalReport
{  
    public function __construct()
    {
	echo $this->showOff1() . "<br />";
	echo $this->showOff2() . "<br />";
    }
    private function showOff1()
    {
	$local = "All good things come to pass.";
	return $local;
    }
 
    private function showOff2()
    {
	$local = "Fatal assumptions: He will change; she won't change.";
	return $local;
    }
 
    public function showOff3()
    {
	$local = "We serve the public (visibility)!";
	return $local;
    }
 
}
 
class Client
{
    public function __construct()
    {
	$runner=new LocalReport();
	echo $runner->showOff3();
    } 
}
 
$worker = new Client();
?>

The output is:

    All good things come to pass.
    Fatal assumptions: He will change; she won’t change.
    We serve the public (visibility)!

Whether to use local variables or class properties in OOP development depends on the purpose of the application under development. I tend to go for private properties to better insure encapsulation, but local variables can be handy in certain types of implementations. In either case, neither is subject to the problems associated with global variables.
superglobalman250
Superglobals

Superglobals in PHP are automatic predefined global variables available in all scopes throughout a script. Most PHP developers are familiar with $_GET and $_POST, but other superglobals such as $_COOKIE, $_SESSION and $_SERVER are commonly used as well. Elsewhere on this blog, injection attacks through superglobals have been discussed, but here I want to look at the relationship between OOP/Design Patterns and superglobals.

To get a good idea of the “superness” of superglobals, consider a typical OOP program where the requesting class is a client. It calls a class that uses a superglobal. Also, to acknowledge Brazil’s 2014 World Cup hosting, and the publication of Learning PHP Design Patterns in Portuguese (Padrões de Projeto em PHP), I thought I’d create the UI in Portuguese as shown in Figure 1:

Figure 1: Data input module

Figure 1: Data input module

The HTML data entry is a simple one, asking for the user’s favorite team and favorite sport. They are saved in the super global elements, ‘team’ and ‘sport’ and then sent off using the post method. The following HTML code was used:

DataEntry.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <link rel="stylesheet" type="text/css" href="brazil.css">
    <title>Data Entry</title>
</head>
 
<body>
    <h2>Exame dos Esportes</h2>
    <img src="fifa.png">
    <h3>D&#234; entrada com o nome da equipe e do esporte em umas caixas de texto apropriadas:</h3>
<form action="SuperClient.php" method="post" name="super">
    <input type="text" name="team"> Equipe de esportes favorita<br />
    <input type="text" name = "sport"> Esporte favorito<p />
    <input type="submit" name="shoot" value="Emita a informa&#231;&#227;o">
</form>
</body>
</html>

You’ll have to excuse my poor Portuguese. In English it asks to enter your favorite team and sport. (As a long-suffering Chargers fan, you can see the sample entry in Figure 1.) Also, it needs some CSS, lest you think me a total savage:

brazil.css

@charset "UTF-8";
/* CSS Document */
/* 06794e (green), f8d902 (yellow), 1b3c83 (blue), ffffff */
body
{
	font-family:Verdana, Geneva, sans-serif;
	color:#06794e;
	background-color: #f8d902;
}
h2
{
	font-family: "Kilroy WF", "Arial Black", Geneva, sans-serif;
	color: #ffffff;
	background-color: #1b3c83;
	text-align: center;
 
}
img
{
	display: block;
	margin-left: auto;
	margin-right: auto;
}

The client class (SuperClient) is little more than a trigger to call a class to process the superglobals. However, the client has no superglobals itself. This is significant in that SuperClient.php is called by the HTML document (DataEntry.html).

SuperClient.php

<?php
include_once('SuperGlobal.php');
 
class SuperClient
{  
    private $superGlobal;
 
    public function __construct()
    {
	$this->superGlobal = new SuperGlobal();
    }
}
$worker=new SuperClient();
?>

So the question is,

Will the super global $_POST be accessible to the SuperGlobal class called by the client?

Let’s see.

SuperGlobal.php

<?php
class SuperGlobal
{  
    private $favoriteTeam;
    private $favoriteSport;
 
    public function __construct()
    {
	$this->favoriteTeam = $_POST['team'];
	$this->favoriteSport = $_POST['sport'];
	echo "Minha equipe favorita &#233; $this->favoriteTeam. <br />";
	echo "Meu esporte favorito &#233; $this->favoriteSport. <br />";
    }   
}
?>

When you run the program, your output will look something like the following:

    Minha equipe favorita é Chargers.
    Meu esporte favorito é football.

That shows that a superglobal can be accessed from even the most encapsulated environment. In the sense that the HTML Document called the SuperClient and yet the superglobals were available in the SuperGlobal object should tell you (and show you) that once launched from an HTML document a superglobal can be accessed from any PHP file communicating directly or indirectly with the originating HTML document.

Can Superglobals Cause Global Trouble?

For superglobals to be a problem, they need to change unexpectedly within a program.

So the first question, we need to ask is, Can superglobals be changed once they are sent from an HTML document?

We showed that superglobals can get inside an encapsulated object, but can they be changed or do they maintain the values set by the HTML document? The following is a test to find out. With a slight change to the SuperGlobal class and a couple more objects, we can find out.

Step 1: Change the SuperGlobal class to the following:

SuperGlobal.php

<?php
//Include new class
include_once('GlobalChanger.php');
 
class SuperGlobal
{  
    private $favoriteTeam;
    private $favoriteSport;
 
    public function __construct()
    {
	$this->favoriteTeam = $_POST['team'];
	$this->favoriteSport = $_POST['sport'];
	echo "Minha equipe favorita &#233; $this->favoriteTeam. <br />";
	echo "Meu esporte favorito &#233; $this->favoriteSport. <br />";
 
	//Add a new line
	$caller = new GlobalChanger();
    }   
}
?>

Step 2: We need a class to change the values of the superglobals and call another object to display the changes in the same super global.

My friend Sudhir Kumar at PandaWeb.in from Chennai, India is a cricket fan; so I decided to use his favorite team and sport to replace whatever team and sport is entered.

GlobalChanger.php

<?php
include_once('SuperChanged.php');
 
class GlobalChanger
{   
    public function __construct()
    {
	$_POST['team']="Team India";
	$_POST['sport']= "cricket";
	$caller = new SuperChanged();
    }  
}
?>

Step 3: Finally, we need to see if the new team and sport has been changed in the application.

SuperChanged.php

<?php
class SuperChanged
{  
    private $newTeam;
    private $newSport;
 
    public function __construct()
    {
	$this->newTeam=$_POST['team'];
	$this->newSport=$_POST['sport'];
 
	echo "<br />Now my favorite team is $this->newTeam. <br />";
	echo "And my very favorite sport is $this->newSport.<br />";
    }   
}
?>

Starting with the same html document initially used, we can now see that indeed the superglobal values have been changed, and they are quite available throughout the program.

    Minha equipe favorita é Chargers.
    Meu esporte favorito é football.

    Now my favorite team is Team India.
    And my very favorite sport is cricket.

As you can see, the GlobalChanger object changed the original values. Furthermore, it is clear that we were using the same superglobal array in the SuperChanged class when the $_POST values were passed to private variables and displayed using the echo statement.

Obviously, a PHP programmer cannot simply drop superglobals. Further, even though we can change their values, that doesn’t mean we should change them or even have an occasion to do so. But, we need to be aware of the problems with global variables. After all, superglobals are global variables, even in an encapsulated environment.

Conclusion

Two important points need to be emphasized here:

  1. Don’t use global variables.
  2. Where you have to use superglobals, don’t change their values dynamically in PHP.

Like everything else in programming there are exceptions, but remember that globals, while having a purpose, often loose that purpose in OOP programs and structured design patterns. When using superglobals, keep in mind that they are true globals and they can be changed, but only if the developer assigns them different values after they’ve been assigned values in HTML. As true globals, they can cause the same kinds of problems that any other globals can. So treat them more like constants, and let their originally assigned values from the HTML form stay put.

Share

PHP Adapter Pattern for Defense against Injection Attacks

injectionAttcksProtect 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:
Download

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>
<html>
<head>
<link type="text/css" rel="stylesheet" href="inject.css"/>
<meta charset="UTF-8"/>
<title>Data Entry</title>
</head> 
<body>
<h1>Send Information</h1>
<form action="Client.php" method="post">
  <input type="text" name="cusName"/>
  &nbsp; Name Please <br />
  <input type="text" name="cusEmail"/>
  &nbsp; Email address <br />
  <input type="text" name="cusUrl" value="http://"/>
  &nbsp; Web Site address (URL) <br />
  <input type="submit" value="Enter Data into Database"/>
</form>
</body>
</html>
//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.<br />",$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.<br />");
		}
		$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 <br /> 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

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

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’

Share