doBoard

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.

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!

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 ihackcharities.org, 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.

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!

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.

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.

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.

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”.

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.

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.