About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

All posts for Aug 2008

Inspecting and Hacking HTTP

There are numerous reasons you might want to inspect HTTP when debugging a problem. If you've ever tried to debug problems with sessions, cookies, or redirects, I'm sure you can appreciate how hard it is without taking a close look at what's going on behind the scenes.

There are numerous tools to help you inspect HTTP. If you're a Firefox user, you can use LiveHTTPHeaders or HttpFox. (Please feel free to suggest others.) If you use Safari, you can enable the debug menu:

$ defaults write com.apple.Safari IncludeDebugMenu 1

This gives you access to the Web Inspector, which displays HTTP headers under Network. Unfortunately, it seems to be limited to the headers, omitting everything else. (Safari users, are there better options?)

If you're using Safari 3, replace IncludeDebugMenu with IncludeDevelopMenu. You'll know it's enabled when you see the Develop menu.

Sometimes it's useful to make a slight modification to the request and try it again to see if it fixes the problem. Many HTTP tools let you do this, and tamperdata for Firefox is particularly useful.

Despite having numerous tools available, I still find myself using telnet pretty regularly, partly because I want to minimize the risk that the tool I'm using is giving me false information, whether it's due to a bug in the tool or simply an error in my interpretation or use of it.

If you've never used telnet to send requests to a web server, you might be surprised by how easy it is:

$ telnet google.com 80

Once connected, you can enter a simple GET request to try it out:

GET / HTTP/1.1
Host: google.com

Because Google prefers the superfluous www subdomain, you'll get a 301 response. If you want to follow the redirect like a browser would, simply change the Host header in your request, and you should get a 200 response that includes the content.

When debugging a secure URL, telnet won't help you. Luckily, openssl provides similar simplicity:

openssl s_client -connect google.com:443

You might prefer -quiet if you don't find the s_client output useful.

You can use the same GET request as before to try it out, or you can copy a real request your browser sends by using one of the HTTP inspectors like LiveHTTPHeaders.

Do you have any related tips for budding web developers?

Security 2.0 in Cincinnati

I'll be visiting Cincinnati briefly tomorrow (Thu, 21 Aug 2008) to give my talk entitled Security 2.0 at the local PHP user group, OINK-PUG. Elizabeth Naramore is kindly hosting me, so I'll be able to fraternize after the meeting, which is always the best part of any user group.

This talk is one of the least PHP-specific talks I give, so if you're in the area and interested in learning a bit more about evolving trends in web application security, I hope you'll join us. In case it helps convince you, here's the talk description:

Web 2.0 has been described as many things. It's the Web as a platform, a network of networks, the architecture of participation. However you choose to define it, the way we build applications online has changed. Web sites do more by empowering users, but this has opened a Pandora's box. Cross-site scripting (XSS), cross-site request forgeries (CSRF), and Ajax are being combined in creative new ways to launch sophisticated attacks that penetrate firewalls, target users, and spread like worms.

This talk examines this new threat, dubbed Security 2.0, by demonstrating some hypothetical and real exploits as well as discussing methods of safeguard and prevention.

The meeting takes place at Bridge Worldwide, who happen to have a nice map on their site. As far as I can tell, their office is located on the word Cincinnati (on Google Maps), so it must be smack in the middle of the city.

I might bring an extra copy or two of Essential PHP Security to give away, and you will receive a copy of the slides of my tutorial of the same name as a token of appreciation for sharing your time with us. I have also heard unconfirmed reports that there will be pole dancing.

I hope to see you there. :-)

End of Life for PHP 4

Today is 8/8/8, which is interesting for a few reasons, one of which is that it marks the end of PHP 4. What does this mean? It means yesterday's release of 4.4.9 is the final release of PHP 4. More information can be gleaned from the mailing list archives, beginning with Derick's request to drop support:

I am trying to gauge what people feel about dropping support for PHP 4 at the end of this year.

Derick caveated his suggestion with the idea of continuing to publish new releases that address security vulnerabilities. Rasmus didn't see the point:

I don't really understand what dropping support means if we will still release security fixes. That's the mode we have been in for at least a year, so what would change at the end of the year?

He suggested a stronger stance:

I'd be more in favour of a statement that put a final death date on it which means no new releases of any sort. We could still say security-fixes only by the end of the year and then death by 08/08/08 or something like that.

So, here we are. PHP 4 is dead. Long live PHP.