Although it is often derided in the security community as unsafe and as the harbinger of new security vulnerabilities in web applications, HTML 5 includes a number of notable security enhancements. Using native HTML 5 features we can actually eliminate most cross site scripting (XSS) attacks at the client side. Doing this merely requires clean application architecture to segregate dynamic display code, properly defined trusted origin domains, and use of the HTML content security policy. These features even include reporting capabilities that can be used to detect XSS attacks in the client browsers and report them back to the server.
An overview of cross site scripting (XSS) prevention functions provided in the PHP language, including discussion of suitable uses and guidance for approach to untrusted user input sanitizing. Arbitrary script injection flaws are widespread and pernicious among web applications. Understanding and appropriately utilizing built in language controls to prevent XSS is critical in removing this class of vulnerability from your web application.
In Drupal 7 it is quite convenient to be able to display blocks using conditional PHP logic. To set this up we merely need to enable a block in the block display interface (at #overlay=admin/structure/block). If we wanted, say, to display the "Who's online" block only to users not running Chrome we could use some conditional PHP to do this. Chrome doesn't report its HTTP user agent in requests, so we can check if the variable $_SERVER['HTTP_USER_AGENT'] is set.
As SANS is reporting at http://isc.sans.edu/diary.html?storyid=11413 there is an issue with PHP 5.3.7 that could have security implications. I was able to confirm this bug report. However, while this bug is problematic, it is only reported to affect the crypt() function (http://php.net/manual/en/function.crypt.php), and not in any sort of exploitable compromise kind of way that I can think of (which isn't to say one doesn't exist).
As SANS is reporting at http://isc.sans.edu/diary.html?storyid=11413 there is an issue with PHP 5.3.7 that could have security implications. I was able to confirm this bug report. However, while this bug is problematic, it is only reported to affect the crypt() function (http://php.net/manual/en/function.crypt.php), and not in any sort of exploitable compromise kind of way that I can think of (which isn't to say one doesn't exist).
PHP remote shell backdoors are scripts that are uploaded by attackers onto compromised web servers in order to provide an easy way to issue commands on the remote server. Their capabilities vary, from simple scripts that evaluate URL arguments, execute them with a function, then display the results on the web page, to complex user interfaces that provide point and click functionality to perform many post compromise activities.
Local file inclusion (LFI) is a nasty vulnerability that affects many web applications. Normally, dynamic file inclusion is an extremely useful feature of scripting languages such as PHP. This compartmentalization allows for separation of logic code, display code, and various other components into separate areas of the application structure. However, dynamic file inclusion can open the door for vulnerabilities. Clever attackers can exploit these vulnerabilities to escalate LFI vulnerabilities into arbitrary code execution (ACE) attacks.
Several high profile arbitrary code execution vulnerabilities in PHP web applications stem from improper handling of PCRE (Perl Compatible Regular Expression) functions. PCRE is designed to implement regular expressions for the preg_ functions in PHP (such as preg_match and preg_replace). Under most circumstances the PCRE engine is completely safe. It does, however, provide the /e modifier which allows evaluation of PHP code in the preg_replace function. This can be extremely dangerous if used carelessly. With the addition of this flag the normally innocuous search and replace function becomes a potential vulnerability.
Null byte poisoning can be an extremely dangerous problem in PHP applications. Null byte poisoning is often used as a technique to exploit arbitrary local and remote file include vulnerabilities, information disclosure vulnerabilities, and arbitrary filesystem manipulation vulnerabilities. Many of the functions vulnerable to null byte poisoning in PHP operate on the filesystem and can be the source of severe problems if misused. In order to fully understand the PHP null byte issue we have to examine how C handles strings.
File include vulnerabilities in PHP present a pervasive problem that eludes many efforts at remediation. Understanding the dangers posed by PHP include and require functions is critical to defending web application. There are many strategies for utilizing file inclusion safely to prevent against file include vulnerabilities (both local and remote) as well as directory traversal attacks and information disclosure vulnerabilities. Using native PHP functionality allows a developer to produce safe, and maintainable PHP based web applications.
CentOS is a wonderful, stable, enterprise Linux distribution. Because it follows an enterprise model, however, the latest and greatest packages are often not available for installation from RPM repositories. In order to deploy binaries such as the new PHP 5.3 you'll need to compile them from source. Luckily this isn't terribly hard, but it does take some trial and error. I've tried to enumerate the process on a CentOS 5.3 host to take some of the pain out of it.
So for my latest math homework assignment I was tasked to develop a powermod function similar to the one available in Wolfram’s Mathematica. We were told to do it in any programming language, but Mathematica and Maple were recommended.
Roundcube is a wonderful dynamic web based e-mail client. It serves pretty much all of my needs, except a few. Recently I’ve been working on taking advantage of the fact that it’s open source software to add some new features that I feel are critical for me. One such feature was to expand the built in contacts function. I like to keep track of additional information, such as phone numbers, addresses, etc. in my online contact directory. Altering RoundCube to facilitate this functionality was actually quite simple and I’ve outlined the steps below to add a ‘Phone’ field to a contact record, but you can repeat the process to add pretty much any field you’d like.
After using Roundcube for some time I thought it would be neat to expand the Addressbook functionality to include things like actual physical addresses and phone numbers to each contact record. Additionally, since Roundcube is a hosted email solution, I thought it would be nice to be able to share contacts amongst other users on the same system. By adding a flag to each record, users can share their contacts amongst one another. This is nice because it cuts down on duplicate records and allows people to look up contact information with less work.
To modify RoundCube Email to allow for expanded contacts you first need to create new fields in the database. Here are the MySQL commands, but I�m sure you can replicate them through another interface:
The first, and in my opinion, most important step in approaching a new PHP project is to identify the goals and business rules of a project. This means understanding the purpose of the application as well as the real world system that it will be mimicking.
The c99 shell is a somewhat notorious piece of PHP malware. C99 shell is often uploaded to a compromised web application to provide an interface to an attacker. The c99 shell allows an attacker to hijack the web server process, allowing the attacker to issue commands on the server as the account under which PHP is running.
Google's new Safe Browsing API is a neat service that allows you to poll the MD5 hashes of known malware and phishing sites. This is especially handy because you can check URLs submitted to your site or service by internet users to make sure that they don't include malicious links. The API is relatively well documented at http://code.google.com/apis/safebrowsing/developers_guide.html so the purpose of this tutorial is mainly focused on how you can utilize PHP to implement the API. If you use Firefox you are probably familiar with the malware or phishing warning screen that shows up when you visit suspicious sites. This feature implements the Safe Browsing API.
Separating the elements of your LAMP stack makes a lot of security sense. If you host your web server on a different machine than your database server you get a couple of wins. A compromise in your database won't allow an attacker to alter web pages or write files to the web server, and compromise of your web server wouldn't allow attackers to read the text based MySQL data files. By segregating the functionality you effectively sandbox each tier of your web application to prevent the escalation of compromises. The potential downside of separating these elements, however, is that you introduce a new attack vector, namely snooping traffic on the wire as it travels between the database and the web server.
PHPIDS (http://php-ids.org) is a very intriguing project that mimics the functionality of much more involved intrusion detection systems. PHPIDS is written entirely in PHP, so it should be supported by almost any platform that supports PHP applications, although PHP version 5.1.2 or greater is required. PHPIDS also requires SimpleXML support and PDO in order to facilitate database interaction. Because PHPIDS is written in the same language as applications it is designed to defend installation is eased considerably. Chances are that if your PHP application is running you can install PHPIDS.
MySQL provides a number of features that can be used to greatly increase the security of your PHP application. Because MySQL is often used to store critical data for web applications, it is a common target for attackers. Gaining access to the database often allows access to sensitive data. In most development models PHP is used to provide views into the database layer, and in a sense to shield the database from end users. However, flaws in PHP applications can expose the database to malicious users. By utilizing some of the security features in MySQL you can protect your database from flaws introduced at the PHP layer.
Suhosin is an extremely valuable part of any effort to secure a PHP installation. Many PHP users have long been aware of Suhosin as FreeBSD, OpenSuSE, Debian and Mandriva come with Suhosin preconfigured or available for their PHP distribution. Suhosin is an add-on to PHP that provides additional protections against many attack vectors. For instance, Suhosin will note when a URL variable is overly long (evidence of a buffer overflow attempt or other nastiness) and automatically drop the variable. Suhosin will also protect against buffer overflow attacks, ASCII null characters in variables (including POST and COOKIE variables), directory traversal attacks, some common injection points for string format vulnerabilities, unauthorized remote file inclusion, and many other vectors
The built in PHP pathinfo() command is commonly used by developers to filter filetypes for inclusion. However, many developers fail to realize that using extension overloading and classic null byte injection attackers can manipulate the pathinfo() evaluations of file extensions and file names in order to exploit arbitrary file include vulnerabilities introducing by improper use of pathinfo().
PHP's default configuration file, php.ini (usually found in /etc/php.ini on most Linux systems) contains a host of functionality that can be used to help secure your web applications. Unfortunately many PHP users and administrators are unfamiliar with the various options that are available with php.ini and leave the file in it's stock configuration. By utilizing a few of the security related options in the configuration file you can greatly strengthen the security posture of web applications running on your server.
Database interaction is a critical component of most web based applications and unfortunately it can be the point at which many security vulnerabilities are introduced. Both PHP and MySQL include many features that developers can use to create safer web applications. Learning to use these features lowers the possibility of applications being exploited through vectors like SQL injection attacks.
RoundCube Webmail Project (http://roundcube.net) is a popular, AJAX enabled web based email client. RoundCube utilizes a user friendly interface and allows users to access IMAP email via their web browser. RoundCube is written in PHP with a MySQL database and utilizes XHTML and CSS. RoundCube's intuitive interface and advanced UI functionality have made it a popular open source webmail client. Unfortunately RoundCube versions 0.2-3 beta and 0.2-1 alpha were found to contain a critical flaw that allowed remote attackers to execute arbitrary code with the privileges of the web server (CVE-2008-5619). This article examines the root causes of that flaw and it's implications.
Many PHP based web applications use md5 hashing in order to obscure stored passwords. At first glance this seems like an effective security measure, however upon further examination it becomes clear that this approach does little to secure a password. Let us assume that an attacker somehow captures the md5 hash of a users password. This could happen in many ways, the most obvious being a SQL injection that reveals the password.
I recently wondered if I could use a common encryption algorithm across both PHP and Perl. In this particular case I wanted to know if PHP and Perl could both utilize the Blowfish encryption algorithm to share encrypted data (with data being encrypted in one language and decrypted in another).
A discussion of preventative measures PHP application developers can take when deploying their programs on a Linux filesystem. This includes setting proper file permissions as well as protecting files from unwanted exposure on the web.
Failing gracefully is often an application development goal that gets overlooked in pursuit of development. Quite often programmers are so task oriented that they focus on the goal of the software rather than the process. This is understandable since developers can predict input and flow in the controlled environments of their development setup. It isn't until software is released to actual users that unexpected inputs begin to crop up. Designing modular software that handles exceptions in a meaningful way is one of the touches that distinguishes good software from great software.
When tackling a large (or small) web development task it often pays huge dividends down the road to give consideration to scalability. Even if you think your application will be small and easily maintained (or run unmaintained), using a pattern for design can ease your development load, streamline your applications, and alleviate your maintenance headaches in the future.
A look at the notorious problem of PHP namespace protection.
A short discussion about object prototyping and introspection in PHP5
As a display layer, both Smarty (templating) and XML (transformation) present interesting opportunities and challenges to PHP developers. Both introduce exciting new possibilities, but careful consideration of client needs and maintenance requirements should guide your decision as to which technology to implement. The two differ quite drastically in conceptual framework and thus produce very different working results.
Short description of how to use the PHP CLI (Command Line Interface) to create and utilize PHP scripts from a shell.
A quick primer on how to use factory classes in PHP and their relevance.
A short guide to setting up an Apache, MySQL and PHP system on your Windows machine including common errors.
This article aims to show you how to retrieve and use MySQL result sets in PHP. Included are a few functions for making data retrieval, and your code, more manageable.
Documentation of my experimentation and eventual success with a system to import POP3 email into a MySQL database via a web interface.
Overview white paper developed for training, discussion of using and installing PHP as a scripting language.