mostly useless crap from me

Howard Schmidt has been appointed as the US’s cyber czar. The position has been open for months, which is … interesting … considering how vital IT is to the world’s economy and safety.

Mr Schmidt, if you read this blog entry, please consider the following:

• Web Application Security is the most pressing need for change. It’s the key to nearly all attacks today, and the least well funded. Help OWASP and others to improve developer education, get the message out to CIOs to apportion their training budgets and remediation efforts accordingly.
• Be positive not negative. The attackers really don’t care if you “keep your computer up to date”. Let’s work mostly on things that can stop the issue in the first place. The horses have already bolted. Let’s make a better stable and fences so they can’t get out again.
• Push for real security, not security theatre. Listen to Bruce Schneier, and not the profits of doom that want to sell you useless widgets for billions that do nothing but annoy folks.
• If you can do any change, the first change has to be removal of indemnity for negligence with software development from licenses and sales. If an ISV doesn’t have a security development lifecycle, doesn’t include secure business requirements, and doesn’t require its developers to be trained in security coding practices, it IS negligent, and must be open to lawsuits. What we have today is not working and must be changed.

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.

Peter Quodling. an old friend, e-mailed out of the blue last week. I have a lot of time for Peter as he’s one of the few Australian IT architects that really knows his stuff, plus he’s a really nice guy. He is involved in OLPC in the PNG region. Last Christmas, I nearly bought an XO under the Buy One, Give One program so Mackenzie could have a cool first laptop … and somewhat more honestly, so I could play with the OLPC until she’s old enough to type let alone talk. However, circumstances prevented toy purchases of that magnitude, and I forgot all about the XO until this week.

I thought through my various abandoned projects (for I have many), trying to work out which would help the OLPC project and kids all over the world. I’ve had an itch for a while to do something for the One Laptop Per Child project (OLPC), but never really had a substantial idea that would help transform kids’ lives rather than my own. But now I think I have just the project.

So I put in a proposal for two laptops to help develop GaiaBB (which is UltimaBB++ (sic gloria transit), which is XMB++, which is awful) into a OLPC specific product.

My current plans are:

• Get GaiaBB.com back up and make it OLPC centric. Revitalize the Sourceforge project.
• Finish OWASP ESAPI for PHP. I need it for this project.
• Port GaiaBB to the OLPC, porting the database to sql lite, and probably using LightHTTPd. I could use Apache + MySQL as per now, but these are huge compared to SQL Lite and LightHTTPd, and on a device with limited NAND memory, every byte counts.
• Ensure GaiaBB works properly with Browse, the XO browser. I might need to turn the nested tables into CSS templates a bit sooner than I intended
• Beg, borrow or steal a graphic designer to come up with a GaiaBB theme that works well with the dual color display (it’s both black and white and color and more wide than tall), and possibly work out how to detect the XO’s current screen state from the web page so I can dynamically choose a grey scale or a color theme.
• Simplify the product so that it’s more manageable by young ‘uns without dumbing down too much or removing some of the depth and surprise features of the product
• Write an installer that makes it easy to install on the OLPC. I want kids to be able to create their own social communities and for them to easily share their forums with their friends.
• And this is where it gets fancy… write a web service that allows authorized folks to replicate their version of the forum with other versions of the forum … without causing major security issues. That way when you’re at home and have no Internet service, you can still read the forum and write new posts and then sync when you’re at school. This is where I will have to significantly change the way GaiaBB works as right now, it’s a single database deal and assumes that there are trusted administrators.
• Go through the code with a fine tooth comb, replacing all the crappy security bits with ESAPI for PHP. Some parts are truly ancient (circa 2000) and need refactoring. As part of this, I will ensure the code is easily modifiable. I learnt how to code by changing other folks’ code and then starting to write my own, and I want kids to modify the heck out of this forum so as to create a new generation of coders excited about programming and IT in general.
• Lastly, possibly write a OLPC School Server centralized GaiaBB hub for schools to run “their” forum which students can sync with in a safe fashion.

