Cross Pollination; it's not just for bees...

While I was at AppSecDC 2010 - I got into a great conversation with John Steven from Cigital about a great number of things. One of those, and something that I have been openly preaching for years now, is the need for the developers and security professionals to start talking to each other, start interacting, and most importantly start teaching each other.

There are a select few people, like myself, that are kind of double-agents. I have spent the last 5 years as a Senior Software Engineer and I did security - now I am an Application Security Engineer and I do development. At no one point in time have I seen these as opposites, and I think they compliment each other quite well.

What I would really like to see in both communities is people branching out and not only learning but working to solve problems in both. Developers attending security conferences, giving talks at security conferences about subjects like agile/xp, build systems, continuous integration, frameworks, and writing good code - conversely security professionals at development conferences, giving talks on code review, security testing, tools and frameworks, and giving cool demos.

I have started to see this adopted slowly by both OWASP conferences and the NFJS tour. Uberconf had a day long track that was almost purely security related information - but we need more community involvement. It is hard to justify an entire track dedicated to development at an OWASP conference if there will only be 5-10 people attending it. It is up to the community to start expressing an interest in this concept of cross pollination.

I envision a conference with the following people attending:

* Developers
* QA Analysts
* Security Engineers
* Configuration Managers
* IT Managers

And the following tracks:

* Development and Architecture
* Offensive Security
* Defensive Security
* Metrics and Reporting

Moreover, I would love to see more coming out of these tracks then just a bunch of people sitting around talking. I want to see people actually working together to accomplish things. Presenters designing a project that can be done - or taking an existing project and working on it.

It's funny because almost every conference I have been too - I almost always think to myself, here we have a building with 100-200 of the smartest people in and we are missing the opportunity to build things - make cool new discoveries - and invent technologies.

After my conversations with John last week I am convinced that we can start to make some of these things happen and a couple of us have already taken the first steps in putting some pretty cool ideas together.

If you would like to see this happen too, raise your hand - we can always use more people in the community bringing in new voices and ideas.

There and back again

So you may have been wondering if I disappeared from the face of the planet for a while, or where I have been - well, I am still here and I have been extremely busy! Lots of things to share, both in development and application security. So I will jump right in!

At the beginning of the year I came up with a couple of goals that I wanted to achieve this year. The first of which was to speak at come conferences. I spoke at the Front Range OWASP Conference (FROC) at Auraria on June 2nd. It was a great experience, despite the technical difficulties incurred midway through my demo and now I am hooked.

I presented on using the OWASP Enterprise Security API to solve REAL WORLD security problems. The presentation was very well received and I got some great feedback from those in attendance. My presentation slides and video are available on the OWASP FROC Site and I encourage anyone to take a look at the slides and video and let me know what you think.

In addition, just this week I was at The Uberconf where I had the opportunity to co-present with Ken Sipe on both Security Code Review and the ESAPI. Needless to say I am pleasantly exhausted from the 4-day onslaught of talks and workshops that was UberConf.

The second goal I set was to start a book - and I will be using my blog as a venue to test run some ideas that I have for the book. It will be on Application Security - specifically aimed at software developers. It may or may not feature the ESAPI, but you can be assured I will be using the ESAPI in examples code samples.

I am hoping to speak at AppSecUS 2010 in September, will be attending DefCon in LV for the first time - hanging with the DC303 Crew, and am submitting to do an ESAPI BootCamp at AppSec DC and AppSec Brasil.

So as you can tell, it has been very busy.

I will begin a new series to test-run for the book called Secure Development Recipes (working title) sometime in the next week or two, so look for those here.

More to come soon! Time now for some sleep!

SQL Injection... Still? Really?

When it comes to development blunders there is one thing that really just rubs me the wrong way, no matter what language I see it in. SQL Injection is that one thing. I can understand XSS bugs, DOS vulnerabilities, buffer and stack overflows, information disclosure bugs, and just about any other type of application vulnerability that you can think of, but really there is just no excuse for the most basic SQL injection bugs to exist anymore.

