cat slave diary

The document is a complete re-write from scratch, and is totally up to date. It’s 34 pages of goodness wrapped in a shiny new document format. Essentially it’s over all bar the shouting… which comes next!

The document will be uploaded to our Wiki in the next week (post-board approval). If you want your review points or changes to be included, you will need to be on the Top 10 mail list to make the suggestions or changes. To join the OWASP Top 10 mail list (it’s free!), go here:

OWASP Top 10 Mail man interface

I am particularly interested in hearing from people in the

• PCI DSS arena
• Department of Homeland Security
• NIST
• - Your nation’s equivalent of the above two if you are outside of the USA
• If your organization has previously adopted the OWASP Top 10 2004
• Vendors in the WAF, automated code review, and other automated tool arena (yes, we finally discuss if these automated controls are likely to work, but as we don’t know about every product, the more advice we can get the better)
• Frameworks, particularly the PHP team, J2EE / Struts / JSF / Hibernate / Sun / BEA, JBoss, etc, and of course Microsoft’s folks in the .NET team

The last two bullet points are REALLY important as we make some stringent suggestions about how best to code to avoid the Top 10 weaknesses and we want to ensure that it really is the best advice. If you can’t be seen contributing publicly, feel free to e-mail me… vanderaj (at) owasp.org.

UPDATE >> Here it is!

http://www.owasp.org/index.php/Top_10_2007

Andrew

I’ve been busy on the Top 10 2007 with Dave Wichers and Jeff Williams. I’m very close to finalizing a draft release right now. This process made me think, how can we eliminate these issues? Why should every developer have to learn how to fix the same problem? We know On some frameworks, some classes of application programming error are history. Obviously, we’re not going to be able to fix business process or logic issues, but I’d prefer people working on that than wasting time searching mountains of code looking for every last vulnerability.

So over the next week or so, whilst I’m traveling and theoretically have more time (i.e. less TiVo!), I’ll pump out what’s wrong with the current model, and propose how it might be fixed. Permanently.

Some of my recommendations will be hard to swallow, but the alternative (”same old, same old”) has failed, and failed miserably for years. It’s time for something new, or in the case where it works real well on another framework, let’s adopt their ideas and maybe even improve on it a bit. Up first is our old friend XSS.

XSS

The table shows just how wrong the old way (PHP) is. I made the number up in the difficulty column, arbitrarily setting it to 10 / 10 for the weakest solution, and then thinking carefully about what would be required in the other platforms to come to the same desired point: a safe application. In this round, J2EE using any of of the common presentation layers wins hands down. Sure, you can do bad things in J2EE and .NET, but the important thing is that it is not the default. You have to work at being insecure. But when you need to be, those frameworks allow you to be as insecure as the next guy.

Given the likelihood that a PHP developer is no better or worse than a J2EE or .NET developer, the PHP application requires more care and thought to get right. This means, in the entire universe of webapps (regardless of language), a larger percentage of PHP applications will have XSS issues than other frameworks.

What’s needed to get it right?

With PHP, there’s no real solution other than … a very ballsy decision to make PHP 6 XSS safe by default. PHP 6 is Unicode. Let’s make the Unicode output functions XSS safe by default, and output a E_STRICT warning when apps use print or echo. Obviously, there will need to be a way to output HTML dynamically, but this is the corner case, not the default. Let’s make the devs who need REAL html do the hard work, rather than make all devs do the hardwork, everywhere.

With .NET, all controls need to be XSS safe by default and have an encoding property, and it should be set to true by default. Enough are properly done right now to protect the usual newbie programmer, but it’s wrong to assume that even advanced devs will remember to encode everything. Where a value is stuck into a field that is likely to be displayed without encoding, a warning should show in the debugger.

With J2EE, the java compilation step should issue a warning when the old style <%= … %> is used un-nested. <%= … %> is required to put values into messages and bean:write to do useful work. But if it’s just on its lonesome, that’s XSS right there.

Tomorrow: Injections…

A few weeks ago, the announcement of the PDF hole made it clear that the age of stupid XSS vulnerabilities is still with us. Is it time for me to surf in a read only sandbox? XSS is so old school, and yet so damaging. It is so SIMPLE to prevent, but so HARD to stamp out. I was disheartened.

But then today rolled around.

We had a board meeting tonight and I’m excited with what we have planned, and it’s re-invigorated me tremendously. It’s a very exciting time to be in the midst of the OWASP community right now.

