Good news! Safari 4.0 has:
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:
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!
I am appearing at OWASP Melbourne tonight. Come along and enjoy my take on protecting business value.
AccessReferenceMap, RandomAccessReferenceMap and IntegerReferenceMap, and enough of the other classes (FileBasedAuthenticator, StringUtilties, etc) are present and working:
This is very good news as although some of the other classes in Milestone 1 are complicated, these two classes were actually going to be some of the hardest to port as PHP does not have the equivalent of J2EE Set, List, HashMap, and many other basic data structures. What PHP does have is native associative arrays (somewhat like HashMaps), ArrayObject, and ArrayIterator from the SPL. The problem is that PHP doesn’t like sparse arrays with very long indexes:
$foo[“THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX.”] = $value
So I had to make up a workable hash function and hope for zero collisions. I tried using spl_object_hash(), but that actually is too good. It uses the object’s value AND pointer position, such that:
$foo = “123”;
$bar = “123”;
spl_object_hash($foo) != spl_object_hash($bar)
I think I still need to add a few more test cases as my hash function WILL collide when there are two direct object references of the same value, and thus will not be safe for some uses.
I’ve been working on the essentials for OWASP ESAPI, and now it passes its first set of unit tests, in this case a 1:1 mapping of the ESAPI exceptions test class.
This is the first set of classes that fully passes a set of tests that is exactly equivalent to the J2EE trunk SVN. Yes, it’s one test, but it tests the exceptions thrown by every single one of the Exception classes.
This is key as ESAPI throws a lot of ESAPI exceptions when things go south. In addition to ESAPI exceptions, the PHP port will also throw SPL exceptions, such as InvalidArgument and so on as it makes sense to do so.
To get this far, I’ve had to hand hack the Authenticator, User, Logger, and Intrusion Detection classes – currently no errors are sent out by ESAPI for PHP, but give me a bit of time and it will happen. String Utilities is also partially there. Authenticator is interesting as it actually does generate strong passwords, and actually reads from the resources directory for the user’s file and decodes it into an array. However, some of these behaviors are hard wired to allow more of the Milestone 1 classes to pass tests, rather than be part of the Milestone 3 build.
I’ve started work on the RandomAccessReferenceMap class. It’s almost there; but unfortunately, I’ve got to go to bed as it’s 2 AM. It’s so close I can smell it. Once done, that class is a close relative of the IntegerReferenceAccessMap, and so there are likely to be two valid and useful ESAPI for PHP classes done soon. I’ll see if I can finish it and check it in before I have to go to work on Monday.
No posts for like a month or two, and two in one day? Time for some shameless crass philanthropy and some good natured commercialism.
In some exciting news:
In other news, Pure Hacking is holding a one day WebEx (i.e. remote) training session on Testing Web Applications with Ty Miller as your host. If you’re interested, please drop me a line.
Last night, I spoke to the phpMELB folks for an hour on ESAPI for PHP.
The talk went well, and they taped it. When the video appears, I will link to it.
More importantly, I worked on ESAPI for a couple of hours after returning last night, and finally have something to show everyone! ESAPI for PHP almost passes some tests:
This means that folks can start cutting code as the test framework and the main framework are fully stubbed out and ready to go.
For those of you sitting on the fence about coming to OWASP AU 2009, it’s time to book. 🙂
The training materials I’ve developed using OWASP ASVS covers all the ground in the ASVS in one day, from a developer perspective:
It’s going to be a long day, so bring your game to the sunny Gold Coast, Australia. OWASP AU is a true bargain compared to commercial offerings.
If you have some training budget, book a ticket and come see me and have a blast!
I feel sorry for Twitter – they have the poster child of low value apps (which usually means no security controls or review), and then all of a sudden, they get done over using such a simple attack that it’s generous to call the attack a “hack”. Of course, because of the targets – Barak Obama, Stephen Fry (the world’s best comedian bar none), who are HIGH value targets, Twitter is feeling the pain of applied media heat today.
Twitter on Monday said the hacker had broken into 33 accounts by gaining access to tools used by its support team.
“These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the email address associated with their Twitter account when they can’t remember or get stuck,” wrote Twitter co-founder Biz Stone in a blog post. “We considered this a very serious breach of security and immediately took the support tools offline. We’ll put them back only when they’re safe and secure.”
– from ZDNet
If Twitter had simply built their software (in 2006) to follow the 2005 OWASP Guide 2.0, they would have been safe today in 2009.
I cribbed and re-phrased these from the 2002 Guide 1.0, which were in turn cribbed from the seminal Saltzer and Schroeder’s 1975 paper. This stuff is not new.
This is all about application architecture. If Twitter had designed their admin app to be non-reachable from the Net, the attack would have failed. If they had made users unable to perform admin tasks, they would have been safe. If they had defense in depth, they would at the very least known about the attack. If they had separated admin tasks from user tasks properly, they would have been safe. If they had not hidden the URL or parameters to the admin interface, they would have been safe as it would have been unreachable.
These are all design time considerations, one that is ultra important … even when you design a low value application.
If ANY of these had been followed, they would have been safe.
If ANY of these had been followed, they would have been safe.
In general, we know and have documented the solutions to these ultra common issues. Here’s my rule of thumb – if you design insecurely, you WILL be broken into. Security Architecture is a MUST.