The proposal has been approved, and the laptops are on their way. They are sending me three XO’s! Awesome. Better get cracking!

I work on an open source project, ESAPI for PHP. Well, “work” might be too strong a word for it, but I try to prod its lifeless carcass from time to time. That’s not the reason I write today. I write because of stupidity, and evil being conducted in the name of a “law”.

I have a fellow open sourcer, who wants to contribute to ESAPI for PHP. He’s actually completed a MVC framework for PHP (jFramework). Due to Google blocking Iran, this gentleman can’t easily contribute to our project, which hosts its repository on code.google.com. ESAPI for PHP will not help build a nuke. It does no crypto of its own. It will make PHP applications safer and more secure – but you can do that anyway if you read half a dozen pages on PHP’s website.

This is madness. ITAR is about blocking the EXPORT of sensitive MUNITIONS (i.e. weapons) TO Iran and other “hostile” countries. ITAR is NOT about blocking the GIFT of intellectual property and valuable developer cycles FROM Iran, helping everyone all over the world, including those folks in Iran (as well as Australia and the USA). This is stupidity on a scale I’ve not seen in a while.

Google: you are doing evil.

Stop this madness, now! Call in your tame congress critters and tell them how stupid and harmful this particular nonsense is and get it repealed. Grow a spine and take a chance. Unless someone open sources a command and control system for a warship, a missile guidance program, or puts Nuclear Reactors For Dummies up as a project, all of the projects should be available for download worldwide. Those one or two mythical and nonsensical projects should not block an entire library of human knowledge to the entire Iranian people just because of some imaginary evil open source project might help Iran’s nuclear program or military. The stuff we do is not rocket science.

Stupid and outdated laws / treaties like ITAR make us disrespectful of all the other laws and treaties, and make us lose all respect for those who abuse their positions of power in the name of “security”. The way to improving relations between countries is not to block them (how’s that Cuba policy going, anyway?) but to engage with them and stop the evil ignoramuses on both sides stopping everyone being happy and free, or just contributing to an open source project.

I read Jakob Neilsen’s post on password security, and although he has a point, there are several issues as to why this is a monumentally bad idea.

First, passwords are a fundamentally bad idea for all data risk classifications. Instead of trying to make passwords more usable, how about getting rid of them?

Second, exposing folks’ passwords in a shared environment will expose them in more ways than one. For example, most folks use the same password everywhere. I used to do this when I was 16. Then I migrated in 1989 to having low, medium and high security passwords. Then about five years ago, I migrated to using long random passwords for nearly everything. I do not know my password for my blog. I cut n paste my passwords from a password manager. I’m ashamed to say that I still use the low security password from 1989 from time to time – mostly to recover access to long lost internet sites. So if your social networking site – where you’ve evaluated YOUR risk to be low, well… that user uses the same password EVERYWHERE, including high risk sites such as Internet Banking, for tax, for their insurance login, etc.

Third, malware that currently snaps screens when used with visual keyboards (security theater!) will have a bonus time with this scheme, or any scheme like it (think iPhone where the last character typed remains on the screen for a second or so and then becomes a bullet). However, if you have malware, you have more interesting problems than just clear text passwords.

I am all for killing passwords. They are crap. They are insecure. They are hard to remember. IT Security folks with NO UNDERSTANDING of human nature or how this terrible usability costs the business ask us to change them every 30 days and you can’t have the same password for the last five years and the password must not be a dictionary word and must contain punctuation and numbers and upper and lower case characters. The only people who can do that without ringing the help desk are the tin foil hat people like me who use password managers with long random passwords. I love going to sites with those sort of rules – the passwords are nearly universally on post it notes or written on the cubicle wall or dry erase board. Dumb!

