Even though there have already been some great posts (Rafal Los, Gunter Ollmann, RSnake, John Steven…and again John Steven) I felt like I wanted to offer my commentary and hopefully convince some of you to attend the next OWASP event close to you. Quick disclaimer: I helped Doug, Rex, Mark, Kate and the rest of the volunteers at the conference, so I might be a little bias.
First – if you’re going to host a conference in DC, there’s really no better venue than the DC Convention Center. This is really a top notch venue in the center of DC that is built for conferences. It’s metro accessible and the conference services (food, beverages, A/V, wireless, etc) are top notch. I’m not saying the venue makes or breaks the con, but it helps.
The speakers, technical content of the presentations, and variety of topics exceeded that of much more expensive conferences I’ve attended. Joe Jarzombek kicked things off with the keynote, David Byrne and Charles Henderson can’t filter the stupid, Jon Rose and Tom Leavey brought the drinking game with a chance of 0-day, Jeff Williams tackled the insider threat, Kevin Johnson and Tom Eston think our friends want to eat our brains, Josh Abraham brought synergy to our pen-testing tools, RSnake gave security experts happy hour chatter for the next year with the 10 least-likely and most dangerous people on the web, John Steven condensed 6 hrs of Threat Modeling training into a 45 minute talk (good thing we had him scheduled at the end of the day), and Chris Weber dazzled with unicode. Not to be outdone, the OWASP projects were equally represented with Pravir Chandra on OpenSAMM, Jeff Williams on ESAPI followed by Arshan Dabirsiaghi on the ESAPI WAF, Sebastien Deleersnyder and Fabio Cerullo brought the OWASP tools together to deploy web applications, Matt Tesauro did his thing with the Live CD, Dr. Boaz Gelbord touched on security spending, and of course, who could forget Dave Wichers at the OWASP Top 10 2010 RC1! The conference also features 2 panels, the Federal CISO panel with Ray Letteer (USMC), Timothy Ruland (US Census), Richard Smith (TSA), and lead by Matt Fisher. The SDLC Panel features Michael Craigue (Dell), Dan Cornell (Denim), Dennis Hurst (HP), Joey Peloquin (FishNet), David Rook (Realex), Keith Turpin (Boeing), and lead by Pravir Chandra. The conference also featured a CTF running the new OWASP CTF project and hosted by Martin Knobloch.
For those of us who have been in the security industry for a few years, these conferences are a great chance to catch up with old friends and make new acquaintances. It was great to see familiar faces like Tom Brennan, @grecs, Ken Van Wyk, Matt Fisher, Dinis Cruz, Jon Rose, John Steven, Lee Anne Hart, Gracie Daniel, Jon McCarty, Jeremy Long, Rob Fuller, Jack Mannino, Rex Booth, Mark Bristow, Doug Wilson and others. At the same time, it was great to make new contacts like Josh Feinblum, Pravir Chandra, Robert Hansen, Matt Tesauro, Arshan Dabirsiaghi, Rafal Los, Jeff Williams, and hell, even the great Dan Kaminski made an appearance!
Just like any good conference, the awards and closing remarks held on the last day were full of thanks, toys, flying vendor squishy balls, foam rockets (courtesy of Tom Brennan), cheers, and clapping. It was truely a great way to wrap up a top notch con!
Finally, and although it’s been done many times already, I want to take a second to recognize all those OWASPers and DCers that came together to make this event what it was. I’m really copying this list verbatim from the last page of the conference booklet:
Rex Booth, Mark Bristow, Doug Wilson, and Kate Hartmann who provided the leadership without which this conference wouldn’t have come together.
The OWASP Board – Jeff Williams, Dinis Cruz, Dave Wichers, Tom Brennan, and Sebastien Deleersnyder who gave us “carte blanche” and trusted us to get this conference done.
The lead volunteers Barry Austin, Angel Contreras, Josh Feinblum, Lee Anne Hart, Martin Knobloch, Jeremy Long, Jon Rose, David Sachdev, Mike Smith, and myself.
The red shirt people of which there are way too many to name…THANK YOU!
And all those who spoke at or attended the conference!
So if you get the chance to attend a future OWASP event, or if you haven’t checked out your local chapter, hopefully this blog post and the others I mentioned in the first paragraph will shed the spotlight on the OWASP organization and how WE work to improve application security worldwide.
These days, it seems like most companies have a standard for everything…
Password standard – to make sure that we don’t simply leave the keys to the front door under the welcome mat.
Acceptable use standard – to make sure that employees aren’t playing WoW all day or hosting warez on the company servers.
(*)^11 standard – if you want to be PCI/SOX/HIPAA/* compliant.
Standards are meant to define what is acceptable or prohibited in accordance with company rules. Beyond achieving industry/legal compliance and when done right, these standards not only help employees determine right from wrong, they allow the company to operate knowing that everyone is on the same page.
Unfortunately, most organizations either overlook product/software development standards (or coding standards) or do such a poor job at defining the expectations that the development staff are left to code according to what they know best, or what they’ve done at previous employers. For seasoned and experienced developers, this might not seem like a terrible thing, so I’m going to illustrate with an example.
Joe is developing a login user interface for the next big product at the XCompany. This interface will be displayed to users visiting the application using a web browser. Being a seasoned developer, Joe implements the password portion of the login form using the HTML attribute type=”password”.
Mark is developing the iPhone application which will enable mobile users to connect to the same application that Joe is working on. Being an iPhone user himself, Mark thinks that the way the iPhone OS handles password masking is a pain and often results in failed login attempts. Mark then talks with the product manager and together they decide that instead of masking the password according to the iPhone OS standards, they’re going to display the full text of the password field until the user leaves the password field or after 3 seconds have passed without new input from the keyboard.
Jake is developing the Android application for the same product as Mark and Joe. Because Jake is paranoid and a hacker by night, he decides that the Android standard for handling passwords is too insecure and decides to totally mask the password field. Note: Android default behavior is to display the last letter typed in the password field for 2 seconds before masking.
While Mark’s approach might be acceptable and justified from a usability standpoint, and Jake’s approach might be acceptable from a security standpoint, we now have an issue where products from the same company are different in the way they implement the same functionality.
To make matters worse, without software development standards junior developers with little prior experience might end up introducing some major security vulnerabilities into the corporate applications. Lets explore another example.
Joe, Mark, and Jake are all senior developers with years of experience under their belts. In the past, their applications have been torn apart by hackers leveraging input based security flaws. As such, they’ve learned that all input must be validated prior to being consumed by the application.
Martin is the latest hire on the development team. He’s right out of college and this is his first real software development job. Eager to please, he takes on the responsibility of implementing the Search feature in the application. Bill, the project manager, agrees since the task is rather simple, all Martin will have to do is invoke the well documented search appliance API which then searches the back-end database for the results and display them back to the user. Martin quickly implements the search API and not knowing any better, doesn’t escape the user provided inputs before sending them off to the search API – now we’ve got an SQL injection vulnerability introduced into the system. (security folks, humor me, assume the API doesn’t escape input either).
While the first example seems rather benign, end users might interpret these differences as a failure to do proper quality control – which might be disastrous to the brand image if we’re talking about a major financial application. The second example leaves no room for interpretation, the lack of guidance for a new developer to lean on has introduced an avenue for attackers to steal your customers’ information or adversely impact the application by modifying or deleting critical information from the database.
If you don’t have a software development/coding standard in your organization, or if you feel that the one you have now is inadequate, here are some resources to get you moving in the right direction: