Security

Security is not an exact science. Below is a list of the recognised security risks and the measures we've implemented to secure OmCore from malicious threats.

PHP security

We have implemented a large number of security measures onto the PHP server and into the PHP scripts to prevent against common security risks.

PHP server settings

REGISTER GLOBALS

"When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier." (http://uk.php.net/manual/en/security.globals.php)

DISPLAY ERRORS

If display errors is on then important server information, such as directory paths, can be revealed to the user if an error occurs.

Display errors is set to off.

Forms and URLs

SEMANTIC URL ATTACKS

$_GET variables should never be trusted within the URL

We use sessions to confirm if users have passed verification and use data from the verified session. i.e. $_SESSION[‘user’]

FILE UPLOAD ATTACKS

is_uploaded_file(); is used to verify if a file has been uploaded
move_uploaded_file(); is then used to move files only if its an uploaded file

CROSS-SITE SCRIPTING (XSS)

Scripts saved in form elements and then presented back on the page can be executed.

We use htmlspecialchars(); to format all output to prevent it being executed.

CROSS-SITE REQUEST FORGERIES

This is where a URL to a processing script accepts $_GET variables to activate it.

For example if the following image was loaded into a browser it would send a request to buy.php to buy 50 pens and anyone already logged in to that site may end up purchasing the items.

We use $_POST instead of $_REQUEST in the form processing script
All forms use a captcha code to protect against spamming.

SPOOFED FORM SUBMISSIONS

This is where the source of a form is copied, set up remotely, and altered so that it can submit alternative data.

All forms use a captcha code to protect against spamming.

SPOOFED HTTP REQUESTS

This is simply where an HTTP request is made from a script and underlines the fact that even the HTTP headers can be modified so no trust can even be put in the header information. For example, don’t rely on checking the Referrer variable $_SERVER[‘HTTP_REFERRER’] to ensure where a page has loaded from.

Data is filtered to remove any risk.

Databases and SQL

SQL INJECTION

This is where a form that obviously activates a MySQL query, such as a login form, is passed a string that manipulates the query. For example, in a login form entering the following as the username:

myuser’ OR ‘x’ = ‘x’ --

could result in the following query

SELECT * FROM users WHERE username = ‘myuser’ OR ‘x’ = ‘x’ -- AND password = ‘password’

We filter user input data and escape data sent to the database.

Sessions and cookies

SESSION FIXATION

A new session identifier can be created on a site that uses sessions by simply placing ?PHPSESSID=1234 on the end of a URL that links to the site. PHP will then use this session from then on in as opposed to generating its own random one. An attacker could do this by placing a link to the site anywhere on the web. If a user uses the link the attacker can then link to the site with the same ID and effectively hijack the users session. This is useful for getting into restricted areas, such as login areas.

The PHP server variable use_only_cookies is set to true preventing PHPSESSID from being accepted in the query string.

Files and commands

TRAVERSING THE FILE SYSTEM

A vulnerability exists if using a variable as part of a filename when accessing a file

$handle = fopen(‘path/$_GET[‘filename’].txt’, ‘r’);

Variables are filtered using basename();

REMOTE FILE RISKS

Similar to traversing the file system above, if the entire path is a variable allows remote files to be reference as though they were local

$contents = file_get_contents($_GET[‘filename’]);

Variables are filtered using basename();

COMMAND INJECTION

The exec() function allows shell commands to be executed using PHP scripts. It is advised to not use this were possible but when required always ensure that if variables are used within the function call, the data should be filtered and escaped

escapeshellcmd(); is used to filter all variables used
Other shell command functions such as passthru(), popen(), shell_exec() and system() are avoided

CODE INJECTION

Placing a variable at the start of an include(); allows someone to potentially include a script from anywhere on the internet and run it on your server. It’s as bad as letting them edit your PHP scripts themselves.

allow_url_fopen is switched off to prevent URLs being loaded

Shared hosting security risks

Exposed source code

Other people hosting on your server can potentially write code that navigates and reads yours, if they can guess the exact path.

Exposed session data

Session data from all users across the server will be stored in a single location, /tmp by default. A simple script can allow uses to read other peoples session data.

Session injection

Users can also write to the session /tmp directory. This allows them to potentially modify the details of sessions and therefore bypass all access restrictions.

File system browsing

A user can create a script that browses the file system to discover the location of your source code.

Safe mode

This sets PHP to ensure that a file being read by a script has the same owner. This doesn’t prevent scripts written in other languages from doing so. It also doesn’t prevent scripts owned by the web server, and those written by PHP are assigned to the user nobody which is the user Apache runs as.