So how do we improve the situation? I strongly believe that for the average user, the browser should take over the credential for the user. A nice auto-generated certificate login managed basically transparently by the browser’s credential manager makes the most sense. This should be able to export to a standard file format that all the browsers agree upon so that users can upgrade their machines, and move amongst them. Obviously, Apple already has MobileMe to help sync those credentials around, and this will help folks like me with more than one computer. If you’re out and about and need to log in remotely, you log in to MobileMe (or similar), and approve the site you want to log on to for (say) 10 minutes from the computer you’re currently on. Then you go to the site you want to go, like Wikipedia or Travelocity with your full strength credential… that will not stay on that machine and will not work after a few minutes.

For value transactions, the use of SMS transaction signing and two factor transaction signing should be mandated where PII, finanical or health data is concerned.

Then we can put passwords out of their misery, and folks never need to remember their passwords ever again. Jakob is right – passwords suck. It’s time for them to die.

Well, what an interesting weekend. A cold, working like a slave, and one of my co-workers is a father for the first time (Congrats, Ty!). But that’s not the most interesting news.

I will be taking sole ownership of my forum, Aussieveedubbers, sometime this week. This means that I will have to spend a bit more non-existent personal time attending to it.

This is good and bad news:

• For UltimaBB, the underpinning forum software, it’s fabulous news. UltimaBB was never released and is now effectively a dead project. My acquisition of AVDS gives me the impetus to make the forum software as good as I can make it. Once I’m complete, as it’ll be by far the most secure PHP forum out there. Very few open source programs ever get the chance of a top to bottom code review. Once I’ve fixed all those issues, I will think about possibly adding a few flashy features and integrate it with CPanel and others, so ISPs can easily deploy it. Obviously that integration will not come cheap. Hopefully, I can start to earn a bit of income from the forum, finally.
• For OWASP, this is not good news. I have two current projects, the Developer Guide and ESAPI for PHP. I need ESAPI for PHP to be complete to help UltimaBB, so you can guess which of the two projects will get my time.
• For my personal life, I hope Tanya will forgive me making her do some basic accountancy work. I think it’ll ease her eventual way back into the workforce in a few years, as she is terrific at accountancy, and I would hate to see her lose all her skills for the want of a bit of work here or there. However, it’s not just delegating the book work to my poor suffering wife, it’s also a bit of an ask for the few hours I have to give right now.

So if you want to help with the Developer Guide, please join the mail list and let us know how much time you have, and where your interests are.

The last time I talked about OWASP’s new Application Security Verification Standard, I had performed a Level 2B-3 review of my forum software, UltimaBB.

This time, I’m working on a real project for a real customer. It’s been interesting.