If you do a google search for SQL Injection, you will see 'Results 1 - 10 of about 2,990,000 for sql injection'

Yes, you did read that correctly.. That really does say 2,990,000 results for SQL Injection. Seeing that should raise a big red flag in your minds eye, a big red flag that says, "Why, oh why is this still an issue?"

Code Injection as a generalized vulnerability is the act of embedding executable code into an application thereby forcing that application to perform an action specified by the user. This is a pretty broad description and really describes anything from a BOF (that's buffer overflow for you non-l33t types) to XSS (Cross Site Scripting) to my favorite SQL Injection.

Let me digress for a second.

The vast majority of websites on the internet are run by one guy in his spare time. Not every site has a Development Team full of Architects, Designers, Security Analysts, QA Analysts, and Database Administrators. That one guy acts as all of those people, and more often than not, doesn't look very good with any of those hats on. That one guy also relies on the 'frameworks' he downloads off of the interwebz to take care of all that tedious difficult stuff for him. Keep that in mind as we move forward along the tracks of my train of thought.

SQL Injection differs from most other types of code injection in that it has the ability to change the persistent state of an application or a site. There are some other forms of code injection that can do the same thing either by themselves or by accessing the persistent storage used by the application in the injected code, but every Skiddie in the world knows about ' or 1=1. Thus, if your app has this:

$badSQL = "Select * from users where username='$_GET['username']' and password='$_GET['password']'"

You end up with:

select * from users where username='Administrator' and password='' or 1=1

Go ahead now and type that into your MySQL Client and see what that returns... Whoops.. If you don't have a MySQL client, well, you'll just have to take my word for it that bad things follow.

I could spend all day (or night in this case) discussing all the different types of SQL Injection attacks, and all the proper ways to combat them; fortunately I don't have to because 2,990,000 pages have already gone down that path according to the mighty Google. That is beyond the scope of this article. What I want to talk about is why this is still happening. Why do we still see hundreds of new sites and apps each year falling victim to something that is so widely known, so easy to take care of in almost any language?

The answer is simple, and is the answer to most questions about things dealing with Application Security. The answer, my friends, is pure and simple HUMAN LAZINESS.

To put it in the simplest possible way, developers, and I use the term loosely, are either too lazy to care about fixing this simple issue, or too lazy to learn that it is an issue.

Option 1: Too lazy to care
This covers a pretty broad scope of excuses and general B.S. that these self proclaimed developers will use. Everything from "I didn't think that my app would get enough exposure to attract hackers." to "There's nothing worth stealing in my application anyways."

For the too lazy to care breed, let me just tell you this. Skiddies love your small website that you built for your bowling league photo album. You know why they love it? They may be skiddies, but even they know that they can completely take over your site and you will never be any the wiser because you are the guy that would never, never, ever expect to have your site pwnt.

Option 2: Too lazy to learn
I think this covers the vast majority of the people who are guilty of belonging to this caste of developer, specifically in the web space. This is the guy that got a PHP for Dummies book for christmas from his wife's brother's dog's former owner, read the first two chapters, and starts up a project on SourceForge for the newest latest greatest web app in the world. You sir, have commited the 8th Deadly Sin - "Thou shalt not distribute code that sucks"

So there it is. This is why SQL Injection has been and is still on the OWASP Top Ten List since 2004 when it was incepted.

In conclusion, I challenge you, blog-o-sphere, developers, humans - to write your next batch of code with input filtering and proper validation, or using parameterized queries (which I believe are available in almost every major interpreted or server-side language there is by now).

I challenge you to get this off of the OWASP Top Ten List for 2010.

I challenge you to overcome the laziness and put time and effort into learning your craft, or walk away and leave it to the people that do. There are plenty of ways you can get your information onto the tubez without ever having to write a single line of code.

While you're at it, I challenge you to share this post with your friends who may or may not fall into one of these categories, your friends who will read this and nod their head in agreement, and your friends who simply like to slashdot and facebook share every single page they come acrossed.

Until our next blog-o-spheric confrontation - may the schwartz be with you, farewell, and thanks for all the fish!