afongen

I made it to Tuesday night’s Minneapolis/Saint Paul OWASP meeting for the first time this year. It’s good to be back. There was good information and conversation both during and after the meeting.

Tim must have drawn the short straw to be scheduled first, so he got to deal with the usual projector problems. But once things got rolling, he treated us to a demo of a few free or low-cost scanning tools. He has notes on his blog. From what we saw tonight, what really differentiates higher-priced commercial scanners/pen-testing tools like AppScan and WebInspect is the reporting. It’s obviously not that simple, but man it makes a difference. Reading a Still, I’m with Tim: the Burp suite is a nice toolset, I enjoy using it.

Bob Sullivan gave us a quick overview of what’s new in WegGoat 4.0, a teaching tool for web application security. One thing that I’m glad to see is moving the documentation to the OWASP wiki. There’s also an Eclipse developer environment using WTP, but I haven’t investigated to see exactly what that means.

Next Joe Teff gave a quick demo of Fortify’s source code analysis tool. He was quick to point out that he wasn’t selling the tool, but he had experience with it with his job at Wells Fargo and thought it was worth talking about this type of tool. I don’t know if there are open source tools in this space, but it is at least heartening to see more and more commercial tools building on the Eclipse platform. As I understand it, source code analysis tools take a couple approaches. Static analysis is essentially a glorified grep, searching for problematic patterns. In dynamic or runtime analysis, the binary is examined while it is running. Fortify seems to do the latter, and is connected to your static source code to trace problematic data paths through the app. This is simple for small or standalone apps (think jar, war, ear), but it sounds like you have to jump through hoops to make it work with a distributed app. Possible, yes, but SOA will push the limits of these tools, so I expect some movement on that front in the next couple years. Unless I completely misunderstand how they work, which is possible. Either way, interactions at the boundary between two applications/modules/services merit close scrutiny; relying on a tool alone is insufficient.

Gunnar Peterson gave a quick overview of the goings-on at AppSec Europe. Good stuff, I’ll have to check out the presentations and watch for video. I really need to attend an OWASP conference. One interesting takeaway is a discussion of whether the open source world is keeping pace with Microsoft on the development and dissemination of secure development practices. Johan Peeters has a summary and interestingirritatingly pedantic discussion in the comments. Note to self: take another look at CLASP.

This meeting came at a very good time, as I actively work on improving how we incorporate security into our development process. Much as I resist generating documentation that does not move us closer to working software (and do like docs that help us get work done), I am cautious about introducing tools that may chew up cycles without sufficient benefit. Penetration testing software has an obvious place in the SDLC, but it comes too late in the process to intervene with a train about to derail. I used to be suspicious of code analysis tools but have warmed to them. I believe that they can help developers learn more about secure coding practice. If they can tie into bug reporting and tracking, all the better. (I’m also becoming a fan of metrics.)

I want to stay clear of the notion that it’s all a developer problem, though, which I think a focus on development tools tends to encourage. “Oh, those darn developers, if only they’d just think!” Yes, developers need better security education. So do designers and architects. More on that another day.

I keep forgetting to mention this. The Twin Cities OWASP chapter is meeting Tuesday night this week at the Minneapolis campus of Metro State (right near MCTC). Directions and details are on the chapter page.

Tim McGuire will be talking about free and open source pen-testing tools, and Joe Teff will talk about Fortify, a commercial source code analysis tool. Looks to be a good meeting. Since I’ve been unable to attend the last two, I’m looking forward to it. Maybe I’ll see you there!

It looks like OWASP is running on new software, MediaWiki by all appearances. Hopefully that will work better than whatever they were using before. I know that getting the local chapter pages updated has been an ordeal.

I gave a talk about web application security testing last year and started to write up my notes, but somehow I never quite finished them. I’m unlikely to do so in this format but thought I’d at least post the notes as they stand. Things have changed in the past year: I have a better handle on threat modeling (and Microsoft has released a couple new iterations), we’ve seen great new tools like Firebug released, the Build Security In portal was released (although I still think it’s of more interest to developers than architects, which is an okay thing), there’s been more work published on abuse/misuse cases, a new OWASP Guide was unleashed…

So on the off chance they are of value, here they are: notes for Web Application Security Testing talk.

I am so pleased to be working with people who are clued in enough so I can have conversations like this:

Me: John, I’m glad that we’ve finally got Board policy addressing data security and privacy, and we’re putting in place practices and training to address network security, wireless security, and so on, but—

Him: But Gary McGraw is right.

Me: Yes, exactly.

Here’s the thing. We have paid far too much attention to network security and not nearly enough to application security. That’s what Gary McGraw has been saying, and thankfully our security guy knows it. Software security is the new frontier. Or really, it’s been the frontier all along, we just haven’t acknowledged it.

So what do I do? I’m going to have a very busy summer, jump-starting our secure development process and trying to get policy to match what our process should be, so practice can flow from policy. This is nothing official to my job, it’s just something that I care a lot about and am going to do. It’s a start.

