mostly useless crap from me

In September, MITRE talked about statistical proof that apps still suck on a mail list. In fact, web apps suck much more than any other form of vulnerability.

MITRE was surprised that their data set was so popular, and cleaned it up and released it.

http://cwe.mitre.org/documents/vuln-trends.html 

These will form the basis of the OWASP Top 10 2007, and as I’m also working on the SANS Top 20 2006 will contain some or all of this detail, with some luck.

Well, I’ve just had the (somewhat dubious) pleasure of reviewing my first Spring Web Flow app. Initially, I thought ARRRRGH Aspect Oriented Programming (AOP) dudes are on crack…

and then

I got the Kool-Aid. Here’s the low down for all you l33t code reviewers: it makes doing code reviews extremely hard … and extremely easy.

About a year and a bit ago, when I was (re-)writing the OWASP Guide, I realized that checklists don’t work. So how do you review code if you’re not looking for say Runtime.exec()? In my day job, technical issues such as cross-site scripting and SQL injections, although embarrasing, are hardly worthwhile compared to the sort of losses that can happen if business logic is wrong.

Sure the checklist approach, particularly OWASP Guide 2.x, produces huge reports, but does it mean anything? In short, no. The value is where the business is. That means understanding what the code does. And along the way, you can have a look at the dangerous stuff, like XSS and SQL injections.
So I started looking at flows more throughly. In normal J2EE programs, this can be a little tricky. In SOA, where apps are strung together dynamically, it seems like it’s impossible.

flows.xml