I hereby declare 2007 the year of pro-active webappsec research. Not looking for or researching new vulnerabilities, but researching and developing long term effective methods to close down common holes which plague browsers and common frameworks. It’s time to kick XSS, CSRF, injections of all types in the slats and make it impossible for folks to say “well, I didn’t know” or “that’s too hard / costly / time consuming”.

We have a range of projects we’re doing this year, and I will make it my task to ensure that OWASP builds the knowledge, tools, patches, and so on to eliminate wide swathes of wepappsec retrobugs. Let’s see how I go in 345 days or so.

It was nice to see Marcus Ranum (who has an interesting slant to the security industry) get some press again. This time it’s on responsible / full / no disclosure. In a probably unrelated attack, his site is defaced by a SEO blackhat. Irony, eh? If only he had patched or used software which has learnt the hard lessons.

Here’s the anti-rant I wrote my co-workers a Friday or two ago:

Ranum’s argument has four major elephant sized flaws (at least).

Firstly, he states that security has not gotten better. This is clearly wrong. Security has gotten a great deal better, but so have the attacks and our knowledge. However, the impact of attacks has been steadily decreasing. When I first joined the Internet, there were perhaps 100,000 people on it at a very small number of sites. That year, the Morris worm nearly destroyed the entire Internet. There have been no significant attacks like that for some time. Yes, there are more attacks, but considering there are more than a billion of us on it now, that’s to be expected. Attacks require a great deal more skill today than in Morris’ time. Old software, particularly in the webappsec is trivial to exploit. Proof – modern stuff which is hardened through the lessons we’ve learnt is very hard to exploit. Software which does not heed the lessons is trivial to exploit (see MJR’s site, natch!). Without some pressure, all software would be trivial to exploit, not just the lesser used stuff.

Secondly, he states that disclosing vulnerabilities is akin to shouting fire when there is barely any smoke. The implication is that you should never shout fire, even if there is the possibility of fire. However, if no one shouted fire, children’s pajamas would still be made of highly flammable materials resulting in third degree burns or death instead of slow or insulating materials we have today. Only through research, standards and indeed, advocates (akin to vulnerability researchers) doing shock stories on tabloid TV did we move from obviously deadly dangerous to moderately safe. Fire is a particularly weak analogy as the metaphor breaks down very quickly – fire always occurs and is a natural phenomena.

Thirdly, Ranum ignores evidence that contradicts his position. Vendors and customers are hurt by rampant full disclosure, and I agree that some folks are only out to get on CNN for a few cycles. However, responsible disclosure is the only proven way to make security sloppy companies like Oracle pay attention - eventually. It made Microsoft more secure, and I think if you look at NT 4.0 (1996) versus Vista (2006), Vista is a much larger but harder target. Oracle’s CSO (is in my view) negligent because she thinks like Ranum, and refused to protect her customers and ipso facto all of us.

Lastly, Ranum HATES - and I mean truly despises - upgrading software. This leads directly to his point of view that if there was no disclosure, there would be no (or much less) patching, therefore he wouldn’t have to upgrade. This is a logical fallacy as one does not lead to the other. If all of us had his world view, we’d be running NCSA web server with no firewall on SunOS 4.1, i.e. completely unsafe. How would have Microsoft|Apple|Sun learnt how to secure (as best they are able) their operating systems without the challenges of security researchers and malware creators? It’s like MSRA golden staph - damn near unkillable around hospitals today. It didn’t get like that because we used soapy water.

He rants against the creation and sale of malware as if we’re powerless to stop it. However, it is already illegal to do this in many countries. So if someone writes malware, they are already breaking the law. Why would they stop now, or in the past in his alternate no disclosure universe.
I remember a few years ago that CERT sat on a major DNS issue for oh 8 years (I’m making this number up, but it was not a few months) until the last root server was upgraded to bind 8.something. There was an architectural flaw that could have destroyed the internet with a few packets. And I knew about this in like 1992 or 1993 and at that stage I was not in the security game fully – just a sysadmin. It only required someone with bad intentions and the Internet would have been dead. Why X years? Because there was no impetus to upgrade the root servers, despite it being 14 times redundant, simply because CERT sat on the problem. When I met Spaf a few years later at a SAGE-AU conference, I asked him about this, and he was unapologetic about it. Who gives him the right to decide if the Internet stays alive or not? It should have been fixed, and indeed it was fixed – eventually.

Will we ever be secure? No. Will Ranum’s or my site be safe from attack? Doubtful. Ranum is simply wrong in his thinking if by stopping disclosure we will suddenly become safe.

Ranum’s alternative is no alternative.

