do… Web Application Development and Security

ShmooCon Memories

March 26th, 2008

I’ve been procrastinating on writing about the ShmooCon hacker convention, and today the thought bugged me enough to finally do something.

I signed up at Hackers for Charity, formerly known as, after originally committing at ShmooCon. I ran into the founder and legendary hacker Johnny Long in the hallway.

Factoid: It may be illegal to possess Kevin Mitnick’s business card in DC because it doubles as a lockpicking kit.

GSM encryption technology (specifically, the widely used a5 algorithm) is essentially broken. At the time of presentation, a research team had gone 1 month into a 3 month process of calculating the full rainbow table needed to accelerate the process of cracking session keys. With custom hardware, it will be possible to decrypt a conversation after 30 minutes (one FPGA and laptop) or 30 seconds (16 FPGAs and solid state drives at total cost around $500K). This is well within the reach of some criminals, wealthy organizations, and governments.

I knew that voting machines (especially, but not only, the electronic touch-screen type) had security issues, but I had no idea just how shockingly bad. If you were to research the subject now you might find some reports that were redacted and otherwise watered down. But at ShmooCon I saw a presentation given by Sandy Clark, one of the top investigators chartered by the state of Ohio. She presented specific examples of how, with the right knowledge, a few simple tools in some cases, and the wrong intentions, it would be fairly easy to abuse commonly used voting machines and thereby alter the results of elections and the integrity of the counting & recounting processes. For unethical and ruthless politicians and their supporters, this provides a powerful means to influence or steal the vote. For anyone who doesn’t want more unethical and ruthless people running our country, it’s critically important to get those machines fixed, and that means overcoming the inertia of government bureaucracies and entrenched interests.

OWASP February 2008

February 8th, 2008

At my first local OWASP meeting, Andre Ludwig presented on “…the intersection between web application security and the attackers mindset.”

Doug Wilson and Mark Bristow were very active participants and just happened to have a laptop with the same presentation and security demo I saw them use at Refresh DC a couple months ago. Very handy!

CapSec January 2008

January 31st, 2008

After work today I walked to The Brickskeller and enjoyed a couple beers with a few of the CapSec group including Doug Wilson.

One thing we discussed was that with tech groups formed around common interests, like web development, linux, or security, it’s very easy for people to stick with what and who they know. But in security, work roles tend to be multidisciplinary. Security often is one of several hats to wear or is built upon another specialty such as networking or development. Because of this many security professionals have the perspective and the opportunity to cross-pollinate by participating in other groups where security isn’t the primary focus but is still relevant.

I think, the more people who act on that thought, the better for the community.

20 Hacker Tricks for Attacking Web Apps

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.

What Is Security, Really?

November 12th, 2007

You get a different answer each time depending on who you listen to:

“It’s simple – patches, firewalls, anti-virus and the latest security products.”

The product vendors would like you to believe that.

“Preventing and fixing known security holes like XSS, SQL injection and CSRF.”

A good web developer might say that.

“Efficiently detecting and blocking hacking attempts.”

Spoken like someone who has been in the trenches. Whack-a-mole at Internet speed.

“Complying with security rules and requirements.”

Smells like bureaucrats. Hopefully the thousands (!) of requirements aren’t constantly changing, poorly defined, contradictory, or ill-conceived…

With more variations than we can count, there has to be a better way to get a handle on security. So what’s the bottom line?

Security is keeping bad events to a minimum.

That’s my simplest, broadest and most fundamental definition of security. Everything else derives one way or another from that basic goal.

So what does it mean to keep “bad events” to a minimum? What are these bad things?

It’s bad to lose control of sensitive information, like credit card numbers or passwords, allowing it to go where harm can result.

It’s bad to lose integrity of your information and your systems, allowing data to be altered, systems to be broken into, transactions to be falsified or erased, etc.

It’s bad for services to be unreliable or unavailable to those who legitimately are trying to use them.

As the news headlines remind us, there’s a growing community of people who are actively trying to make those bad things happen, with a wide variety of increasingly powerful motivations, tools and knowledge.

So what to do about this?

First, identify what you have that needs protection.

That might be sensitive customer data, confidential business information, computer-based services that are vital to business operations, and so forth. Understand what it is, where it resides, and how it’s processed and transmitted by your systems.

Second, understand the risks and damage that can result from problems with protection.

Where are your systems vulnerable? How much damage would be caused by leaking medical records? Tampering with financials? System takedown? How likely is it that such things will happen? What will that mean in terms of money?

Third, decide what protective measures to take.

You might want people to prove their identity before they can access private information on your system. You might want security audits of your financial systems. You might want to test your systems to ensure they’re not easily taken down. There’s a large menu of security controls including the things mentioned at the beginning of this post. And now you’re in a position to make intelligent choices balancing risks vs costs and setting priorities.

Fourth, implement your chosen security controls.

Have qualified people do this correctly. Clear enough tasks off their plates so they can focus on getting this done. Ensure they have the organizational support to make reasonable progress.

Fifth, continue to re-evaluate and update your security over time as changes happen.

This may require management attention, periodic reviews and gap analysis, and one or more workers who have security management as their primary responsibility. Ideally everyone in the organization will take ownership for the security aspects of what they do.

This approach will help ensure that the right things are protected to the appropriate degree, avoiding excess and preventing or resolving deficiencies in an efficient way. By taking a step back, and thinking of security in terms of the fundamentals, it becomes much clearer how to proceed and where to focus your efforts.

By doing this you’ll be well on your way toward keeping bad events to a minimum.

DC PHP Conference 2007 – Security Highlights

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?

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

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.

The New doBoard

November 2nd, 2007

Despite all efforts to cling to the past, the times have changed. So I’ve retired the old website that served well for six years.

The new doBoard will participate in the web technology and security communities. Expect to see content and discussion about web development and web application security, plus the occasional foray into the broader technology, security, and business fields.