doBoard

do… Web Application Development and Security

Archive for the ‘Security’ Category

Who Says PHP Security Sucks?

Tuesday, November 24th, 2009

Who would say such a thing? Obviously we can’t let that stand. It’s time to bust some myths while raising our own game to the next level.

(An earlier version was published in php|architect, April 2009)

Aside from the trolls who frequent forums and blogs, it’s mainly the enterprise community which carries the lingering perception, rightly or wrongly, that PHP security sucks. As PHP continues to evolve toward the enterprise, it’s going through a slow and messy collision with enterprise culture, standards and criticism. Naturally, PHP and the community have been absorbing lessons and improving, though one of the least understood aspects of this is security and security perceptions. I hope that by discussing security, PHP’s progress can be made smoother and easier than otherwise.
Continue Reading…

ShmooCon Memories

Wednesday, 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 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.

OWASP February 2008

Friday, 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

Thursday, 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

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.

What Is Security, Really?

Monday, 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.