do… Web Application Development and Security

Posts Tagged ‘DC PHP’

DC PHP Developers’ Community

Thursday, March 12th, 2009

A new website for the PHP community launched yesterday: Thanks to Keith Casey, Brandon Savage and Joe LeBlanc for making that happen.

The new site:

  • Has a blog with community-related content
  • Is a hub for interesting posts and sites around the community
  • Includes a quick-and-easy signup for the DC PHP Developers’ Group email list
  • Has a directory of DC PHP developers and the companies we work for (I’m the moderator)

On a semi-related note, I’m now organizing DC PHP Beverage Subgroup meetings in Washington, DC. This is nothing formal, just an opportunity for DC PHP community members and friends to gather socially. The first meeting I organized was at R.F.D. Washington on March 3rd which coincided with a large and friendly gathering of people who were in town for DrupalCon.

How to Make Application Security Suck Less

Wednesday, June 4th, 2008

Application security sucks because it’s a wicked hard problem to mix the goals of security and application development within real-life projects.

If application development is about making an app do what it’s supposed to do, then application security is about making sure an app doesn’t do what it’s not supposed to do, despite real world conditions which may be hostile and chaotic.

“Hard core” security has become a massively complex black art with its own priesthood. As a result, the security community has generated an enormous volume of arcane information about security vulnerabilities and countermeasures.

Many conference presentations, books and articles about application security have tried to boil that down for the developer community, with excellent coverage of the top several types of security flaws. But security has a long tail, so that approach leaves vast territory uncovered.

That approach also doesn’t necessarily give developers the context and perspective necessary to judge the costs and benefits of security, and to make sound decisions about what really does or doesn’t need to be done. So I decided to address application security in a different way.

I gave a talk on this topic yesterday at the 2008 DC PHP Conference in Washington, DC. I’m posting a copy of the presentation slides and speaker notes for all of you here.

The goal of this talk is to help you wrap your brain around core concepts of application security, and thereby to make it easier to deal with correctly.

The talk begins with “What is Security, Really?”, poking fun at misconceptions and presenting the idea that security is keeping bad events to a minimum despite even skillful attempts to cause them.

Then it covers fundamental concepts and practices including: how to identify what needs protection; vulnerabilities and countermeasures with PHP examples; and how to avoid security excess by considering risk in a consistent way.

By the end, you should have a conceptual framework for application security that will at the same time simplify the problem space and provide more rigorous results.

So it’ll suck less.

DC PHP Conference & Expo, June 2-4, 2008

Sunday, April 13th, 2008

I’m going to talk about “How to Make Application Security Suck Less” at this international conference, hosted locally in Washington, DC.

The keynote speakers will be Kshemendra Paul from OMB, Christopher Jones from Oracle, and Chris Shiflett from OmniTI.

Local PHP agitator Keith Casey will moderate the featured panel discussion on PHP IDEs. Panelists will be: Cal Evans (Zend), Wez Furlong (OmniTI), David Sklar (Ning), Eli White (Digg), and Jeff Griffiths (ActiveState).

I’m looking forward to the interesting people, informative talks and great conversations that I expect based on last year’s experience. Hope to see you there!

20 Hacker Tricks for Attacking Web Apps

Monday, January 21st, 2008

At the DC PHP Developers Group meeting on January 9th I had the pleasure of giving my very first talk to a tech group.

Since other people have given excellent talks focusing on a few top attack methods, I tried to give a broader survey to show some of the diversity of the hacking mindset. If this talk triggered some thoughts like, “It never occurred to me that hackers might try that”, then I met my goal.

My original slides were a little rough… to avoid shame and embarrassment I edited them a bit before posting them here for public consumption:

20 Hacker Tricks for Attacking Web Apps

I welcome any comments, especially if they will help improve the content or my performance. I’d like to give updated talks along the same line in the future. I’d also like to cover ways to harden web applications against hacking.

DC PHP Conference 2007 – Security Highlights

Monday, November 12th, 2007

This year’s conference had a fairly heavy dose of security.

Chris Shiflett’s keynote, “Security 2.0″, included nice discussions of XSS (cross-site scripting) and CSRF (cross-site request forgery) with an AJAX scenario.

Ed Finkler presented on the PHPSecInfo project, a tool to scan the PHP environment for security issues, and Inspekt, a PHP library to protect applications from the potentially tainted contents of superglobals.

Eli White presented “Help, My Website Has Been Hacked! Now What?” and covered how to prepare for and respond to hacking incidents, based on his experiences at Digg.

Damien Seguy presented on MySQL Security.

While not primarily security-related, Keith Casey included some discussion about security while presenting “Designing REST Web Services”.

Q & A: Risk of Duplicates When Using MD5?

Monday, November 12th, 2007


Update April 27th, 2013 – WARNING – if your intention is to encrypt (hash) passwords, this isn’t the code you’re looking for. Because of massive advances in attacker capabilities the code in the original post is obsolete for that purpose. It’s better to use the built-in password hashing functions or an alternative made with appropriate techniques and expert review.


Yes, MD5 can produce hash collisions in a very small percentage of cases. For many uses this shouldn’t be significant, but for security there are better options.

I prefer the SHA-2 series, referred to as SHA-224/256/384/512, because the algorithms are strong and widely supported.

If you need the hashes to be un-guessable then I’d recommend hashing more than just the input data. A well accepted strategy is to include a secret key in the computation, resulting in a keyed-Hash Message Authentication Code (HMAC), and another useful technique is to concatenate a “salt”, which may or may not be secret, with the input.

PHP versions >= 5.1.2 have the hash_hmac() and hash() functions:

$hmac = hash_hmac('sha256', $data, $key); // hex string output

$hmac = base64_encode(hash_hmac('sha256', $data, $key, TRUE)); // force binary output before encoding

$hash = hash('sha256', $data . $salt);

PHP versions < 5.3 have the mhash() function:

$hmac = base64_encode(mhash(MHASH_SHA256, $data, $key)); // mhash produces binary output

$hash = bin2hex(mhash(MHASH_SHA256, $data . $salt));

There’s a nice table of algorithms and their properties on Wikipedia.

Original email discussion was on the DC PHP Developers Group list.

DC PHP Conference 2007

Tuesday, November 6th, 2007

I’m going to the DC PHP Conference 2007 in Washington, DC, November 7-9. The keynote will be “Security 2.0″ by Chris Shiflett. Looking forward to seeing the PHP security guru in action, and I’ll probably run into several members of the DC PHP Developers Group.