ps. I am no apologist for unrepentant full disclosure types out for their 15 minutes on CNN. Hint: I will never employ or recommend ANY full disclosure folks.

This edition’s headings:

A1. Cross-site scripting
A2. Injections
A3. Insecure Remote File Include
A4. Insecure direct object reference
A5. Cross-site request forgeries
A6. Information leakage and improper error handling
A7. Malformed input
A8. Broken authorization
A9. Insecure cryptography and communication
A10. Privilege escalation

Note what’s missing? Note what’s new?

If you want to review it, please mail me. We are putting it out to at least a month’s peer review, including previous users such as PCI and SANS, as well as folks who had no particular love for the old 2004 edition.

Unlike 2004’s edition, updating the Top 10 will become a yearly event. With some luck, we will be releasing it each and every January.

JUNE!!!! Why June!

Looks as if I’ll be an AT&T customer come June. Buy AT&T stock now!

As most of my friends know, I’m a bit of a car nut. It always gives me pleasure to buy a new car, which is why I keep them about three years on average. However, this time it was less than pleasurable on two fronts: I had a terrible cold and Tanya had a broken nose (more on that in another post), and the strange way pricing and haggling works in the USA.

Dealers have so long dealt with consumers who are terrified of not getting a unbelievable deal that they create fake “invoice” prices, along with the MSRP (RRP to Australians). Generally, you can find out what the invoice price is from web sites. The invoice price is hidden in Australia, but typically, it’s 15-20% less than tax ex RRP. In Australia, you try to get options and the dealer prep charge thrown in for free, and generally I think a good deal is done when this occurs. The dealer makes a reasonable profit, you get a good price, and relations with the dealer remain cordial.

However, here in the USA folks will start a few hundred or more under “invoice”. However, dealers have holdbacks and volume bonuses beyond the invoice price, which mean that the invoice price is no longer the invoice price, plus they are sticklers on keeping the destination charge, despite freight being part of the invoice price.

So if you get a car for invoice, the dealer makes about a $500 - $1k profit or so, and you think you’ve done a good deal. However, on some popular cars, dealers will hold out for MSRP and they make a few thousand per car. This is what happened to us. We originally started out looking at the Honda Fit (Jazz in Australia), Toyota Prius, and VW Rabbit (Golf everywhere else in the world). I wanted a Prius, Tanya wanted the Jazz.

The Jazz is backordered to March. No good for us - the USA is not a place to be without a car. But we found ourselves looking at the new CR-V. Again, as most of friends know, I hate SUVs. But for some reason this one is different. It drove really well, it’s not that huge, and it’s car like (it’s monocoque construction and modern suspension and Honda’s version of all wheel drive (it favors the front wheels unless they slip, in which case drive heads to any remaining wheels with grip)) made it a nice ride. But the dealers knew they had limited stock and lots of waiting buyers, and even though they wanted to shift units (they have to pay tax on any units left on their lot on January 1st), they universally stuck to MSRP. So we walked away, which is a shame as it’s a very nice car.

Strangely enough I now have a bunch of Honda dealers giving me very close to invoice pricing on the CR-V. So I will remember this in the future - go a week beforehand and walk away when they give you crappy pricing.

After Honda, we test drove the Prius. I loved it. I wish we could have bought it. But Tanya HATED it with a passion. Oh well. Maybe I can buy one as a second car in a couple of year’s time.

Some folks on newbeetle.org recommended a nearby VW dealer and the sales dude there. We went to Antwerpen VW, and test drove the VW. I was worried about the test drive as Tanya seems to be very picky with her cars, which is strange as she’s very much a car appliance (A to B) buyer. VW has a reputation (which I can back up personally) for making unreliable shit heaps, so that was weighing on my mind as we test drove a Rabbit. Luckily, Tanya liked it, I liked it, and they had a few on hand so I knew I’d be getting a good deal.

The haggling was straightforward - he offered us invoice straight up. So the haggling being over, we started on finance. That was awful. After three visits and nearly a week later, we finally can announce our new car: a black VW Rabbit 2.5 auto, with ESP, extra airbags, upgraded stereo and sunroof.

It drives lovely, is nice and quiet, has a delicious throbby 5 cylinder note, and has all the mod cons you’d expect. The only downside is that our car payments are horrendous, but after 12 months, the car is ours to own. Luckily, my new job has a salary to match, so although we will have to be careful, we’ll be okay. This means when we likely to have a new kid (assuming we succeed!) we will not have any car payments, which will be lovely.

