Web App Sec Predictions for 2010

Normally at this time of the year, I would talk about the industry’s achievements over the last year.

None. Zilch. Nada.

We’re seeing more SQL injection used in real world attacks than ever before. XSS is still with us, and one of the biggest offenders – PHP – has made zero moves to include proper encoding or encoding by default for echo and print, or including a safe by default generic SQL layer that is enabled by default and works with the three or four most common databases (e.g. MySQL). The adoption of PCI seems to have made little difference in the amount or severity of breaches.

Things like ESAPI, App Sensor and ESAPI WAF are the only true breakthroughs in 2009. But outside of OWASP DC, there’s no love for defences. Hats off to Jeff Williams and the entire ESAPI for * team, Michael Coates, and Arshan for the only true web app security efforts this year.

So let’s forget about 2009 and move on to 2010.

  • Full disclosure / responsible disclosure / etc has failed (again) to improve security as it always has. We should stop doing it. Nearly every app has at least one or more of the OWASP Top 10 2007 / 2010 issues. It’s like shooting fish in a barrel or using dynamite to fish. Stop wasting time on it and come research how to put in safety by default in every language and framework, starting with woefully insecure frameworks and languages like PHP.
  • Conference presentations about attacks are still getting all the sexy girls and media! Conferences and the media have to stop promoting attacks – it’s irresponsible and wasteful. Let’s start talking about defences instead.
  • No more penetration tests! We have to stop doing penetration tests. They suck at predicting the safety of a system, particularly insider risks. Pen tests have value at mature clients who have done the hard work – an SDLC, secure requirements, secure development, peer reviews, code reviews, and extensive testing. They are a validation of the other security benefits, not as a “my X is bigger than yours” exercise and certainly not absolute proof of security.
  • SDLC’s are still rare in the clients I visit. We need to encourage the adoption of SDLC, and require secure requirements.
  • Agile still needs a lot of security as yet. User Stories still have no space for a security outcome in most environments. It’s hard to code review every milestone let alone every sprint. We as a security community need to do a lot more work here to fit in with the modern development methods in use.
  • Developer training is still in the nascent stage and is the only workable method of producing secure apps by default. I donated my full two day deck to OWASP at the beginning of 2009, but as far as I can tell, it hasn’t been updated or given any love. I hope that can change over the year. Please go here and help make this deck the de facto developer training deck!
  • We have to encourage or even mandate folks who outsource / out task / buy off the shelf software to only allow the acquisition of secure software, with the burden of insecurity firmly on the developer. Laws and licenses that prevent this must be changed as insecure software is not fit for purpose and thus defective. Obviously, there’s a huge difference between accidentally insecure and deliberately insecure software. If you don’t have an SDLC and a security program, an ISV is deliberately insecure and must face the costs of their negligence.
  • Over-reliance on silver bullets (WAFs and so on) is harming the effort to fix the problem. Silver bullets don’t always work, and eventually, you’ll have to do the right thing. I don’t know what we can do here but yell at the sky as the marketing dollars for these things overwhelm that simple message.

Let’s not waste another year. Let’s get moving on secure defenses, SDLC, R&D in agile technologies, and developer education.

Published by vanderaj

Just another security geek

Join the Conversation

6 Comments

  1. Could not agree with you more on penetration tests. We also need to think about enumerating goodness, not badness, and stop a reliance on user education.

    People are like electricity; they will take the path of least resistance.

  2. Way off course on Penetration Testing. The budgets of many organizations can not afford code reviews, change and incorporate security into an SDLC, Secure development and various other “new” techniques. We’ve seen that code review as well as training still leaves XSS and Injection problems, because its just a fact. Developers, reviewers get lazy and revert back to old bad habits. Face it. You need to balance all aspects of these things to effectively stop the “known” attacks of today. You also need to get people to understand that this is NOT a singularity but an ongoing, ever changing environment that produces new vulnerabilities never dreamed of at the time of code hashing.
    Just like someone stating that a WAF is the correct and only way to do this. Dead on wrong. Its a concerted effort across the board, but you will never see this implemented UNTIL you start changing the mindset of Managers, program Mgt included.
    They lump “security” as part of Risk Management and as we know this is wrong. Risk Assessments are usually done at the beginning of an application prior to any code being written.
    The only way to be sure you capture every aspect is to implement all of it. The bottom line is that you do an injustice to the Application Security environment stating that “PTs are useless”.
    Get your mind out of the code and LOOK at what needs to be accomplished and you will realize, you are missing that its no one solution will fix the problem.

  3. I do both penetration tests and code reviews. Penetration tests find a tiny fraction of the items a code review performed with a live test application to eliminate false positives will find. Code reviews find things that cannot be easily discovered by penetration testing alone. Penetration testing with zero knowledge might give someone a woody, but it’s really a huge waste of money.

    Code reviews are not that much more expensive than penetration testing, and if done right, they can save hundreds if not thousands of days of wasted developer time in resolving issues in their code. Code reviews are very cost effective.

    In my 12+ year experience, once given penetration test findings, folks fix just the things in the report, and do not search for any other similar issues within their code. So we do a do-over a bit later, and surprise, they still have XSS or SQL injection in different places in old, modified and new code. If you’re in the pen testing business, great. If you’re in the business of being a trusted advisor to your clients, then this is a FAIL.

    Penetration tests happen far too late in the development process to prevent these issues going live, and if it’s your only control, it’s not enough. Often I test older applications, and it’s like dynamiting a lake full of fish.

    We need the full suite – security architecture, developer training, code buddies, code reviews, penetration tests, and WAFs. No one thing is the silver bullet. In my experience, firms that have an SDLC, do security architecture, get their architects and devs trained up, peer review themselves for coding flaws, write abuse cases in their unit test, and perform code reviews have the best outcomes in penetration tests. Those that just do penetration tests are unfortunately doomed to repeat their mistakes as there is no loop to train the developers not to make those mistakes again, no policies or peer reviews to prevent those issues creeping in again, and no tests written to ensure that the issue doesn’t get re-introduced.

Leave a comment

Your email address will not be published. Required fields are marked *