OWASP EU 2009 Coming Soon!

OWASP EU 2009 is coming up! This year, it’s held in Kraków, Poland. Time to book!

Program highlights:

  • Keynote: Ross Anderson from Cambridge University. I’ve wanted to meet Ross for many years. Those guys are legends!
  • Keynote: Bruce Schneier. I bet there are groupies
  • w3af – Andrés Riancho. This is one of the best free toolkits I’ve tried recently. It’s awesome.
  • HTTP Parameter Pollution, Luca Carettoni, Independent Researcher & Stefano Di Paola
  • OWASP Source Code Flaws Top 10 Project, Paulo Perego, Spike Reply
  • O2 Advanced Source Code Analysis Toolkit, Dinis Cruz
  • … many others!

Although I would love to be there – I had a blast at OWASP EU 2006, I can’t attend this year. Which is a shame, because OWASP AU 2009 was huge fun, and I can’t imagine OWASP EU 2009 would be anything less.Don’t make the same mistake as me! Book now!

ESAPI for PHP news

AccessReferenceMap, RandomAccessReferenceMap and IntegerReferenceMap, and enough of the other classes (FileBasedAuthenticator, StringUtilties, etc) are present and working:

ESAPI for PHP tests passing

This is very good news as although some of the other classes in Milestone 1 are complicated, these two classes were actually going to be some of the hardest to port as PHP does not have the equivalent of J2EE Set, List, HashMap, and many other basic data structures. What PHP does have is native associative arrays (somewhat like HashMaps), ArrayObject, and ArrayIterator from the SPL. The problem is that PHP doesn’t like sparse arrays with very long indexes:

$foo["THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX."] = $value

So I had to make up a workable hash function and hope for zero collisions. I tried using spl_object_hash(), but that actually is too good. It uses the object’s value AND pointer position, such that:

$foo = “123″;

$bar = “123″;

spl_object_hash($foo) != spl_object_hash($bar)

I think I still need to add a few more test cases as my hash function WILL collide when there are two direct object references of the same value, and thus will not be safe for some uses.

ESAPI for PHP – first tests passed

I’ve been working on the essentials for OWASP ESAPI, and now it passes its first set of unit tests, in this case a 1:1 mapping of the ESAPI exceptions test class.
PHP ESAPI Exception Test Suite pass

This is the first set of classes that fully passes a set of tests that is exactly equivalent to the J2EE trunk SVN. Yes, it’s one test, but it tests the exceptions thrown by every single one of the Exception classes.

This is key as ESAPI throws a lot of ESAPI exceptions when things go south. In addition to ESAPI exceptions, the PHP port will also throw SPL exceptions, such as InvalidArgument and so on as it makes sense to do so.

To get this far, I’ve had to hand hack the Authenticator, User, Logger, and Intrusion Detection classes – currently no errors are sent out by ESAPI for PHP, but give me a bit of time and it will happen. String Utilities is also partially there. Authenticator is interesting as it actually does generate strong passwords, and actually reads from the resources directory for the user’s file and decodes it into an array. However, some of these behaviors are hard wired to allow more of the Milestone 1 classes to pass tests, rather than be part of the Milestone 3 build.

I’ve started work on the RandomAccessReferenceMap class. It’s almost there; but unfortunately, I’ve got to go to bed as it’s 2 AM. It’s so close I can smell it. Once done, that class is a close relative of the IntegerReferenceAccessMap, and so there are likely to be two valid and useful ESAPI for PHP classes done soon. I’ll see if I can finish it and check it in before I have to go to work on Monday.

Web training news

No posts for like a month or two, and two in one day? Time for some shameless crass philanthropy and some good natured commercialism.

In some exciting news:

  • I’ve donated my one and a bit ESAPI / ASVS training deck I gave at OWASP AU 2009 to OWASP! It’ll be available as soon as the education project finds a home for it. I’ll come back and link to it when it’s ready. Very rarely does an entire 1+ day deck escape into the wild, so I hope the OWASP Education community runs with it, and constantly improves it.
  • My deck is forming the basis of Pure Hacking’s new two day developer training! Obviously, we’ll be extending the deck and giving it the Pure Hacking spin, but fundamentally it’ll be the same focus on building secure applications and not breaking crap applications. Our new deck will be ready at the end of the month for your training pleasure!

In other news, Pure Hacking is holding a one day WebEx (i.e. remote) training session on Testing Web Applications with Ty Miller as your host. If you’re interested, please drop me a line.

ESAPI for PHP

Last night, I spoke to the phpMELB folks for an hour on ESAPI for PHP.

The talk went well, and they taped it. When the video appears, I will link to it.

More importantly, I worked on ESAPI for a couple of hours after returning last night, and finally have something to show everyone! ESAPI for PHP almost passes some tests:

ESAPI for PHP build 1

This means that folks can start cutting code as the test framework and the main framework are fully stubbed out and ready to go.

Training coming along nicely

