Download The basic concepts of the PHP internet application security

THE BASIC CONCEPTS OF THE PHP INTERNET
APPLICATION SECURITY
Kwiatkowska Anna
Technical University of Lublin,
Lecturer, Ph.D., The Institute of Computer Science
ul. Nadbystrzycka 36B, 20-618 Lublin, Poland
tel. +48 81 525 20 46
e-mail: [email protected]
Łukasik Edyta
Technical University of Lublin,
Lecturer, Ph.D., The Institute of Computer Science
ul. Nadbystrzycka 36B, 20-618 Lublin, Poland
tel. +48 81 525 20 46
e-mail: [email protected]
Pańczyk Beata
WSPA, The High School of Initiative and Administration,
ul.Bursaki 12, 20-150 Lublin, Poland
Technical University of Lublin,
Lecturer, Ph.D., The Institute of Computer Science
ul. Nadbystrzycka 36B, 20-618 Lublin, Poland
tel. +48 81 525 20 46
e-mail: [email protected]
The main aim of this paper is to describe the basics security rules for PHP application. It
presents some general security advice, explains the different configuration option
combinations and the situations they can be safely used.
Introduction
PHP is a powerful language, used in a web server is able to access files, execute commands
and open network connections on the server. These properties make anything run on a web
server insecure by default. PHP can be used to build complete server applications or it can be
used for simple server-side includes. How to secure it, is largely up to the PHP developer.
1. The basic security concepts
This section presents some basic suggestions to use for PHP Internet application
programmers.
Filesystem security
PHP is subject to the security built into most server systems with respect to permissions on a
file and directory basis. This allows to control which files in the filesystem may be read. Care
should be taken with any files which are world readable to ensure that they are safe for
reading by all users who have access to that filesystem. Some dangerous example and how to
prevent files may be found in [3].
Error reporting
There are two sides to error reporting: one is beneficial to increasing security, the other is
detrimental. A standard attack tactic involves profiling a system by feeding it improper data,
and checking for the kinds, and contexts, of the errors that are returned. This allows the
system cracker to probe for information about the server, to determine possible weaknesses. If
an attacker had gleaned information about a page based on a prior form submission, they may
attempt to override variables, or modify them.
Solution is to use PHP's own error_reporting(), to help secure the code and find variable usage
that may be dangerous. By testing the code, areas where the variables may be open to
modification, may be quickly find. After testing, error reporting should be completely
disabled by setting error_reporting() to 0, or turning off the error display using the php.ini
option display_errors Off. It should be also defined the path to log file using the error_log ini
directive, and turning log_errors on [3].
Using register globals
The most controversial change in PHP is when the default value for the PHP directive
register_globals went from ON to OFF in PHP > 4.2.0. Reliance on this directive was quite
common and many people didn't even know it existed and assumed it's just how PHP works.
The example 1 demonstrates how one can write insecure code with this directive but keep in
mind that the directive itself isn't insecure but rather it's the misuse of it [3].
Example 1.
Let’s assume that in php.ini is register_globals on. Script index.php includes the code:
if (check_user()==1) $admin=1;
if ($admin) show_adminpage(); else show_infopage();
When user write URL with index.php?admin=1, script shows the adminpage!
Example 1.a
The safely is to modify the above script (using the arrays $_GET, $_POST, $_COOKIE etc.)
and initialise all variables: if (check_user()==1) $admin=1; else $admin==0;
User submitted data
The greatest weakness in many PHP programs is not the language itself, but not being
security written code. Any variables being submitted from a web browser should be properly
checked. It is impossible to test all possibilities for even the simplest of pages. The input data
expected by programmers may be completely unrelated to the input given by a user. So the
good practice is to look at the code from a logical perspective, to discern where unexpected
data can be introduced. Example 2. presents the dangerous not checked variable usage [3].
Example 2.
<?php
unlink ($bad_var); // remove a file from the user's home directory
fwrite ($fp, $bad_var); // Write logging of their access
system ($bad_var); // Execute something
exec ($bad_var); // Execute something
?>
Magic Quotes
It is a process that automatically escapes incoming data to the PHP script. It's preferred to
code with magic quotes off and to instead escape the data at runtime, as needed. When on, all
' (single-quote), " (double quote), \ (backslash) and NULL characters are escaped with a
backslash automatically. This is identical to what addslashes() does [3].
Hiding PHP
A few techniques can help to hide PHP, to prevent some weaknesses in scripts:

setting expose_php = off in php.ini file (reduce the amount of information)

