Currently browsing security
Sat, 4 Mar 2006 19:40 UTC
A preview release of the Zend Framework is now available, and, so far, I must say that all looks well.
The one thing that I’m a bit curious about is the apparent removal of the Active Record implementation, Zend_Db_DataObject. The documentation for this object exists in the Programmer’s Reference Guide, but it’s nowhere to be found in the API. I wonder whether the implementation exists in a different form in Zend_Db, or was it scrapped altogether?
The Active Record implementation aside, one of the other features I was looking forward to was the Zend_InputFilter framework. I know that Chris will undoubtedly write much more about this, but I wanted to point out one very cool feature: the strict mode.
The strict mode works like this: you pass an array of tainted data (let’s say the $_POST array) to Zend_InputFilter to create a new object to access the data in a safe manner, and, then, by default, $_POST is set to NULL for the remainder of the script—you simply cannot access the raw, tainted data from $_POST. Here’s an example:
<?php
$filterPost = new Zend_InputFilter($_POST);
$username = $filterPost->isAlpha('username');
var_dump($username);
var_dump($_POST);
?>This strict mode could be very useful in an environment with a team of application developers. Just set auto_prepend_file in php.ini to load up a script that grabs all autoglobal variables ($_POST, $_GET, $_COOKIE, etc.) and stores them to Zend_InputFilter objects, and you never have to worry about your team accessing raw data—they must always use the Zend_InputFilter object to get to the data. (There is a getRaw() method of this object, but I’ll let Chris discuss it in more detail.)
Finally, lots of folks are already talking about this. Here are some links:
No Comments
Permalink
Tags: filter-input, framework, php, security, zend, zend-framework
Thu, 1 Dec 2005 3:26 UTC
A while back, when I was doing some research for a talk on server-side security for PHP, I looked into various “secure” methods for setting up a server for multiple users. Despite my search, I couldn’t find a simple and effective solution for managing a server with a large (and untrusted) user base (as is the case with many virtual hosting companies). Sure, there’s PHP’s safe_mode, but its “safety” is misleading at best. There’s also open_basedir, which helps a little, but it’s not quite enough. I also looked at jailing Apache (both the hard way and the easier way), but even then, all user directories have to be in the root jail, and any user can still read the readable and write to the writable files of another user in the jail.
For my research, I also looked at and tested mod_security, the goal of which is to secure applications from the Apache Web server, and the Hardened PHP Project’s Hardening Patch, which secures PHP applications from the language engine. Both of these are excellent tools and should be assessed by anyone seeking to “harden” their server configuration.
Still, I wanted to find something that would split off Apache so that each user’s site was running as that user instead of the general Apache user that could read and execute all user files. This global user serving and processing all pages is where the root of the problem lies. Yet, if Apache could serve each site as the owner of the site, then the owner’s file permissions could essentially be set to 700 (instead of being world/group readable for the Apache user) and Apache would still serve the pages since it’s running as the privileged user. Even better, run Apache with this configuration, and place it and the system users in a jail; no one would then be able to access any system files or the files of other users.
No matter how many people I asked, I couldn’t find an easy answer for how to do this.
Around that time, someone suggested I look into Metux MPM for Apache, but, from what I understand, Metux uses threading, and running PHP in a threaded environment is not recommended, so the solution needed to be non-threaded.
Finally, via a comment on Christopher Kunz’s blog, I’ve found something that, at least, sounds like what I’m looking for. It’s the Peruser MPM by Telena Internet Services, and it seems that it was created with PHP in mind.
Here’s what the site says about Peruser:
The fundamental concept […] is to run each apache child process as its own user and group, each handling its own set of virtual hosts. Peruser […] can also chroot() apache processes. The result is a sane and secure web server environment for your users, without kludges like PHP’s safe_mode. […] I created Peruser, which provides multiple processes for each unique user/group/chroot.
The site warns against using it in production, and it warns that it breaks mod_ssl and renders Apache not as scalable, but it sounds like a step in the right direction. I’m putting it on my radar to test soon.
6 Comments »
Permalink
Tags: apache, hardened-php, mod_security, peruser-mpm, php, security
Thu, 17 Nov 2005 21:02 UTC
Lately, there has been a good deal of discussion on php-general concerning filtering input. Richard Lynch even tossed out a few of his ideas concerning the use of a $_CLEAN superglobal variable that would merely serve as a reminder to programmers (through its constant use in the PHP manual) to filter input as a “best practice” (see here and here). Furthermore, on Chris Shiflett’s blog, Richard comments that ”[s]urely our base solution for minimal Security should be a fundamental part of the PHP language, not some add-on second thought.”
I tend to agree with Richard, and that’s why I’ve been paying attention to the PECL Input Filter extension.
Back in October, Derick Rethans and Rasmus Lerdorf made their initial release of the PECL Input Filter extension. Since then, I’ve taken some time to play around with it, hack around it, and report a few of the bugs I’ve found, which have since been corrected in HEAD. I’m proud to say that they even used some of my patches. Nevertheless, I’m going to continue to tinker around with this extension to see what else I can break because I think it will be a good tool for promoting best practices to PHP programmers, and the more it’s tested, the better it will be.
Now, on to Richard’s point about security tools being “a fundamental part of the PHP language.” The Input Filter extension right now is only just that: an extension. Yet, recently (15 Nov), I noticed that Jani Taskinen (a.k.a. “sniper”) checked in some revisions with the comment “Prepare for including in PHP core.” This got me thinking, so I asked Derick, and Derick confirmed that the Input Filter extension will be a part of the PHP core in versions 5.1.1 and 6.0. So, there’s one of your built-in security tools right there.
So, now, let’s take a look at some code. Let’s assume that we have a form. On that form are four fields: name, age, email, and list. These are fairly self-explanatory. With name, we expect a string; with age, a number; email, an e-mail address; and with list a value of either 1, 0, yes, or no to determine whether you want to be on the mailing list (it’s a radio button, and, for the sake of argument, let’s assume that the values are “yes” and “no,” but they could be 1, 0, true, false, on, or off; any of these will filter as a BOOLEAN value).
Our processing form might start out like this:
<?php
$clean = array();
$clean['name'] = input_get(INPUT_POST, 'name', FL_REGEXP, array('regexp' => '^[\w ]+$'));
$clean['age'] = input_get(INPUT_POST, 'age', FL_INT);
$clean['email'] = input_get(INPUT_POST, 'email', FL_EMAIL);
$clean['list'] = input_get(INPUT_POST, 'list', FL_BOOLEAN);
?>The constants passed to the function determine the type of filtering, and if the input variable matches the filter, then it returns the raw and unchanged value. If it doesn’t match, then it returns NULL. So, at worst, $clean (in this implementation) will contain a NULL value.
You may also filter script variables and even perform some sanitizing. The following example will strip the HTML tags from $name and store the value “Ben Ramsey” to $clean[‘name’].
<?php
$clean = array();
$name = '<b>Ben Ramsey</b>';
$clean['name'] = filter_data($name, FS_STRING);
?>
While I am not a big fan of sanitizing functions (I believe that programmers should use a whitelist approach and simply filter input for valid data and, on invalid data, require the user to enter valid data), I can definitely see the advantages of including these filtering functions in the core to promote best practices. It should be noted that it is just as easy to filter input without these built-in functions, but, perhaps, with the inclusion of these functions, it will encourage others to start properly filtering data.
Finally, I’d like to point out that the Input Filter extension is still in “beta” and should not be used in production environments. There are still some bugs and functionality to work out before it can be safe for production use.
UPDATE (19 Nov): Version 0.9.3, which includes several bug fixes, was released yesterday.
10 Comments »
Permalink
Tags: filter-input, pecl, php, security
Thu, 27 Oct 2005 15:36 UTC
I’ve just finished reading Chris Shiflett’s Essential PHP Security, and I have to say that it’s a great book. It’s very small—weighing in at only 109 pages (including the appendices and index)—but I think Chris feels this is its main draw. Indeed, it’s a quick and easy read, but that doesn’t mean it’s lacking in thoughtful and careful attention to detail—on the contrary. Rather, Chris has created a very concise and easy-to-read guide to Web application security. The language is clear, as are the examples.
For anyone who’s ever attended one of Chris’s talks on PHP security, this is the ultimate companion. For those who haven’t had the privilege of sitting in on his talks, this book is everything that you’re missing.
It’s available on Amazon for $19.77.
Now, for some fun, I used the Rednoize MD5 database mentioned in Chapter 3 of Essential PHP Security to create a little AJAX application to create MD5 hashes of strings, as well as check for the existence of a hash in the MD5 database. According to the Rednoize blog, there are over 2 million MD5 hashes stored with their counterparts in the database. In addition, I’m using Paul Johnston’s JavaScript MD5 library to handle the string-to-MD5 conversion on the client side (rather than sending an extra request to the server).
Now, on the Rednoize MD5 site, when you enter a string (as opposed to an MD5 hash) that does not exist in the database, it automatically creates a hash of that string and adds it to the database. Thus, you should beware if you enter your own passwords, for then, your passwords and their corresponding MD5 hashes will be in the database. My implementation does not do this, however. If the string entered is not exactly 32 alpha-numeric characters, then it will not try to retrieve a value for it from the MD5 database.
If you want, give my little MD5 reversal application a try.
UPDATE: The MD5 database does not appear to store string values longer than 32 characters; it appears to truncate strings at 32 characters and save the MD5 hash of the truncated string. So, be sure all your passwords are > 32 characters. 
UPDATE (6 Nov ‘05): I’ve moved my MD5 hash lookup application to http://md5.benramsey.com/, where it will live on a permanent basis.
8 Comments »
Permalink
Tags: ajax, books, md5, php, security
Sun, 11 Sep 2005 0:49 UTC
From the introduction:
“You’ve heard a lot of buzz about security in PHP, lately, but you’re still confused about this ‘input filtering’ thing? Ben Ramsey lends a helping hand in part 2 of his mini-series on this technique.”
2 Comments »
Permalink
Tags: articles, filter-input, php, php-architect, security, tips-and-tricks
Fri, 19 Aug 2005 21:42 UTC
So, I decided to have a little bit of fun, and I was feeling creative one day. Thus, inspired by
George Schlossnagle, who’s made his own PHP T-shirts, and
a picture I took of
Chris Shiflett during his talk at OSCON, I decided to create PHP’s very own security mantra T-shirt bearing none other than the likeness of Chris Shiflett. I hope I don’t owe him money for this . . . maybe just a beer, but no money, Chris.
You can get your very own at CafePress.
2 Comments »
Permalink
Tags: filter-input, humor, php, security
Thu, 21 Jul 2005 21:27 UTC
From the introduction:
“This year has seen an increased focus on PHP security, and this is good for the language, developers, and business community. One phrase that comes to mind when discussing secure coding practices is Chris Shiflett’s mantra of ‘filter input, escape output.’ While we know what this means in a general sense, practical examples elude us. Ben Ramsey provides part one of his input filtering series, chock full of code examples.”
5 Comments »
Permalink
Tags: articles, filter-input, php, php-architect, security, tips-and-tricks
Wed, 6 Jul 2005 21:14 UTC
Tomorrow marks Atlanta PHP’s fourth consecutive, regular meeting at New Horizons in Tucker, GA. Originally, Matt Kern was slated to present a talk on Ajax, but he is now gearing up to move to Oregon, so he is not able to prepare his presentation. Thus, I have taken up the reigns again, and I will be presenting a talk that I’m preparing for some of the fall conferences (in the event that my proposals are selected).
The talk I’m presenting was actually inspired by several questions asked during my presentation at the last Atlanta PHP meeting, in which I briefly covered cross-site scripting (XSS) and cross-site request forgeries (CSRF) but went on to describe server configuration instead of a more in-depth discussion on XSS and CSRF. This talk goes into more detail where the other left off and approaches these attacks from the application (code) level.
XSS and CSRF: Programmers Prepare, Users Beware
Cross-site scripting (XSS) and cross-site request forgeries (CSRF) are often confused as being one and the same, but this misconception can lead to disastrous results. In this talk, you will encounter each of these attacks through examples and learn to distinguish between them. You will also examine secure coding practices and techniques for prevention.
So, if you’re in the Atlanta area tomorrow, come on out and join Atlanta PHP at 7:00 PM EDT at New Horizons in Tucker.
Looking forward, our August and September meetings are already shaping up and the topics are very promising. We’ll discuss what’s in the forecast at our meeting tomorrow.
12 Comments »
Permalink
Tags: atlantaphp, csrf, php, security, talks, xss