For those of you sitting on the fence about coming to OWASP AU 2009, it’s time to book. :-)

The training materials I’ve developed using OWASP ASVS covers all the ground in the ASVS in one day, from a developer perspective:

  • About the Application Security Verification Standard
  • What you need to verify code
  • About Risk 
  • The ASVS Levels
  • Verifying Architecture
  • Verifying Authentication
  • Verifying Session Management
  • Verifying Access Control
  • Verifying Input validation
  • Verifying Output encoding / canonicalization
  • Verifying Cryptography
  • Verifying Error Handling / Logging
  • Verifying Data Protection
  • Verifying Communications Security
  • Verifying HTTP Security
  • Verifying Configuration
  • Verifying Malicious Code
  • Verifying Internal security controls
  • How to write a decent report and how to communicate (good and) bad news 

It’s going to be a long day, so bring your game to the sunny Gold Coast, Australia. OWASP AU is a true bargain compared to commercial offerings.

If you have some training budget, book a ticket and come see me and have a blast!

Book my course now

All about OWASP AU 2009

How today’s Twitter Attack Might Never Have Been

I feel sorry for Twitter – they have the poster child of low value apps (which usually means no security controls or review), and then all of a sudden, they get done over using such a simple attack that it’s generous to call the attack a “hack”. Of course, because of the targets – Barak Obama, Stephen Fry (the world’s best comedian bar none), who are HIGH value targets, Twitter is feeling the pain of applied media heat today.  

Twitter on Monday said the hacker had broken into 33 accounts by gaining access to tools used by its support team.

“These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can’t remember or get stuck,” wrote Twitter co-founder Biz Stone in a blog post. “We considered this a very serious breach of security and immediately took the support tools offline. We’ll put them back only when they’re safe and secure.”
- from ZDNet

If Twitter had simply built their software (in 2006) to follow the 2005 OWASP Guide 2.0, they would have been safe today in 2009. 

Security Principles

I cribbed and re-phrased these from the 2002 Guide 1.0, which were in turn cribbed from the seminal Saltzer and Schroeder’s 1975 paper. This stuff is not new.

This is all about application architecture. If Twitter had designed their admin app to be non-reachable from the Net, the attack would have failed. If they had made users unable to perform admin tasks, they would have been safe. If they had defense in depth, they would at the very least known about the attack. If they had separated admin tasks from user tasks properly, they would have been safe. If they had not hidden the URL or parameters to the admin interface, they would have been safe as it would have been unreachable.

These are all design time considerations, one that is ultra important … even when you design a low value application.

Access Control

  • Principle of least privilege
  • Centralized authorization routines
  • Authorization matrix
  • Controlling access to protected resources – All functions must be access controlled

If ANY of these had been followed, they would have been safe. 

Administrative Interface

  • Best practices – describes the Twitter issue completely. It would be the new example if I was writing this today.
  • Users are not admins, admins are not users.
  • Divide the admin interface off into its own app, unreachable from the Internet.

If ANY of these had been followed, they would have been safe. 

In general, we know and have documented the solutions to these ultra common issues. Here’s my rule of thumb – if you design insecurely, you WILL be broken into. Security Architecture is a MUST. 

2009 – The Year of WebAppSec Solutions

“He who controls the present, controls the past. He who controls the past, controls the future” – Orwell, 1984

Looking back at the last few years, we’ve made some huge leaps at swatting at issues that bit us in back in the past, but still have not made a huge fundamental leap to controlling the future, and in particular controlling the risk from VALUE attacks, such as phishing, crime ware, and process issues (aka business logic issues).

I’ve been interested in process issues for a long time as its the easiest way to get VALUE out of a system. One the earliest web app sec attacks was against CDNOW back in the mid 90′s. They preceded and were bigger than Amazon for a long time. Ultimately, Amazon acquired CDNOW. Why? Apparently, they had a cool front end shopping cart, a payment system and a shipping system. Sure enough, the shipping system took a bunch of hidden fields and accepted a “paid=yes” type of flag. So essentially, you could fill in the hidden fields with the CDs you wanted and skip ahead to the ship bit, and get free stuff. End of story, they’re part of Amazon today instead of the other way around. The opportunity cost of being insecure for CDNOW can be measured in billions and will continue to rise as the years go on. That one attack wasn’t the end of the business, but it set them along the path.

So why in 2009 we do we allow 1995 era attacks to succeed? Why is this stuff not taught at University? Why are the business folks who make really bad decisions allowed to continue on doing the same old, same old, when they should know – do know – that it’s going to cost them a lot more in the long run?

So let’s look at the lows and highs of 2008:

Highlights of 2008:

  • PCI compliance starts to hit merchants. They still suck, but they’re unlike before, they’re now going to have to fix their stuff or go out of business
  • PCI 1.2 updated to OWASP Top 10 2007. Awesome. 
  • OWASP has a huge security summit in Portugal, deciding on future directions, and an awesome set of security conferences around the world. I think we have hit critical mass
  • OWASP Application Security Verification Standard Released