to configure web servers to parse different filetypes through PHP (in the apache
configuration file)
Databases security
Databases are components of any web based application. PHP cannot protect database by
itself but there are some the very basics of how to access and manipulate databases within
PHP scripts. The simple rule is: defence in depth. Good design of the database schema and the
application deals with greatest fears.
Applications should never connect to the database as its owner or a superuser, because these
users can execute any query (for example, modifying the schema - dropping tables or deleting
its entire content).
It is need to be created different database users for every aspect of the application with very
limited rights to database objects. The business logic shouldn’t be implemented in the web
application (script), instead it should be done in the database schema using views, triggers or
rules.
It is possible to establish the connections over SSL to encrypt client/server communications
for increased security, or use SSH to encrypt the network connection between clients and the
database server. If either of these is used, then the traffic monitoring and gaining information
about the database will be difficult for an attacker. SSL/SSH protects data travelling from the
client to the server but does not protect the persistent data stored in a database. Encrypting the
data is a good way to protect information, but very few databases offer this type of data
encryption. The way to solve this problem is to use several PHP extensions, such as Mcrypt
and Mhash, covering a wide variety of encryption algorithms. The script encrypts the data
before inserting it into the database, and decrypts it when retrieving [3].
2. The possible attack examples
This section describes two the most popular attack: file inclusion and SQL injection [1,2].
Example 3. File Inclusion
a)
File course.php contains the code:
<?php
echo "<h2> PHP</h2>";
if ($course=$_GET['nr']) include ($course.".txt");
else include("content.txt"); ?>
b)
File content.txt contains the code:
Course number:
<ol>
<li><a href="course.php?nr=1">Introduction</li>
<li><a href="course.php?nr=2">Language</li>
</ol>
c)
File 1.txt contains the code:
<h3>Introduction</h3>
<p> Basic concepts ... <br/>...</p>
Files 2.txt, 3.txt, etc. contain the next section of the course.
d)
File trojan.txt contains the code:
<?php phpinfo(); ?>
Course.php displays the screen presented on the figure 1a. Link from introduction shows
result presented on fig.1b. When the user write the URL as: http://localhost/course.php?nr=1 the
browser displays also the introduction page (1.txt, fig.1b) but when user write:
http://localhost/wyklady.php?nr=http://localhost/trojan, the PHP interpreter includes and executes the
trojan.txt (and any dangerous code – fig.1c).
To solve this problem is to modify the one line of the script course.php (nr should be integer value):
if ($course=(int) $_GET['nr']) include ($course.".txt"); else include("content.txt");
Many web developers assume that an SQL query is a trusted command. Direct SQL
Command Injection is a technique where an attacker creates or alters existing SQL commands
to expose hidden data, or to override valuable ones, or even to execute dangerous system level
commands on the database host. Example 4. shows how the attacker may create a superuser in
the database, when in php.ini is set magic_quotes_gpc=Off.
a)
b)
c)
Figure 1.a) the first page b) the page of the Introduction c) The page of trojan.txt
Example 4. SQL Injection
In the database sqlinj is the users table:
login pass
level
admin
admin123 1
beata
Beata123 0
The script log.php contains the code:
<?php
if($_POST['login']&&$_POST['pass'])
{ $login=$_POST['login'];
$pass=$_POST['pass'];
$query="SELECT level FROM users WHERE login=\"$login\" AND
pass=\"$pass\"";
$link=mysql_connect("localhost","root") or die("Server error");
mysql_selectdb('sqlinj') or die("DB error");
$res=mysql_query($query) or die("Query error");
if($row=mysql_fetch_array($res))
{ switch ($row[0])
{ case 0: print "Normal user"; break; case 1: print "Admin!";
}
else print "Login error";
mysql_close($link);
}
else //form print:
{ echo "<form action='log.php' method='post'><p align='center'> ";
echo "Login: <input name='login'/><br/>";
print "Password: <input name='pass'/><br/>";
print "<input type='submit' value='Login'/>";
print "</form></p>";
} ?>
}
The normal situation is presented on fig.2a,b. The abnormal situation is when user write the
login as: admin”# and any password. The result demonstrates the figure 3 a), b). The SQL
query was interpreted as:
SELECT level FROM users WHERE login="admin" #" AND pass="xxx";
and SQL symbol # is treated as comment.
a)
b)
c)
Figure 2. a) The login page b) Information for normal user c) Login error information
a)
b)
Figure 3. a) The login page with wrong admin password b) Information for admin
To avoid above situation the script should be modified as:
$login=addslashes($_POST['login']);
$pass=addslashes($_POST['pass']);
Then the query is like:
SELECT level FROM users WHERE login="admin\" #" AND pass="xxx";
Conclusions
“A completely secure system is a virtual impossibility. A system is only as good as the
weakest link in a chain. If all transactions are heavily logged based on time, location,
transaction type, etc. but the user is only verified based on a single cookie, the validity of
tying the users to the transaction log is severely weakened.”[3]
The advise for programmers is first to learn as more as possible about security for the
technology used and then write the code.
References
1. Hudson P., PHP. Almanach, O’Reilly, Helion, Gliwice, 2006
2. Kierzkowski A., PHP5. Tworzenie stron WWW, Helion, Gliwice, 2006
3. http://www.php.net/manual/en/security.php