• Level 1A and in particular, 1B has been emasculated. I’m not really sure of the value of these reviews as they have 22 and 13 controls to review respectively. Taken together at Level 1, it might have *some* value, but I’m not sure you’re getting a whole lot of assurance. I would only recommend this level if you have like 1000 apps to review, and you need to see which are the most atrocious so you can target Level 2B / 3 / 4 reviews. Sure they can be done quickly, but I’m not sure they prove anything in particular. The good news is I reckon the current state of the art dynamic and static tools could produce reports absolutely compliant with this level with no real changes other than ASVS report format (R1-R4) and risk rating methodology. The problem is that there are no tools today that do both automated dynamic testing (a la IBM’s AppScan or HP’s WebInspect) and automated static code analysis (like Fortify’s SCA or Ounce O2) in the one tool, so combining the output of two different tools in the time available would be a challenge (whilst being incredibly boring and unrewarding to a skilled assessor).
• The basis of a Level 2B review is “manual” verification, most likely using the results of automated scanning. You don’t HAVE to do the automated scan – you can do it by hand. Based upon my experience of both UltimaBB and this review (a mixture of ASP and ASP.NET), the automated scan was more of a waste of time than a blessing. Yes, it found XSS and was quite specific to its location, but honestly, in terms of performing an ASVS review, as long as you know how XSS works (lack of input validation and output encoding), you should be able to find them with grep or your favorite search feature in far less time. The problem is that the scanners are asked to scan for 88 things at Level 2B, and I’m pretty certain that without AI, the scanners are only going to be able to do around 50 of the findings automatically. For example, I have a CSRF token in my forum. The scanner I use claimed that each of the forms had no CSRF protection – a false positive that took nearly all of the alloted 30 minutes to eliminate, and thus put me behind schedule.
• Time ~= money ~= quality. We tried to make Level 2B reviews work in five days as this is a current sweet spot of this rather depressed market. Five days was chosen on best practice productivity of 15 minutes per control + slop time + QA. With the new ASVS release, there’s now 88 controls to review. That’s about 1 control needing to be written up every 20 minutes, assuming four hours for QA (10%) and four hours for the Exec summary. Doesn’t sound like much, but there are many controls that simply take longer than that. Some don’t. I honestly think Level 2B reviews cannot be completed satisfactorily on large or complex code bases in five days.
• Level 3 reviews have 109 controls in 13 categories. This is at least 10 working days’ worth of work – each control gets 30 minutes (assuming 1 day for QA and four hours for Exec summary), which is about right. I personally think Level 3 is about the right level for most code reviews as it does nearly everything a Level 4 review does, but is realistic in terms of schedule, budget and outcomes.
• Level 4 Reviews have 121 controls in 15 categories. If anyone is offering a Level 4 review of any size code base in less than four weeks, take a very hard look at their methodology. I just don’t believe you can satisfy the need to look through each file for malicious content in less than that time frame and give it a “professional indemnity insurance proof” result. This level of review is painstaking and I doubt many people will end up asking for it.
• Report Length will be an issue. Using the reporting format (R1-R4), the average Level 2B report in 12 point fonts will be about 100-120 pages long. This is far too long for the paying customer (== execs, which is different to the consuming customer – the developer), so spending time on the Executive Summary and follow up report out is essential if you’re to communicate the results in any meaningful way. So you know those time lines I mentioned above, take out a good four+ hours out of the juice to write up a proper Executive Summary and other report out materials. This reduces your time per control down to 20 minutes for a five day report and about 30 minutes for a ten day report. Obviously, if you have a large or complex code base, you’re going to be hosed if you’re not on the top of your game every single work day. Put away the nerf guns – it’s work time!
• For those of you used to writing reports that eliminate sections that don’t apply, you’re going to get a shock with ASVS. You need to write up ALL 22, 13, 56, 88, 109 or 121 findings – regardless of if the code is awesome or awful. Leave time for it!
• The OWASP risk rating scheme is a monster. 16 elements per item x say 88 items = A BUCKET LOAD OF CALCULATING. If you’re still using Word to write your reports, you may want to write macros to automate the calculation and Executive Summary elements, or else you’ll be here next year working out what the risk is. You should also check the balancing on the OWASP risk ratings. I find they produce a lot of mediums and highs. I will talk to Jeff about making the scale 0, 1..5, and producing a universal 1, 3, and 5 set of elements to make it easier to produce a more balanced risk rating. Find some of your previously QA’d risks and try them out on the OWASP risk rating to see if you get similar results (and you should!). If you don’t, adjust the risk rating methodology and document it in your report. You don’t want to be known as the risk manager’s nightmare. Too many highs == less work in the future if they constantly (successfully) argue with your ratings for being unrealistic and too high.
• Missing controls. By design, ASVS does not have every control under the sun. Some missing controls are actually very surprising. As there’s so much work in an average ASVS review already, I doubt many folks would add back these missing controls. However, I think the ASVS team is making a mistake by not making Level 3 and 4 include some of these more common controls, particularly if the clients asking for Level 3 / 4 reviews probably already have these controls in their IT security polices and would like to know about the status in their apps. We’re talking things that are found in ISO 27001 and COBIT 4, so I’m not just being tin foil hat crazy here.

So what do I think about ASVS for code reviews? The more I use it, the better I feel that we’re meeting the our customers’ need to produce something that doesn’t produce HIGH risks for information disclosures like internal IP addresses (which are irrelevant). The customer is in control of the amount of looking at their code, and we’re producing developer ready results that affect the design and architecture of the code, which hopefully means much safer applications in a few months’ time.