Start here and then find the sub-flows (often in flows/*.xml). If you know what you’re doing, you can produce a directed graph to understand the flows. This is key to understanding the important flows, and review them early and often.

Once you have decided upon a particular flow, follow it from what I will call the home flow, through to completion.

SWF uses continuations. This is different to many frameworks, but is closer to the way HTTP works in the real world. Tomorrow, we’ll look at what continuations are, and how to exploit them.

Work: I owe my boss a huge beer (and a document) and an apology when I get back to Australia.

Personal life: in the dog house. I got very little sleep these last few days, and I bet my other half is feeling far worse than me. Hopefully, she can come to Vegas so we can sort things out.

OSCON: Awesome.

My presentations went down well. I’ll upload the new presentations soon, but the Ajax Security demo went off really well. The room was overflowing with folks, so I’m really chuffed that so many of you decided to come.

I’ll put up the Ajax XSS demo I did later, but please be aware that these demos are INSECURE by design, and only to test them on your internal systems. The trick is to:

<img src="kitty.jpg" onLoad="... your javascript attack here ...">

People forget there’s literally hundreds and possibly millions of ways to do XSS. Do NOT look for script or Javascript and think you’re done. That’s stupid. Make the output safe, it’s faster, it’s simpler, and it works.

People

I met so many folks who I had spoken to over the net, or e-mailed. Everyone is so nice and friendly, it’s incredible to meet the greats. I really enjoyed catching up with Chris and Laura, met the Schlossnagles for the first time (cool dudes, cute kids , and of course, Wez.

Unfortunately, due to the bad things going on in my personal life, I could not bring myself to hang out after hours as I was feeling extremely down, but life goes on. I was hoping to go out to Portland a bit more; maybe next time.

Talks

I went to a fair few webappsec related talks, and it’s truly gratifying to me that the developers had an entire stream dedicated to it. I really enjoyed the PHP Security hoe down – we had a wack job in the back row causing a bit of a stir, but after he left, the hour really flew.

Portland

I’ve never been here before. It’s a very nice city, great public transport. I’ll post some images soon as it’s very pretty this time of the year. It was a bit hot when I got here (about 40C) but it soon cooled down to mid 20’s and I’ve been happy with that.

A friend through newbeetle.org picked me up from the airport last Sunday, and we went to her place and hung out for a while. She invited over a friend of hers, and I got to see her and her hubbie’s New Beetles (a nice Turbo S and a unired NBC), and her friend’s green Gecko TDI New Beetle. Very nice – I wish we could get that color in Australia. We had breakfast on Friday morning even though I was extremely tired (no sleep) and a bit sad, and she picked me up this morning to take me to the airport. I’m so impressed, I wish I could say I was as good a host when I have folks visiting. Thanks, Debbie – you set the standard!

Next steps

I’m off to SF next. I’m at the airport now. I have to spend a few hours this weekend getting stuff together to meet the CSO of a major partner of work’s, like running through the ESA presentations and ensuring that we have something constructive to talk about. I might need to go to Kinkos tomorrow and print off a few things unless my hotel has a printer I can use.

Colleen Frye from SearchAppSecurity.com, interviewed me via e-mail a couple of weeks ago on the OWASP Ajax security research and materials I’ve been pumping out. Although she asked for brief answers, to paraphrase Mark Twain, I didn’t have the time to write shorter answers.

The results are now available for your reading pleasure.

Part 1
Part 2

Just a quick note as to the quietness of the blog. I’m working on a few things:

• my slides for OSCON (webappsec 150 tutorial, and updating my Ajax presentation to include the latest research and make it a bit more (ahem) controversial to liven things up)
• doing demos for the above
• my slides for OWASP Melbourne, July 2006 meeting (this coming Wednesday! Details)
• reconstructing my work laptop
• the OWASP membership packs and other executive director project items
• administrating Aussieveedubbers
• writing a fresh Ajaxy UltimaBB installer
• writing a proposal for a workable security architecture for PHP 6 which I want to present to Chris when I go to OSCON, and maybe earn myself an audience with Rasmus and the other PHP luminaries to discuss it over a beer or two and thus decrease my trolliness to those folks.

and plus Tanya would like my body sometime as well. I’ve given up TV. Woe is me!

See you at OSCON 2006.

I’m also making an appearance at BlackHat and Defcon, and will be in SF in between those two conferences, and possibly in Salt Lake City before OSCON (depends on work). If you want a Thawte Notarization for the Web of Trust (free *real* fully trusted S/MIME certificates!), please bring photocopies of your photo ID and I’ll do it for free.

I’ve updated the Ajax presentation to the slide deck I gave at OWASP EU. New pictures. More content. More size! (4.3 MB)

Get it here:

Ajax Security (4.3 MB PDF)

Excellent day again.

I’m still waking up far too early, but that’s okay, particularly since I had still to complete my Day 2 keynote slides, much to Dave’s disgust.

- Leuven University

The keynote went well, but I finished what I thought was early, when in fact, it was dead on time. This left Ivan Ristic with much less time than he had intended.

Ivan’s talk was pretty cool – he went through the stuff you’d expect of the author of the open source web application firewall, mod_security, discussing the four major features of the software. I’ve used it before in a DDoS attack, and it worked well.

After the morning break, I went to the invited papers track. I think this was a good idea, and the quality of the ideas was good. I think it allowed people who are not conference whores like myself to get up and speak. And considering that only a small percentage of the attendees are native English speakers, I was pleasantly surprised at the quality of the English at the conference. Awesome.

The session riding talk was cool, but again, they’re using a non-mainstream technology to fix the problems. I think people really need to start using the major technologies which are weak rather than using esoteric languages which take their fancy. PHP needs a lot of help, for example.

After lunch, I went to Dinis’ tool heavy presentation on the stuff he’s made this last year. Awesome tools. Might see if they work under Mono on the Mac. Except for the report generator, which is basically a waste of time. As a customer I HATE (and I mean I will return your report and not pay you HATE) getting nessus or other tool output auto-gen’d from XML into PDF. I don’t pay the pound for my reports. I prefer short (10-20 page) reports which tell me what is wrong, carefully considered and rated. This is something that can be done in Word more easily than Dinis’ tool. I’m sure Dinis’ report writing tool (he’s a total XML freak works for his customer, but I’m not interested. If it gets out in the big bad world, I hope it doesn’t catch on. Our value is our skilled interpretation, not 1000 page automated reports.

After the last break, there was a panel discussion, which was far more lively than the previous day when everyone agreed with each other. It was hard as Gunnar let people speak who had more than their turn. There was one particular lady who just butted in all the time. I had my hand up for half an hour before I could a word in edge ways, thus not allowing me to state a couple of points about user security education which I vehemently disagreed with, but couldn’t as the flow had moved on. Oh well. I’ll butt in next year – being a good guy does not pay off if you want to be heard. Despite this, it was a good and lively session.

Dave finished the conference up. After we had finished, Pravir Chandra and I went out to dinner. I wished a few more could hang around, but many needed to get on flights home, and several wanted to go back to Brussels for food. We had a good meal in the center of the old city. Awesome food.

I think it was extremely valuable as a conference. If I can, I’ll be back next year.

Recently, I’ve been doing a fair amount of work in the SOA area. It’s funny how many folks want to expose ancient code directly to untrusted third parties.

All is not well in the SOA space, and it’s important to understand the risk of web service enabling calls to “trusted” systems. That code is generally not written to handle input from malevolent attackers – it was designed to be called from internal staff who you have a strong legal relationship with and all the motivation in the world to keep their jobs.

This slide pack was intended for the April Melbourne OWASP chapter meeting, and it’s a basic taster of the stuff I’m going to be including in the forthcoming OWASP Guide 3.0.

Securing SOA (927 kb, PDF)

Here’s the quick and dirty preview of the new Ajax chapter of the Guide 2.1. It’s also some of the first real guidance anywhere on Ajax security – period. It was interesting to find so many apps adopting Ajax, but so little information on how to secure it.

• Ajax Security Presentation (PDF, 1.8 MB)

If anyone wants to proof the new chapter, please join the OWASP Guide development.

There are only a few acknowledged industry security architectures. SABSA (best documented in Enterprise Security Architecture by Sherwood, Clark and Lynas) is probably the best known.

The various artifacts from this architecture include:

Each of these layers needs to be thought about in a considered way:

(Business) Drivers

Why do you want X / How will it be used / Who will use it / Where should it be located / When will it be used?

Answering these questions will help understand if something already exists (with PHP most likely), and understand the communities we need to talk to to understand their needs and desires.

Then a risk assessment can be carried out to determine the relative risks of each area, and understand likely vulnerabilities based upon existing exploits.

Occasionally, this process will pick up areas where there are missing areas of functionality in PHP. This then ends up on the roadmap for later versions.

Conceptual Layer

Training and awareness – DR / BCP – audit and review – authorization – administration – incidents – standards, etc

Often these areas are well covered. The trick is to bring them under the one roof and ensure we’re all driving in the same direction. Some of the issues in a standard security architecture simply don’t apply to a language, which is cool as it means less work.

Logical Layer

Policy – classification – security services management – interop standards (WS Security et al) – audit trail, etc

This is usually left to the programs written in PHP, but PHP needs to provide these services. The OWASP Guide provides a great deal of best practices, so the main activity here is to determine if the standard PHP frameworks contain adequate API in each area. For example, PHP is sadly lacking a secure audit class.

Physical layer

For PHP, this is mostly about configuration, but also the rawest possible implementation of the security trumvirate: confidentiality, integrity, availability. Again, PHP may need to grow to allow all of the areas here:

certificate mangament

Component layer

A major win for security architectures in the last few years is the move away from crunchy on the outside, soft on the inside “edge” hardening towards trust boundaries. Identifying data flows from trusted components to other less trusted components is key to understanding the security risk.

Therefore, this can be used to identify those API which normally perform this transition on behalf of programs, such as echo/printf/ IO in general, and so on. Each of these major trust boundaries needs to be investigated to ensure that there is a safe way to make the transition, whilst a raw / unsafe way remains for those few programs that need the raw / unsafe way.

Conclusion for now…

Well, that about wraps up this explanation. In the next installment, I’ll start enumerating the current risks and identifying business drivers. This is an important first step to creating a security architecture which will be robust.