About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.

All posts for Feb 2005

The Birth of a PHP Consultancy

I'm flying to Tennessee this Wednesday to spend a few days meeting with MusiChristian.com and Patrick Reilly. Although I have yet to announce my new PHP consultancy (more on that later), this engagement marks the start of business.

The purpose of the trip is to gain a better understanding of MusiChristian.com's business needs and to help evaluate how their web presence can best fulfill these needs. Their existing web solution is implemented in PHP, and there are several reasons why they have decided to develop a new solution. The most notable reasons are frequent reliability and security problems, and from speaking with Patrick, it sounds like these problems stem from a poor design.

I hope to have the opportunity to help MusiChristian.com enhance and secure their online presence and add value to their already thriving business. It's nice to see businesses taking advantage of PHP like this, and if things go well, I might be able to play a small role in their continued success.

Sign Up for Mastering PHP Security

Today is the last day to sign up for Mastering PHP Security, a live 90 minute talk I'm giving tomorrow as part of the php|symphony series by php|architect.

I'm still tweaking my slides (this is all new material), but here is the basic outline of the talk:

  • The two best PHP programming practices (for security)
  • The two most common PHP application vulnerabilities (for insecurity)
  • Lightning attacks (sounds cool, right?)
  • PHP Security Audit HOWTO (abridged)

I hope to see you there. Sign up here.


Phishing seems to be getting more and more popular. This can only mean one thing - it's successful.

The usual scenario goes like this. You receive an email that makes it sound like you need to visit a web site in order to address some security concern with your account. Clicking the link leads you somewhere other than where you intend to go, but the page looks like you expect. For example, a phishing email going around right now links to http://logon.personal.wamu4u.com:280/login/index.php:

Of course, wamu4u.com is not the same as wamu.com, but if enough people receive this email, there are plenty of victims who won't notice (and who will, by coincidence, bank with Washington Mutual). Once you've been tricked into believing that the phishing site is the real thing, you are asked to provide some sensitive information. For example, if you visit the previous URL and attempt to log in, you will arrive at http://logon.personal.wamu4u.com:280/login/check.php:

This page asks for your name, credit card information, and PIN. Once you provide this, you are redirected to http://www.wamu.com/personal/Welcome/Privacy.htm, a page within the legitimate Washington Mutual web site, possibly unaware that you've just given your personal information to a phisher.

Interestingly enough, whois wamu4u.com shows the following:

Domain Name : wamu4u.com
        Name      : Constance Edwards
        Email     : edwards@mail333.com
        Address   : 1094 SE St Patricks Court, Port Orchard, WA
        Zipcode   : 98367
        Nation    : US
        Tel       : +1.302-338-7956
        Fax       : +1.302-338-7956
::Administrative Contact::
        Name      : Constance Edwards
        Email     : edwards@mail333.com
        Address   : 1094 SE St Patricks Court, Port Orchard, WA
        Zipcode   : 98367
        Nation    : US
        Tel       : +1.302-338-7956
        Fax       : +1.302-338-7956
::Technical Contact::
        Name      : Constance Edwards
        Email     : edwards@mail333.com
        Address   : 1094 SE St Patricks Court, Port Orchard, WA
        Zipcode   : 98367
        Nation    : US
        Tel       : +1.302-338-7956
        Fax       : +1.302-338-7956
::Name Servers::
::Dates & Status::
        Created Date   2005-02-10 07:48:01 EST
        Updated Date   2005-02-10 07:48:01 EST
        Valid Date     2006-02-10 07:48:01 EST
        Status         ACTIVE

Because requests for http://wamu4u.com/ return a server error, and because the phishing attack utilizes port 280, it seems quite possible that the legitimate owner of the site is unaware. However, it sure does seem like these attacks would be very easy to track down. Does anyone know what the big targets (banks, eBay, Paypal, etc.) are doing to address this growing concern? What can we, as web developers, do to help?

SHA-1 Broken

I just read on Bruce Schneier's blog that SHA-1 has been broken. Bruce states:

SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.

He continues:

This attack builds on previous attacks on SHA-0 and SHA-1, and is a major, major cryptanalytic result. It pretty much puts a bullet into SHA-1 as a hash function for digital signatures (although it doesn't affect applications such as HMAC where collisions aren't important).

This is a big deal.

More on Filtering Input and Escaping Output

In my previous blog entry, I summarized the two most important steps (in my opinion) that all PHP developers should take to help secure their applications:

  • Filter input
  • Escape output

These are essentially "the least you can do" in terms of security. I consider anything less to be negligent (we all make mistakes, but these mistakes should be the exception and not the norm).

To my surprise, this simple statement has already been misinterpreted, and this is what prompted me to try to clarify things. Robert Peake writes:

Chris Shiflett has an interesting post on his blog wherein he declares that all PHP security vulnerabilities come from either a lack of flitering input or escaping output.

I hope that's not what I said, especially since it is wrong. :-) Filtering input and escaping output certainly aren't going to protect you from everything, but these two steps can improve the security of your applications substantially with very little effort.

Of course, my simple list leaves out many details, and that's fine. As I mentioned before, this list provides a broad perspective that helps to keep you on track while you focus on the details. I'm trying to help you focus on what's most important, because it's not always practical to implement every safeguard that you know.