All the cool kids get the press for the wrong reasons. It’s much easier to destroy than to create. Therefore, my 2006 and 2007 lists will only highlight those things which I think have helped create safer web apps, not made it harder for us to protect against them.

2006 Highlights

• IE 7.0 released. Seriously. Prevents many phishing attacks, reduces the damage through low privilege browsing, and stops some forms of XSS (including the recent Adobe PDF problem). Firefox and Apple could learn a few things from Microsoft.
• Publication of Ajax Security guidelines by many folks (including me)
• PCI updated their guidelines to encourage vendors to take CC handling seriously, mandating code reviews by 2008
• Folks who are normally hidden started blogging, such as this PCI DSS blog and this
• OWASP Testing Guide gets off the ground in a big way. When this is released (soon!), normal folks will have a way to review existing code properly.
• OWASP Autumn of Code starts, funding approximately nine projects (8 were chosen and we funded another as it is strategic to OWASP’s mission). Many projects are nearly finished! This has been extremely successful and we will be doing it again in 2007
• Encoding gets a fresh look: OWASP Encoding library and Microsoft’s revamped AntiXSS library which takes the refreshing approach of deny all crap and let through known good.

2007 Projections

It’s going to be a very busy year for vendors in this space, such as my new employer, Aspect Security. With PCI compliance coming through the works, folks writing PHP apps finally grokking that they need code reviews and pen tests, it’s going to be a bumper year.

Things that I think will make a difference or need more research:

• Protections against malicious XSS. This will almost certainly focus attention on Javascript implementations
• Better browser protections for users. All browsers need to look at IE 7.0 and think of that as a starting point. You hearing me Firefox and Safari / webkit devs?
• Research into safe I18N methods and prevention. This is an almost completely green field today, and needs serious researchers
• Working on safer API for free form protocols such as XML and LDAP which are essentially utterly injectable today
• Work with the PHP group to get them to make PHP 6 safe by default. They have an excellent opportunity and a huge responsibility to not screw up
• Open source web app sec training for open source languages such as PHP and Ruby is direly needed. Lots of information out there, but how to publish to this audience? Extremely challenging
• Projects utilizing the latest fads (Spring, Ruby, Ajax, etc) MUST catch up with the latest in webappsec trends or they WILL fail. It is not enough to adopt the latest and greatest fad and think it’s secure. It’s not.
• Folks like Gunnar Petersen are getting the secure SOA message out there. This baby’s time was several years ago, but I think in 2007 large organizations will finally start realizing that hooking up web services to 30+ year old Cobol is an insane proposition without a dose of security
• REST will be put to rest, as it is insecure and cannot made to be so… without looking an awful lot like WS-*. At which point you may as well use WS-* and be done with it. SSL != secure.
• A lot greater focus will have to be paid to business logic security. Code scanners and app scanners CANNOT find this stuff, and yet it is the raison d’etre for the web apps. Securing business logic requires hard graft, and a great deal of focus in the architecture and business requirements phase. Hopefully, OWASP will be working on secure architecture, business requirements and design resources this year.

However, it’s going to be a annus horribulous for folks who cannot or will not undergo PCI compliance. PCI compliance is mandatory in 2008, and doing brain dead stuff like storing credit card details will mean many smaller CC gateways and providers will have to shut down, leaving only the big providers. This will mean higher processing fees and less competition. However, the reality is that the financial and identity theft losses from non-compliant places outweigh the benefits from letting them live. I’m happy to pay a little extra and know that my details are reasonably safe from unsavory types.

We’ve moved to the USA and we’re nearly settled in now. Only 13 boxes to unpack… which is funny as we shipped 13 boxes.

Unfortunately, we’ve had a bit of a illness closeout to 2006, and if anything, we’d like to say “sayonara” to 2006 with a vengeance.

Just after arriving, Tanya ended up with reactive arthritis. After nearly a month of painful days, drugs which make her ill, and with a lot of tender loving care, she was finally getting better. We had almost a day where she could walk without crutches and do stuff without being nauseous or tired.

However, we bumped into each other whilst pottering around in the bedroom, and in the jostle her nose broke again. To top it off, I got a bad cold the following day just as we needed to buy a car (I’ll blog about this later). Now I’ve given the cold to her. I can’t imagine how painful blowing a broken nose is.

We’ve had some really good times here since moving - we were invited to several Christmas parties, offers which we took up. Tanya came to two of them, but unfortunately, had to give Diann’s Christmas party a miss due to her illness, and we had to leave early at the Wichers. Despite the health issues, we’re settling in nicely.