Secure Code Through Frameworks

This month our guest blogger is Jeremiah Grossman, founder and chief technology officer of WhiteHat Security. Jeremiah has been a frequent speaker at industry events including the BlackHat Briefings, ISACA's Networks Security Conference, NASA, ISSA and Defcon. In this post Jeremiah is sharing his insights on the problem of secure coding with frameworks.

Thank you to pdp for inviting me to guest blog. This is a first for me.

105 million sites make their home on the Web - 4 million more move in each month. That's a staggering number to think about, and as we well know, the vast majority of websites (I say 8 in 10) have serious security issues. Industry discussions go round and round about what should be done. We talk about secure coding practices, training, compliance, assessment, source-code audits, and the like. What's going to work? Then I read something Robert Auger posted, the lack of security enabled frameworks is why we're vulnerable, touching on an area I've thought a lot about recently.

When you look at safe computing education for end-users we tell them to choose strong passwords, patching regularly, install AV, and to not open attachments. This strategy hasn't seemed to help a whole lot, although the incremental results are good enough to keep doing it. So does anyone really believe bug-free code is coming in the next 1 - 5 years? Or ever? No way. Anyone with enough experience is robbed of that childhood dream. Then it certainly wouldn't make any sense to believe training web application developers to create secure code will result in them actually doing so. Sure there will be improvement in quality, but by how much and when do we see ROI? Developer education is good to do though won't provide the end-game we're looking for.

Here's my point: The only way I see software security improving significantly is if "security" is baked into the modern development frameworks and be virtually transparent. Remember, the primary developers mission is to pump out code to drive business and that's what they'll do not matter what. When developers find that its WAY easier and WAY better to do RIGHT by security, then we'll get somewhere. Not before. I didn't think of this concept, being a web application vulnerability assessment vendor positions you to see this see this happen first hand. Our data makes it quite clear, which websites are more secure than others.

At WhiteHat we assess vulnerabilities in hundreds of websites each month coded in all sorts of programming languages. Its clear to us systems designed with modern development environments like .NET and J2EE are WAY more secure than their predecessor. Session handling issues go away. So does large amount of XSS and SQL Injection. Are they all rock solid and infallible? No, of course not, but the differences are hard to ignore. To improve the security of software, the development framework seems to be making the most difference.

Archived Comments

kl

True, true. I think the biggest problem are environments where code is created from bits of text. The article praises ASP.Net for detection of HTML injection. I'm not familiar with this feature, but its description sounds to me like a patch on poor architecture (like PHP's magic quotes), rather than solid long-term solution. If it used templates that aren't just bunch of echoed bytes, but really a tree of HTML/XML elements (where it's explict when application outputs tag, attribute or text - preventing you from creating ill-formed HTML/XML), programmer would have to work hard just to make XSS possible.

pdp

kl, well yes but it is essential to understand that such an approach is not very flexible and you need to be very specific with the specs at a very early stage. Moreover, if you are planning to extend upon your application in the future you need design a schema/method for achieving this task. This is extremely long and time consuming process which not that many applications undertake. Not today. Not even in the future. In the open source world everything is pretty much build upon quick hacks that are glued together with some code. PHP applications are trivial to extend with .htaccess and mod_rewrite for example. IMHO, PHP is the most agile language for web development currently available. There is nothing else that gives you so much power in such a tiny core. I agree that applications need to be very specific in what they take as input and what they output but again this is a matter of finding the balance between accessibility and security. Usually we prefer accessibility over security because it works better in the long term.

deadonarrival

Yes, we need more security baked into the frameworks. But the by far biggest contribution will come through: * Education - developers need to learn how to create secure software. Universities etc. need to focus much more on security * Software customers - budget for security and demand secure products.

hrrm

i have been developing php commercially since php3 around 10 years back, and over the years have done lots of far out stuff with it. visualisation, cron jobs, VOIP/fax/SMS systems integration, web spiders, diskless workstation single sign-on environments, etc. all my development is based on a custom, heavily modular framework, since every time i evaluate an off the shelf open source one i find massive issues, typically in areas like suitability for alternate execution paths (unix shell or cron-based executions), and real extensibility (eg: hooks defined in framework core / existing modules). a lot of them are also bloated and irritate me by integrating crappy templating languages or defining only one, always-available optimisation/caching model. but to get back to the story of the post, security is also a concern. the real problem is - the web is complex. managing application-specific database state, http state and caching (browser, user proxy, frontend load-balancing proxy), application-internal multi-level caching (database, memcache?, filesystem?) each layer with its own automated expiry rules, multi-frontend node web server farms, multi-node database backends, failures, live migrations, different browsers, mobile devices with differing capabilities, user input....... and every few years a new piece of the puzzle. "flash vLATEST" "ajax" "silverlight" "javascript library #9999" "php vLATEST" "XML standard #99999" The life of any serious web developer is just too busy to perform code audits. They should be writing good code up front. Perhaps automated audits through SVN commit hooks or similar are a good solution. Probably there's good room for a well considered product in this area. Right now I audit the code of new coders I hire as I train them with the framework. Eventually I just trust them. There's not enough hours in the day...