The challenge is identifying data that comes from some external source - what is input? Robert mentions something else that I want to correct:

What this really points out once again is that web applications written in PHP do not really need to focus on much more than absolutely everything that a malicious attacker could throw at you through GET, POST or COOKIES (unless they have access to your server ENVIRONMENT ... *shudder*). Once again this means that if register_globals is turned off, these variables can only make their way in neatly packaged into corresponding $_GET, $_POST, and $_COOKIE arrays (as well as $_SESSION).

It is true that all data in $_GET, $_POST, and $_COOKIE is sent from the client and therefore tainted. However, data within $_SESSION is not. This data is persisted on the server and never even exposed over the Internet (unless you have a custom session handler that specifically does this). If you filter data on input, then you will never store tainted data in a session variable. Therefore, you can trust $_SESSION.

$_SERVER contains a mixture. Some of this data is provided by the web server, and some is provided by the client. Try this simple quiz.

Where does the data in each of the following PHP variables originate?


My Top Two PHP Security Practices

Security is not a simple topic, but I think there is a great deal of value to be had in simplistic summaries of secure programming practices. Like an organization's mission statement, they provide a broad perspective that helps to keep you on track while you focus on the details. It is with this in mind that I have decided to promote my Top Two PHP Security Practices, expressed in four words:

  • Filter input
  • Escape output

These are practices that I've been promoting for years, but this is the first time that I've reduced them to such a simplistic list.

I believe that a failure to properly abide by these two practices accounts for a vast majority of all PHP application vulnerabilities. In fact, I am offering a challenge. I believe that at least four of the next five vulnerabilities announced on php|architect's PHP security mailing list will be due to a failure to properly abide by one (or both) of these practices. If I am wrong, I will donate one hundred dollars to the Open Web Application Security Project.

Update: Thanks to Adam's suggestion, I've reduced these practices to two words each.

Referer Buys You Nothing

I am very surprised at how often I see Referer checking being mentioned as a safeguard against form spoofing. I can't properly express how completely useless this is. I've even had people try to argue with me, convinced that this is a sound technique.

Consider a hypothetical form located at http://example.org/form.html:

<form action="/process.php" method="POST"> 
<input type="text" name="foo" />
<input type="submit" />

To spoof this form, an attacker sends an HTTP POST request to http://example.org/process.php. Assuming the developer who wrote process.php is relying on Referer checking to prevent form spoofing, guess what the expected value is? Does this really seem like a big secret? An attacker will get this right every single time.

If you want to do something useful, at least use some bit of information that isn't obvious. One example is to generate a secret token and include it in the form:


= md5(uniqid(rand(), true));
$_SESSION['token'] = $token;


<form action="/process.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<input type="text" name="foo" />
<input type="submit" />

You can check this value in process.php, and it's not very easy to guess. In fact, the only person with a reasonable chance of knowing this value is the person you send it to.

PHP Security Consortium Redux

The launch of the PHP Security Consortium was a big success. It required more work than I expected to get things going, but I think we're now set to make some very positive contributions to the community.

In addition to being mentioned on PHP.net, Zend.com, and Slashdot.org, eWeek published a story about the group's purpose and future direction. Although the story misses a few important points - our formation was not triggered by the Santy worm, and I made no mention of offering security audits - the overall characterization of the PHPSC is pretty accurate.

There are a few notable blogs that mention the event. Jamie Lewis, the CEO of Burton Group, writes:

Given the popularity of PHP, this sounds like a good idea. (Richard Monson-Haefel has been doing some great research for us on how and where enterprises are using the "P" scripting languages, and it's pretty amazing. We'll be publishing that report in a month or so.) Hopefully the group's efforts will lead to better programming practices, the root of many application vulnerabilities.

Richard Monson-Haefel, whom Jamie references, has been in touch with me regarding his report. Although the report and his interest in my counsel were unrelated to the formation of the PHP Security Consortium, he initially expressed some of the misconceptions I hope to help dispel.

Dana Epps, a recognized security expert, writes:

This is a positive move for the language. Lets hope the effort to educate the PHP community causes a rippling effect and promote the fixing of many of the problems that exist in the tools and technologies that reside there today.

Congratulations to the PHPSC, and good luck.

It's nice to see so much attention coming from outside of the PHP community. As Dana mentions, she is not a fan of PHP. Those within the PHP community know that PHP's poor reputation is undeserved. While the focus of our group is not advocacy, we can potentially have a positive effect on the general perception of PHP and security.

Of course, there was some attention given within the PHP community as well. John Lim writes:

The recently formed PHP Security Consortium has an excellent set of links to PHP security articles. The session management articles by Chris Shiflett are excellent. They discuss how session stealing can occur, and the different techniques you can use to minimize the risk.

I appreciate John's kind words, and it's nice to see that these articles are helpful. I have plans to enhance and grow our library, so that it contains links to many approved PHP security resources. The idea is that we will try to endorse quality documentation, regardless of where it is hosted. For resources that already have a home, we will provide a link in our library. For everything else, we will provide a home in the articles section.

Thanks to everyone who supports the PHPSC. I promise to work hard at promoting secure programming practices within our community.