Good news! Safari 4.0 has:

• Supports read only HttpOnly protection
• XMLHttpRequest read protection for set-cookie, set-cookie2, and GetAllResponseHeaders!

It does not protect against cookie writing.

Test script here: http://greebo.net/owasp/httponly.php

This is a great improvement! Now all major browsers support HttpOnly in some form.

thanks,
Andrew

A long, long time ago, I took on running Aussieveedubbers, a forum based around the love of Volkswagens. We were on EzBoard, where the adverts and performance sucked so bad, that free was no longer acceptable. Over many iterations, I now run UltimaBB, a derivative of XMB. I had various titles – including lead programmer – at both projects for a while, but my main claim to fame was to get XMB 1.9.1 out the door with Tularis, the lead dev at the time, and the primary early force behind UltimaBB along with John Briggs. John implemented the hacks, and I did the architecture changes required to make them suck a lot less and hopefully make them more secure. In a way, I have – UltimaBB does not suffer from ANY of the XMB Bugtraq failures. Therefore, I am a coding god and UltimaBB is secure, right?

I got going in forum development primarily through security fixes. By the time the UltimaBB effort died and XMB imploded in 2008, I thought I had gotten most of the security bugs out of the code. UltimaBB was a shining beacon of the bazaar approach. Or so I thought.

But like most in open source, there’s a huge difference between what I think is secure, and what is actually secure. Just because I think it is secure doesn’t make it so. I wish more folks in open source projects would get this very simple message. You suck, and as long as you know that, everything (in time) will be okay.

So, like all good scientists, I do not let my good opinion of myself get in the way of a solid slap session. I gave UltimaBB a thorough code review using OWASP’s forthcoming Application Security Verification Standard at Level 2B, which encompasses a manual code review for 83 controls with an optional use of automated static code review tools. I used Fortify’s awesome Secure Code Analyzer, which is almost certainly the best in the business today. It didn’t find everything, but it highlighted a number of deficiencies I already knew about quite reliably.

I can’t claim I did this review because I suddenly had a huge chunk of time on my hands, but because I am implementing a new service at Pure Hacking, and we’re using ASVS as our verification baseline. I’ve added a few more things in as I think they’re important, but the main thing is that I’ve now validated that the ASVS produces a reasonable outcome for an average program, one that should have been reasonably secure – because *I* wrote a great deal of it, and certainly the security bits.

The good news is that ASVS can be used as a security consultancy’s baseline for a partially automated, but primarily manual code secure code review. I think with a bit of tweaking, we can develop automated searches in most languages for about 50-60% of its requirements, which will dramatically improve the quality and reliability of secure code reviews.

The bad news is that my forum sucks. I have a bunch of extreme, high, medium and low risks to fix. Until I’ve fixed them (as there’s precisely one forum running this code out there – mine!), I can’t go into them too much, but let’s just say that I was disappointed with myself, and I’ve taken myself out the back and slapped me silly.

Luckily, I have a good client for this review (me), who will actually fix all the defects and lacks found so far.

OWASP EU 2009 is coming up! This year, it’s held in Kraków, Poland. Time to book!

Program highlights:

• Keynote: Ross Anderson from Cambridge University. I’ve wanted to meet Ross for many years. Those guys are legends!
• Keynote: Bruce Schneier. I bet there are groupies
• w3af – Andrés Riancho. This is one of the best free toolkits I’ve tried recently. It’s awesome.
• HTTP Parameter Pollution, Luca Carettoni, Independent Researcher & Stefano Di Paola
• OWASP Source Code Flaws Top 10 Project, Paulo Perego, Spike Reply
• O2 Advanced Source Code Analysis Toolkit, Dinis Cruz
• … many others!

Although I would love to be there – I had a blast at OWASP EU 2006, I can’t attend this year. Which is a shame, because OWASP AU 2009 was huge fun, and I can’t imagine OWASP EU 2009 would be anything less.Don’t make the same mistake as me! Book now!