PHP Security and Templates
PHP Security and Templates
Make sure you have these items sorted out when deploying your applications to production environments:
XSS attacks happen when client-side code (usually JavaScript) gets injected into the output of your PHP script. This can be
through the URL, but can also occur via a stored technique such as the database.
ENT_QUOTES is used to escape single and double quotes beside HTML entities
UTF-8 is used for pre PHP 5.4 environments (now it is default). In some browsers some characters might get pass
the htmlspecialchars().
Injections
SQL injection
When working with databases, one of the most common security vulnerabilities in web applications is definitely
SQL injection attacks. Malicious users can insert SQL queries into inputs handled by code that interacts with
datbases in order to cause unwanted behavior.
Directory traversal (path injection)
Directory traversal attacks, also known as ../ (dot, dot, slash) attacks, happen when users supply filenames as input that can
traverse to parent directories. Data can be set as index.php?page=../secret, or /var/www/secret, or something more
catastrophic:
require $page;
// or something like this
echo file_get_contents('../pages/'.$page.'.php');
In such cases you must check if there are attempts to access the parent or some remote folder:
// Using whitelists of pages that are allowed to be included in the first place
$allowed = ['home', 'blog', 'gallery', 'catalog'];
$page = (in_array($page, $allowed)) ? $page : 'home';
echo file_get_contents('../pages/'.$page.'.php');
Command injection
Be careful when dealing with commands executing functions and data you don't trust.
Code injection
Code injection happens when malicious code can be injected via the eval() function, so remember to always sanitize your
data when using it:
eval('include '.$_GET['path']);
Cross site request forgery, one click attacks, or session riding is an exploit whereby users execute unwanted actions on web
applications.
Public files
Make sure to move all your application files, configuration files and similar parts of your web application to a folder that
isn't publicly accessible when you visit URLs of your web application. Some types of files (e.g., .yml files) might not be
processed by your web server and users could view them online.
Configure your web server to serve files from the public folder instead of from your application root folder. The public
folder contains the front controller (index.php). In case of a web server misconfiguration resulting in PHP files failing to be
served properly, the source code of index.php will be visible to the public.
Passwords
When working with users' passwords, hash them properly with the password_hash() function.
Uploading files
Many security breaches occur when users can upload files onto a server. Make sure you go through all the vulnerabilities
associated with uploading files and take appropriate precautions against these vulnerabilities, such as by renaming
uploaded files, moving them to publicly inaccessible folders, checking the types of files uploaded and so on.
Session hijacking
Session hijacking is an attack where an attacker steals the session ID of a user. The session ID is sent to the server where
the associated $_SESSION array is populated. Session hijacking is possible through an XSS attack or when someone gains
access to the folder on a server where the session data is stored.
An RFI (remote file inclusion) attack is when an attacker can include custom scripts:
Make sure you disable this in your php.ini unless you know what you're doing:
PHP configuration
Always keep the installed PHP version updated. You can use versionscan to check for possible vulnerabilities of your PHP
version. Update open source libraries and applications, and keep your web server well maintained.
Here are some of the important settings from php.ini that you should check out. You can also use iniscan to scan your
php.ini files for best security practices.
Error reporting
In your production environment, you must always turn off displaying errors to the screen. If errors occur in your
application and they are visible to the outside world, an attacker could get valuable data for attacking your application.
display_errors and log_errors directives in the php.ini file:
PHP version is visible in HTML headers. You might want to consider hiding your PHP version by turning off the
expose_php directive, preventing the web server from sending back the X-Powered-By header:
expose_php = off
Remote files
; disabled opening remote files for fopen, fsockopen, file_get_contents and similar functions
allow_url_fopen = 0
; disabled including remote files for require, include ans similar functions
allow_url_include = 0
open_basedir
This settings defines one or more directories (subdirectories included) where PHP has access to read and write files. This
includes file handling (fopen, file_get_contents) and also including files (include, require):
open_basedir = "/var/www/test/uploads"
Session settings
PHP is by default configured to store session data on the server and a tracking cookie on client-side (usually called
PHPSESSID) with unique ID for the session.
session.cookie_httponly
If the attacker somehow manages to inject JavaScript code for stealing a user's current cookies (the
document.cookie string), the HttpOnly cookie you've set won't show up in the list.
session.cookie_httponly = 1
session.cookie_domain
This sets the domain for which cookies apply. For wildcard domains you can use .example.com, or set this to the
domain where it should be applied. By default, it isn't enabled, so it's highly recommended for you to enable it:
session.cookie_domain = example.com
session.cookie_secure
For HTTPS sites, this accepts only cookies sent over HTTPS. If you're still not using HTTPS, you should consider
it.
session.cookie_secure = 1
Use HTTPS
HTTPS is a protocol for securely communication over networks. It's highly recommended that you enable it on all sites.
------------------------------------------------------------------------------------------------------------------------------------------
As web development becomes standardized, the Model-View-Controller (MVC) architecture has become more
popular. The basic idea of this mechanism is to separate the data elements (the model), the user interface (the view), and
the code that connects the model and the view (the controller).
Many programming instructors emphasize separating content, layout, and data. However, the way PHP is often
written, it combines all three elements. As a response, web developers often use some form of templating system to try to
separate the content from the view.
Every modern PHP Web application framework employs some kind of templating engine. Most of them use plain
PHP by default (including Symfony 1.x, Zend Framework and CakePHP), but many standalone libraries can be plugged
into your favorite framework or custom application
User actions are passed (as HTTP requests, GET or POST methods) to the controller. The controller is a
piece of code that handles and processes user input and then reads and makes necessary changes to the model,
which is responsible for the storage and modification of data. (In simple terms, the model consists of the
database structure and contents, and the code used to access it.) Then, the controller generates the proper view
that will be sent and displayed to user.
More Secure
Variables are escaped by default before being sent to the view, which is useful in applications that
display user-generated content. Consider a variable with some unknown HTML or JavaScript code being passed
to the view (which should never happen in your application). Escaping the variables prevents malicious code
from being injected in such cases.
Better Code
Separating the layers forces the programmer to design better applications that are easier and cheaper to
maintain. Also, designers and front-end developers don’t have to work with the business-logic code, because
their task is only to display the contents of the variables that are provided to the view. This reduces the risk of the
breaking some PHP code.
Model
Model is the name given to the component that will communicate with the database to manipulate the data. It acts as
a bridge between the View component and the Controller component in the overall architecture. It doesn’t matter to the
Model component what happens to the data when it is passed to the View or Controller components.
The code snippet for running first_model.php is:
<?php
class Model
{
public $string;
public function __construct()
{
$this->string = “Let’s start php with MVC”;
}
}
?>
View
The View requests for data from the Model component and then its final output is determined. View interacts with
the user, and then transfers the user’s reaction to the Controller component to respond accordingly. An example of this is a
link generated by the View component, when a user clicks and an action gets triggered in the Controller.
To run first_view.php, type:
<?php
class View
{
private $model;
private $controller;
public function __construct($controller,$model)
{
$this->controller = $controller;
$this->model = $model;
}
public function output()
{
return “<p>” . $this->model->string . “</p>”;
}
}
?>
Controller
The Controller’s job is to handle data that the user inputs or submits through the forms, and then Model updates this
accordingly in the database. The Controller is nothing without the user’s interactions, which happen through the View
component.
The code snippet for running first_controller.php is:
<?php
class Controller
{
private $model;
public function __construct($model)
{
$this->model = $model;
}
}
?>
<?php
$model = new Model();
$controller = new Controller($model);
$view = new View($controller, $model);
echo $view->output();
?>
Of course, a number of template engines today add a great deal more to templating. One of the more prominent is Twig.
Twig allows you to use a PHP-like syntax to create powerful templates. It also includes features for populating the
variables that help to separate the data from the presentation and the control.