Low lights of 2008:

  • Phishing and malware links as tracked by APWG rose to its highest level ever. 
  • Massive compromise of credit cards continues – vendors continue to flout PCI regulations and common sense.
  • SQL injection attacks launch a million malware infestations

This basically means that attackers have been noted by the mainstream media and others as attacking VALUE through web apps, and not assets, like pwnage. They don’t care about the mechanism so much as the money. This has been my view for at least five years. I don’t care about if you control a 100,000 bot fleet – your just desserts are coming soon in your very own dawn raid. I do care if you can steal from 95,000,000 folks or defraud thousands with one e-mail.

“How’s that working out for you?” – Dr Phil McGraw

When we do something that is clearly not working, it is beyond time to do something different.

Back in 2002, I was doing security architecture in web apps for some of my more forward thinking clients. I have a draft book in my OWASP folder on Web App Security Architecture I started in 2003. When I moved to the USA in 2006, security architecture was completely off the average US enterprise architect’s radar. Only today are seeing some traction in this space, and not everywhere. 

Success stories elsewhere

With air safety, various safety bureaus review crashes and make binding resolutions on pilots, manufacturers and airlines to remediate design issues and human factors. For example, in many cultures, a strong hierarchal society is the norm. More than a few co-pilots have sat meekly by, refusing to override their captain as they plowed straight into the ground. So the airlines were forced to change the human element in the cockpit, forcing sub-ordinates to take control when the situation warranted it.

Air safety is a poster child for what can and should be done. From the early days when cowboys ruled the roost and many died, to today when only rail is safer per million passenger miles, air travel is one of the safest transport forms, despite being so inherently dangerous from a physics point of view (speed, height, traffic density, weather conditions, etc). We need to emulate air safety. Web application security is at the point where enforceable regulations are in their early days, like seat belts in cars were 50 years ago. 

We can and must skip 50 years. I’m not a huge fan of heavy handed regulation as I feel it will stifle the next big thing if done wrong, but I think many languages and frameworks are settling around a few major paradigms. We can help them, and they must help their users. 

We KNOW how to secure those meta-issues. We MUST secure those meta-issues. So here’s my 2009 Wish List:

Education

We have to educate those who come after us. This means getting into every CS and Software Engineering course world wide, and ensuring they have at least one mandatory security architecture / software security subject.

All applications share exactly one feature: security. I don’t think you can be a sound practitioner unless you have at least heard about this most fundamental of issues. It’s like graduating accountants who have not completed Audit 101. It’s completely ridiculous that there’s no equivalent in most CS and software engineering degrees today. 

I am also only going to speak at developer and architecture conferences. Speaking at security conferences is awesome and I usually get married or drunk or both, but it really doesn’t advance the state of the art. Architects and developers must get on board, and to do so requires their buy in. 

Eliminate XSS and SQL injection

We really need to get some basic technical things off the radar, so in 2010 and beyond we can deal with VALUE attacks. To that end, 2009 should be spent encouraging open source and vendors to fix XSS and SQL injection. We know how to fix these things. OWASP’s ESAPI has the canonicalization, input validation, and output encoding features that every application can use. Every modern framework has prepared statements or a safe(r) mechanism than dynamic statements.

I encourage the OWASP leadership and those in leadership positions to take a stand on these two items. I call on all framework providers to make the simplest possible output mechanism XSS safe. I call on framework providers to deprecate and eliminate dynamic SQL queries, or at least make serious warnings pop up so that folks know that they should not be using those interfaces. I call on open software reporsitories to stop downloads of packages that have open CVE entries. It’s important to bubble up the importance of safe software, and we can’t do this by wishful thinking.  

We can do this. It’s not a pipe dream. 

Security Architecture Is a First Class Citizen

It’s important to start putting security architecture in its place – which is every bit as important as the shiny buttons folks click or the processes businesses use to get stuff done. We cannot hope to eliminate design issues that allow VALUE attacks unless security architecture fu is strong within every organization writing software today. 

Although history is written by the victors, we’re a long way from victory. Let’s get cracking!

A review of 2008

Last year, I made the following observations / resolutions. Let’s check out how well I did:

  • Be a good dad to Mackenzie my gorgeous daughter, and a wonderful (hopefully less chubby) hubby to Tanya, my beautiful wife. 

I think I succeeded at this one

  • Lose some weight and mean it this time. What New Year’s Resolution is complete without this one?

Although I am lighter (149 kg down from probably ~ 155 to 160 kg), I’m not significantly lighter. I could have been close to 100 kg if I had stuck to an appropriate diabetic friendly diet and exercised more. I blame baby girl. JOKING. I’m a member of the cult again, and I have diary entries for walks and gym, so hopefully this time next year, may be I could be closer to 100 kg than I am today. 

  • Finish at least one piece of first class research in the web app sec field

Nope. Not even close. Started a few though. And that’s the subject of my next post – what to look forward to in 2009.