Securosis – Building a webapp security program part 3
December 4, 2008
A bit of a lull in posting – I’m noticing a pattern when the number of posts I write are inversely proportional to how much code I’m writing. As I enjoy the problem-solving nature of programming, I spend more and more time doing that when I have a project. In any case, Rich over at Securosis has part three of their "building a web application security program" up. Parts 1 and 2 were a little light, introductionary material (no issue there, but not much to get any teeth into), but this one starts to get to the meat of the issues.
In this post Rich hits the nail right on the head of why webapp security is "hard" – there’s lots of things stacking the deck in favor of attackers. I don’t have any major issues in the items that Rich and Adrian put forward, but I think in the future of our industry some of these could be turned into positives. Note that I say in the future – there’s still a long way to go before that time, but I’m looking forward not back.
Custom code equals custom vulnerabilities: Any type of "bespoke" software is going to fall against this in one way or the other, and we don’t have that much choice - few businesses are the same, and all will need their own "custom" software in one place or the other. It’s impossible to get away from the "programmers create bugs" issue, but it is possible to make it easier to create "good" software first time. What is required is frameworks/API’s/libraries that get programmers make it easier to do the right thing than the wrong and leading to creating a vulnerability. One of the great things about C/C++ is that it’s so flexible and powerful that you can do so much, but it’s also the reason why there’s so many vulnerabilities in those languages – there’s no safety catch and the gun is always loaded. In addition to the programming issues themselves (bugs), design issues can also creep in (flaws). There’s been lots of work on design patterns, and we need to transfer those lessons to the web world and start teaching those basic building block rather than focus on the vulnerabilities (or more rather the exploits as we do currently). There’s a lot of good work going on with this in MSFT’s patterns and practices team, but I still think there’s a ways to go to make it more "accessible" and used more.
Firewalls/shielding alone can’t protect web applications: Absolutely. (I wish that MSFT had filmed our BlueHat panel on this as I think it was a great discussion, and just haven’t got time to go through what we all talked about)
Eternal Beta Cycles: Amen here! Far too frequently have I seen webapps developed quickly with no lifecycle model and very little QA. Perhaps it’s the nature of web development - maybe it’s the "internet time phenomenon" (you do things quicker on the internet – a "year" is 9 months instead of 12 is one version I was told), or the easy, "Lego building-block" nature of programming for the web, or the "instant service pack" approach I’ve talked about before (no need to get it right, just ship fast and fix issues when they turn up – users always get the latest code anyway). Whatever the case is, web software on the whole clearly isn’t tested as much as it’s cousins in other environments.
Reliance on frameworks/platforms: I think I’ve answered this above already – reliance on frameworks/platforms isn’t a bad thing if those platforms don’t allow us to shoot ourselves in the foot, and promote good design patterns. Case in point – the difference between PHP and ASP.NET.
Dynamic content: The issue at the root of this I feel isn’t that content is dynamic in the web world, it’s just that it’s extremely rich (data and code mixed together, and the ability to call in data/code in from different places, in many various ways, outside the control of the app - things we know cause problems) and a very forgiving environment (browsers going "oh, I think I know what you were trying to do, let me just accept that anyway"). We’re pushing the web to way beyond what it was designed to do, which isn’t a bad thing, but forces us to "hack" technologies together for the next step (i.e. AJAX). If browsers, and the HTTP/HTML spec were tighter and a with little more security in mind, I think we can do better. It’s not going to happen though because there’s so much out there that adheres to the "thou shalt not break old code" rule.
New vulnerability classes: I’m going to disagree here, and I believe that Gary has the same thoughts. What we are seeing in web vulnerabilities isn’t all that different from "old(er)" and very well known issues that have constantly affected software. Saying that "the web is different" (something I’ll admit to doing myself a while back), its really not true. I think we know most, if not all, of the attack/abuse patterns we’re going to see, and the rest is just a case of figuring out what you can do with it (exploitation). Someone correct me if I’m wrong, but for the past few years all the web-based vulns I’ve seen are pretty much down to input validation and misuse of trust. They all leverage those vulnerabilities, just have different exploitation vectors. I would wager that if we fully vetted inputs into webapps (and I mean fully – whitelists containing data that we know we should be getting, and very restrictive, no more "oh, I’ll let that slide"), 90% or more of the attacks we are hearing about will just go away. We already know what we should be doing to secure software, webapps included. Saying that there are new vulnerability classes just puts out another excuse.
So, overall I Rick and Adrian have this down so far and are setting a great path of information for people to follow. I’m really looking forward to the rest of the series as they get into more technical and actionable material.
Posted in Security