Shreeraj Shah has just published Assessing Web App Security with Mozilla over on ONLamp.com. It’s really more about introducing LiveHTTPHeaders than the guts of a security assessment, but it does point the way. Not unlike the talk I gave at this spring’s MnSCU IT conference (handouts). I like LiveHTTPHeaders for just this purpose, I use it all the time. (In fact, I used it just yesterday when reviewing PHPSurveyor, an app that has its share of problems.) More and more, though, I find that I’m using Fiddler, at least when I’m on a Windows box and don’t have to deal with HTTPS. Fiddler offers a lot of detail that I find useful.

Still, I do fire up LiveHTTPHeaders when I just need a quick overview of what’s happening and want to manipulate requests. I also use it to introduce developers to HTTP. Too often I find that developers don’t have a solid understanding of HTTP basics, which has a direct impact on their ability to write secure web applications.

LiveHTTPHeaders is a fine tool, and Shreeraj Shah’s article is a good introduction. If you’ve never used it, a few minutes reading that will get you started and point you in the right direction. And maybe give you a little insight into the sorts of things an attacker can do quite easily.

At Tuesday’s OWASP Twin Cities meeting, I learned that DHS is about to launch a new software security portal, BuildSecurityIn. An article in a recent IEEE Security & Privacy magazine describes the portal. I don’t subscribe so will be hitting the library this weekend to find what I can before this thing goes live.

Tuesday night I went to the first meeting of the Twin Cities chapter of the Open Web Application Security Project (OWASP). We’ll be meeting the second Tuesday of every month. It’s too early to tell how successful the group will be, but the people there seem dedicated, so I am hopeful.

In attendance was Gunnar Peterson, whose articles on a collaborative secure development process (PDF: parts one, two, three) introduced me to misuse cases and, eventually, threat modeling. Interestingly, of the 10-12 people there, I was the only developer. Everyone else was a security analyst, architect, or consultant. This defied my expectations but not theirs. The developer blogs I read deal with security and build an impression that developers are more concerned with security than is generally the case. Of course, I seek out those blogs in part because they have interesting things to say about security, so that misleading impression is only natural. The developers I work with give consideration to security, but probably not as much as I’d like to think and certainly not enough to drag them out to the Golden Valley library on a Tuesday night. I think, then, that I need to evangelize the new OWASP chapter to the developer communities in which I participate. This will likely mean having meetings on topics of interest to them.

Gunnar brought up a good point, that so often security teams (which have historically been network-focused) point at developers for security problems, but we musn’t forget the architects, who obviously need to consider security as part of the software architecture. This underscores a point that many of us have been saying for years: security needs to be incorporated throughout the development cycle of an app. That’s what Microsoft’s Security Development Lifecycle is all about, and from everything I’ve heard they’re really taking it to heart.

I’d like to find ways to get involvement in OWASP from all sorts of different groups involved in software development, not only to emphasize the importance of security in those areas, but to learn about these other fields and make connections outside my immediate arena. Software development fascinates me, and not just programming. That’s why I distinguish between “developer” and “programmer”: to focus exclusively in one area is a death knell for my passion, my career, and perhaps my sanity. This is part of why I’ve started to be more active in local industry groups like the OWASP chapter. I’m a security-focused web application developer with a penchant for open source and open processes, so it’s no surprise that OWASP appeals to me.

I volunteered to give a presentation about the OWASP Top Ten at our next meeting. It’s a good introduction to the issues in web application security, of interest to developers, architects, analysts, testers… anyone involved in web application development and deployment. I’ve given this talk a couple times before, but this time I have some new ideas for presenting the material. So come on out! Tell your friends! We’ll be at the Golden Valley Library a to-be-determined location on Tuesday, October 11, 6 – 8 p.m. Hope you can make it.

Update: I’ve been told that the library was already booked, so a new location for October’s meeting is being sought. Check the OWASP Twin Cities page for updates.

Update, 8 October. Tuesday’s meeting is at the Plymouth Public Library, 6 – 8 p.m.

A Twin Cities chapter of the Open Web Application Security Project is starting up. Our first meeting is September 13 at the Golden Valley Library.

On Saturday I gave a talk about form processing and input validation to the Twin Cities PHP User Group. It went well. I had originally planned to talk for 20 minutes or so, but other speakers backed out so I had lots of extra time. I made a spur of the moment change, pulling in slides from previous presentations, covering SQL injection, cross-site scripting, and cross-site request forgeries. If you’re operating in a strictly whitelist mode, it’s possible to do input validation without understanding the threats, but it’s extremely limiting and generally unwise. You have to know your threats to write secure software. Thereis obviously far more to consider than SQL injection, XSS, and CSRF, but time was limited and that’s what I had slides for. :)

After that quick overview, I covered basic strategies and pitfalls awaiting the programmer fortunate enough to be considering input validation. I even gave props to the Apache Commons Validator, a Very Useful Java validation library that we use in Struts (and that in fact started life in Struts). I’m not aware of anything parallel in PHP, although some libraries and frameworks offer similar functionality. I am intrigued by Solar_Valid and Solar_Filter in Solar, a library/framework for PHP 5. Paul M. Jones has been busy. Matthew Weier O’Phinney provides the background on Solar_Filter. (Quick aside: Marcus Whitney recently interviewed Mr. Jones for the Pro-PHP Podcast.)

I’m not sure how, but after the talk they convinced me to make my slides (PDF) available online. I’m normally opposed to this, and indeed the slides aren’t that useful in isolation, but detailed meeting notes are forthcoming so I am somewhat mollified.