cat slave diary

Blog

  • Automated detection of CSRF

    I’ve been finishing the OWASP Top 10. One of the things I profess I know little about is automated tools. Up until recently, they’ve created more work (false positives, false negatives) than is actually justified in running the tool. However, they are getting better.

    After discussions with Jeremiah Grossman of White Hat Security and WASC fame, I was a little surprised to find that none of the tools can detect CSRF vulnerabilities. This is doubly surprising in that of all the attacks, this one is tractable given a flexible enough engine.

    The basic game plan is this:

    a) Watch an action take place
    b) Determine what changed so you can create a signature of the attack
    c) Create a pre-canned request from (a) but add in your CSRF locator strings
    d) Go.

    Now, how to exploit the CSRF? It will need something like a eggshell site of pre-canned CSRF attack payloads. Most CSRF attacks start with a XSS, so the game plan has to be … find a XSS and insert the eggshell in there. This is not hard, just requires that the victim browser has access to the eggshell site, or the CSRF attack is small enough to be self contained by the hosting site itself (as in the Samy worm).

    However, it is fun to read professionals dismissing the potential of CSRF. This list either shows ignorance about how many apps work, or worse, ignorance of how you can easily submit a form from a GET request, creating a POST request. All it requires is sufficient payload space to include a link to a vulnerable reflected or persistent XSS to start obviating the HTML stream. Once that’s done, CSRF is all but in the can.

    Interesting. We need to do more, not less CSRF promotion in our camp. However, on the other hand, our defenses are woeful, so maybe leaving it in a less than well understood state is a good idea. Hard to say. What do you think?

  • Toyota takes over #1 car maker spot

    GM has held this position since 1931, but now Toyota will be #1 for some considerable time to come.

    Story here (New York Times)

    Why? Toyota produces cars that folks want. A few years ago, they produced dull as dishwater boring cars, or even outright ugly cars (think the Echo sedan – FUGLY! I’m an ex-Echo *hatch* owner and even I think the sedan version is awful), but they were exactly what folks want from cars – utterly reliable, frugal enough, and safe.

    GM was “safe” as long as it produced cars roughly equivalent. Dull. Increasingly reliable. But not particularly frugal. And they lost sight of the ball. They worried more about Toyota than their customers. They forgot about their own history and their golden years – the 1950’s.

    Toyota got a clue a few years ago, and started injecting all of its models with design, something GM pioneered with its Art and Color (=Design) area. So although Toyota’s current design philosophy (L-Finesse) probably offends the 55+ sedan owner who buys a car once every 20 years, they actually don’t matter. They don’t buy enough cars, and they literally die off. Why target this market at all?

    The car magazines here are bemoaning this change left, right and center, trying to figure out who is to “blame”. Well, the consumer is to blame. They stopped taking the car magazines’ advice when the magazines stopped advocating for the average consumer. Not everyone can afford 911’s or a Nobel M12, no matter how driver focussed these cars have become. They are simply impractical.

    Look on the roads – you’ll find SUVs, MPVs and sedans, and in more European style markets, hatches, larger hatches masquerading as MPVs, and the occasional “executive” car like the BMW 3 series, which form the remnants of the sedan market (sedans are almost dead over there as they are so impractical and inflexible. I’ve worked out most of the SUVs sold here are basically super dooper hatches – they are the same shape, just much larger on the outside. Most of the SUVs here have such rustic and soft suspension, two wheel drive, compromised tyres that they are not any better at offroading than our Golf.)

    What you don’t find in people’s driveways are 911’s, Ariel Atoms or Nobel M12’s. The Emperors have no clothes – they have abandoned the consumer, so the consumer goes and makes choices that best reflect their upwardly mobile aspirations, budget and safety. Thus they have bought Toyota’s and Lexus’s. And they bought lots of them. The Australian car mags, which are actually some of the best I’ve read (I read Car, Automobile, Wheels, Motor, Motor Trends, Car and Driver, and Top Gear), diss Toyota continuously. They rarely review Toyota, and when they do, they hate it. Yet, Toyota has been #1 in Australia for many years. The buying public have better collective wisdom than the onomastic wannabe race boys at the mags. No surprise there.

    Car magazines need to pull their finger out of their collective rectums and figure out who buys cars, and write at least a few non-token stories about them. If they want to make changes in cars they hate, they have to review them properly against the likely use. There’s no point in saying things like “The Mercedes Sprinter FedEx truck sucked on the track and had a terrible 0-60 time”, or “This MPV could not sustain more than 0.6 g and took out a bunch of cones at 110 mph”. That’s not how those cars will be used. Don’t review them as if the world is a racetrack. It’s not. Hire a soccer mom who knows a thing or two about cars, and train her what makes a good car and what makes a good car story. Get her to review the family cars as if she was looking to buy one. Road test them with kids and stuff. Hire a skivvy wearing Apple owner to review “Prestige” Euro cars and wannabes like Volvos and Saabs. Teach them what dynamics are and how to not get sucked in by appearances, maybe by letting them have long term loaners. Give an Audi A3 or New Beetle convertible to someone for six months and they will quickly learn good looks does not maketh a reliable car. Don’t let wannabe race car drivers anywhere near family cars and hatches. Make the dark age petrol heads realize that cubic capacity is not everything by only allowing them to take home a MX5 when they’re not reviewing another car. Only allow one single BMW in the long term carpark per year, and give it to the production staff to review. And everyone should have to take the “econobox” cheapy for a week or so to how the rest of us live.

    So what happened in the USA with Toyota? Well, design happened. The new Camry is not a bad looker for a sedan. Certainly a lot better looking than the predecessor Avalon / Camry / E300. The Prius is good looking no matter which way you look at it. The new Echo hatch is pretty good (sedan still fugly). The RAV4 definitely talks to its market even if I don’t like it. Lexus IS looks better than the 3 series and is better value. The trucks they sell here are polarizing – not slab sided, but beefy, which suits the “built like a brick shithouse” crowd who buys them (again trucks are not my thing). So by incorporating best of breed reliability, pretty good fuel economy (compared to their competitors), and now design, Toyota will be #1 for some time to come.

    I’ve had the misfortune to hire a few Chevy Malibu’s recently. They suck. I had one with 270 miles on the clock and it still had the new car smell. It had a gargantuan turning circle – like a first generation front drive, and then wandered around the road a bit under torque steer, and even minor inputs. It drank like a thirsty pig and wasn’t particularly fast. I had the hatch as I like hatches, but GM missed the point of hatches – lots of room. The Malibu hatch is a fast back. All the disadvantages of a sedan – limited cargo space, plus incredibly hot if left in the sun. GM is not going to win the war with this car. They need to scrap it and pick up their Euro cars and Americanize them. Which means make a sedan version which is not fugly. And that’s hard. May be it is time to wean Americans off sedans. Nah, not going to happen whilst those 55+ folks are considered and the lowest common denominator focus groups exist.

    For the next 10 or so years, GM has lost the crown to Toyota. At least. Unless they start calling their design group “Art and Design” again and let the designers release cars which have NOT been through millions of consumer focus groups, but allow the designers to have their way, GM will continue to release cars few want.

    If the lowest common denominator wins, everyone loses. There’s enough brands, designs and cars to suit every taste. There’s no reason to say “well, the Mini only sold 700,000 thus was a failure”. The Mini stands out like dog’s balls. And that’s fantastic. Would I have one? Yes. Would Tanya’s parents? Unlikely, but not all the cars need to be a Mini.

    GM also has to stop producing fuel hungry crappy cars like the Malibu and pretty much the rest of their range. Toyota has not ever bothered to make a fuel hungry car and called it a “feature”. Although we think fuel supplies are expensive now, this will probably be nothing compared to 20 or 30 year’s time. Not thinking ahead to those times will kill GM. There should be a concerted effort to move to cars which move with adequate pace but use a lot less fuel. Not even a V8 owning monster truck driver likes paying ze big bucks to the oil companies. It’s time GM started to wean their cars off the juice, whilst not overly reducing performance, or even enhancing it.

    Car Magazines will continue to sell dreams, but they have to fix their game too. They are responsible for ignoring the consumer and letting them buy any old crap through the absence of any real information on the majority of models on the market today. Luckily, despite this, consumers ended up buying well. Typically not dynamically enjoyable cars – but how would the consumer know? The magazines and web sites never told them as they’re too precious to dilute their “hard” wannabe race driver image sullied by reviewing a normal car. Now, imagine if Toyota made a car which was reliable, cheap to buy and run, safe, good looking AND dynamically capable? No other car maker would be able to compete. That is the car journalists’ collective fault and they will continue to suck whilst they forget their first and foremost duty – to their customers. No other media form is as narrow minded as a BMW-loving wannabe race driver.

    A car should be something *worth* owning. A car is either the most expensive or second most expensive thing most folks have, and it should reflect them and honor their choice. This is why buying a soulless car is soul destroying – you’d never buy a house which is not you. You’d never wear clothes that don’t suit you. Why do folks feel they have no real reason to buy a car which reflects them? As Barney would say “SUIT UP!” If you’re going to do this thing, do it right. Don’t buy that slab sided monstrosity. Buy the Hugo Boss of cars, tailored for you.

  • On CSRF

    Many folks are failing to understand CSRF properly, and how to protect against it.

    Let’s do this from the beginning and look at what works, and why.

    CSRF diagram

    Click for full size version.

    Cross-site request forgeries are simple at heart; force the victim to use the victim’s session and credentials to perform authorized work. This almost always uses XSS as the injection path, and can take the form of a hybrid attack, stored or reflected XSS, or a pure DOM attack (including remote script to take over the page).

    Typically, a simple CSRF might look like this:

    <img src=”logout.php”>

    If the application has a logout.php, including a URL will force the victim’s browser to load logout.php. As per normal, the user’s credentials (the session) is sent with the request to logout.php. If logout.php is not CSRF aware, it will log out the user.

    This is simple DoS attack. However, imagine if you could do this for Internet Banking, forcing the user to transfer money from their account to a nominated attack account or via a wire transfer service. Unfortunately, this attack is present in every application with a XSS problem, which means > 90% certainty the apps you use have CSRF issues.

    What can be done, and what doesn’t work and why

    The first thing to realize is to look at the diagram above. Anything in the red box is 0wned by the attacker if they have access to run their script on your user’s browsers. This includes:

    a) session (with its implied credentials)
    b) credentials (if any, such as Basic auth or NTLM auth)
    c) random tokens
    d) the entire DOM (i.e. all aspects of the page’s look n feel, as well as how it interacts with your server).

    Now there are some good ideas to prevent what I call “no click” attacks. These are like the example above – just by viewing a page, the attacker forces the victim to perform their actions. In order of usefulness:

    Move from GET to POST

    This is in the HTTP RFC – any request that *alters* the state of the application (such as transferring money, logging folks out, etc), SHOULD be done via verbs other than GET. In our case, we choose to use POST as it’s simple. This raises the bar … a little. Anyone who can code basic JavaScript can get around this.

    Add a random token to the request

    This scheme is simple: add a nonce hidden field to the form, and check that the nonce is the same on the server upon return. You know what? This will defeat all no click attacks, but will not block advanced hybrid attacks, like the Samy worm.

    This approach is done by most anti-CSRF tools out there today, including the CSRF Guard from OWASP. It works… against script kiddies.

    Add the session ID to the request

    On the surface, this is even simpler than the previous example, and attempts to provide check that the session identifier is sent with the request, thus preventing simple e-mail attacks. However, this misses the point – the victim’s browser sends the request, thus including the credentials. So this is a false mechanism – you’re just repeating what the web server does to associate you with your session, and therefore, this mechanism is not a valid or viable method of protecting against CSRF.

    Ask the user for a confirmation that they want to do the action

    Many CSRF attacks send one request and will fail if there is a second page asking for confirmation. Guess what – this does not prevent scripted CSRF. Samy worm broke new ground in many different ways – it did a multi-page submit process to make a million folks their hero. But this approach is nearing the correct solution.

    Ask the user for their password

    In this scenario, the attacker should not know the user’s password, so we’re moving towards the correct solution for CSRF as it’s out of band thus not knowable in an automated way.

    However, anyone who has been phished or knows what phishing does will realize straight away why this does not work – not only has the attacker full control of the DOM, they can re-write the page any way they wish, including intercepting forms by changing the submit function, intercepting data sent to the server, and they can pop up their own dialog to authenticate their request. Something along the lines of “I’m sorry, your password didn’t work. Please try again”.

    SMS authentication

    In this scenario, for our high value transactions, you may wish to consider using SMS based two factor authentication. What happens is that the user will get a random code with explanatory text, like this:

    “The code is WHYX43 to authorize transferring $2000 to account 23214343 (“My checking account”). If you did not initiate this transfer, please call 1-888-EXAMPLE.”

    This takes the app out of the left hand red box to a second red box. Sure, you don’t control this new red box, but to attack this scenario, the attacker must:

    a) Attack the application successfully and run their script
    b) Be available when the user logs on to the application
    c) Attack the telco’s SMS infrastructure such as to intercept the token to re-write the message or redirect the token at the right time
    d) Ensure the user cannot reverse the transaction because they would most likely receive the SMS or if they didn’t they would be expecting to get a new code which may invalidate the attack token.

    This confluence of attacks is not easy. It requires too much, and I personally believe for its cost, this solution cannot be beaten. It doesn’t make it impossible, just really really hard.

    Two factor transaction signing

    Bring on the big boys. This is how two factor authentication should have been done: authenticate the transaction / value, not the user.

    In this scenario, the attacker would have to convince the user to type in a sequence of steps, most likely including the value of the transaction and return a code to the attacker. Phishers are clever, but not clever enough in this case.

    I really think that for the highest value systems, two factor transaction signing is the way to go.

    Sequencing

    This is a counter-measure that I discovered by accident when reviewing a Spring Web Flow app a little while ago. By mixing up SWF’s flow mechanism, we can create really hard to obviate applications.

    The approach is this:

    Application has a range of functions on a page which perform actions. Each action has a special flow ID, flow step, and random nonce mixed in and calculable from the the server only.

    So if you want to create a link to go somewhere, you do it like this:

    myUrl = createURL(FLOWID, FLOWSTEP, someRandomFn());
    or
    myUrl = createFormAction(FLOWID, FLOWSTEP, someRandomFn());

    It would create a special link, or a post action. When a user views a page, only those links or form actions are permissable. Therefore, a hostile attacker wishing to go from page x to a goal function g’ simply can’t without that goal function being reachable by x. This means that by introducing the concept of landing pages and confirmation pages for special functions like logout or change profile, you can only do so whilst in the midst of that flow.

    Attackers would have to inspect the current URLs to determine where they are and this is not easy if the location is somewhat randomized or commonalized (typical of MVC apps, which have a single entry point).

    This could be taken to the next level, forcing the client to perform public key crypto to calculate the correct response token by signing where they want to go like this:

    rsToken = sign(serverPublicKey, destination Flow ID, Flow Step);

    The server could then determine if the response was calculated by one of its clients, rather than one of the hordes of attack zombies. If the server then eliminated all previous steps as a potential flow source, it would immediately block out the user, or the attacker, and thus make the attack detectable.

    This makes it much harder for a hostile DOM / attacker to move you directly to their goal function g’ and thus make the attack delayed, diminished, or at worst detectable. As most attackers are only out for a good time, this may be enough for them to move on to another application which is easier to attack.

    However, as it requires re-jigging all applications, and we can’t eliminate XSS in the current set of applications today, I doubt this approach will work outside those who are prepared to try.

    Administrative attacks

    One of the things that has got my goat up for a while now is why application authors insist on mixing up user and admin privileges in one application. CSRF just makes a very silly non-compliance issue a really stupid and foolish mistake.

    Administrators by their very nature use the app a lot more than most users. They have more privileges than your average bear. Attackers using CSRF would be silly not to attack the administrative users of the application.

    So… what does this mean?

    SOX (I’ll get to this), COBIT, ISO 17799 and a host of other compliance regimes all mandate that users are not administrators. Make it so. Get the administrative functions out of your app today and into their own app. Force the admins to use a different credential. If the admins view user created content, they are still at some risk of CSRF attack, so make sure those pages have the highest levels of anti-XSS and CSRF protection.

    SOX is simple and often misused to get unwilling business folks to (at worst) spend big on IT’s latest geegaws or (at best) to fund chronically underfunded security budgets. In any case, the basics are this: your app, if it pertains to the financial underpinnings of your business, must have anti-fraud controls. This essentially boils down to initiator / approver model. If one person is allowed to create an order for $100 million, that same person shouldn’t also be allowed to authorize it. In a perfect world, neither of the two roles mentioned so far wouldn’t receive the order. Fraud thrives when one person can do all three things. So if you have users that can create all three roles, then that user MUST NOT be able to use the application, and that user MUST be extremely heavily audited. Such admins are not users … by law. I hate reviewing such cretinous mistakes, so please fix it. This fixes the CSRF issue as the admins are unlikely to CSRF attack themselves.

    In the real world

    The problem is that most applications are not high value transaction based systems. They’re forums, blogs, social networking sites, book selling sites, auction sites, etc. What about them?

    They should be eliminating XSS in their apps as a matter of priority – XSS is the buffer overflow of the web app world. They need to stop using GET immediately. They should be using random tokens.

    These simple methods of stops most simple CSRF. Adding additional protection will provide additional protection – but every application is different. If you need more, add more, but always consider usability. Forcing users to use a two factor authentication device for every page view is impractical and foolish. Choose wisely by protecting only your sensitive functions from abuse.

  • USA: First three and a bit months

    Gary predicted I wouldn’t last three months, and yet here I am. However, my health has taken a bit of a beating and Tanya hasn’t been the most healthy.

    The funny thing is that when you live elsewhere you have the impression from the meejia that all Americans are fat. I’ve been to Cleveland, OH, Pittsburgh, PA, Miami, FL, a little place about 30 miles outside of Philadelphia, Washington DC, and obviously here in Columbia. There are very few fat Americans. I am usually the largest sphere of influence at geek meetings. In fact, most of the folks in my company are fitness freaks and play a game called 3 coin to make the “winner” do flights of stairs as a reward/punishment. So much for the usual stereotypes of fat slothful folks. I was sort of hoping that I would be able to find clothes that better fit me as more folks needed them, but I’m still having to buy from big and tall shops. Luckily, one of my bosses is a gentle giant from the sky, and he put me onto where I can find the bigger stuff at one of the local malls.

    The lack of fat folks is a miracle as the food is totally yummy, totally huge, and so, so wrong. I’ve gained 4 kg and high blood pressure, taking me to a new category of bad overweight. I don’t know how folks maintain their svelte appearance if they eat like me, and most seem to. One thing I have noticed is that they have great salads. Maybe I should eat those instead of the double heart attack on a plate.

    My doctor sort of yelled at me for being so unhealthy and so we agreed that I would try to lose some of the weight. The problem is that Tanya is so unwell most of the time, and what she can keep down, is not necessarily good for me. Plus, when I come home from a long day at work, if Tanya is too unwell to cook, I really don’t feel like doing it. We have to break the pattern soon, or else my doctor will yet at me some more. I was referred to a ENT specialist to deal with the dizzy spells I’ve been having, and luckily, the beta blocker heart pills (I call them my “dried frog pills”) seem to have capped that sucker. However, I was worried about hearing loss and so they tested me. I was really surprised to find that I still have all of my hearing. I don’t think I do; I find it really amazingly hard to understand folks in noisy environments, and it was made worse by the dizziness spells. However, the hearing test was nothing if not thorough and they basically declared me to have “perfect” hearing, which is extremely unusual for adults over 25. Damn my perfect hearing.

    The USA is an intriguing mix of up to the minute technology and ancient conservatism. The banking system is in the dark ages. We had to get a cheque book. I’ve never really had one before. We had to ask what to fill in the blanks as we simply didn’t know. Online banking is a joke. It’s like they heard about it from someone who went on a trip overseas, and then forgot all the important details. Not only can our Internet Banking not see what transactions are in play at the moment, most of the transactions take days or sometimes a week or more to resolve themselves. Yet if you go to an ATM and get a mini-statement, it is mostly accurate. The anti-phishing controls are like it was like in 1999 in Australia – i.e. none. There’s no real security – the URL changes to somewhere completely different than you typed and the lack of features would have made a small cash strapped bush credit union back in the mid 1990’s blush. Our bank? Citibank. Most folks are completely wary of electronic transfers, and it’s no wonder. The online banking system is crap and needs a good competitor to come in and shake up the moribund bankers here with a few modern features like, ooh I don’t know, electronic bill payment. Yes, we’re paying our electricity bill by cheque because they complain when we ring up to pay via credit card, and we can’t do it from the online banking system.

    Many places are able to take credit cards now, but we cannot pay the rent by credit card or electronic means. Don’t even bother trying to get in a cab with a credit card – they only take cash. Even the ones who say they take visa on the window. They’re lying. It’s a total crapshoot if the place is totally modern taking contactless payments or if they are still in the dark ages requiring cash on the barrel. Even places with EFTPOS don’t always take debit cards. I was in a hotel suite not long ago that would have refused my good money if I didn’t already have a standing authorization from work. And yet, we order our pizza and Indian food online and pay via credit card.

    Winter was fun. Never really had much to do with seasons before, and so going outside when it was well below freezing (say -20 C) took my breath away. Literally. Snow was fun for about the first three days… until we got stuck in 20-30 cm of snow and had to spend the day at home chilling out until they plowed and salted the roads. Then spring came with a bang. One day it was like snowing and around zero. Then the very next week it’s like 25 C and the snow is melting. We had one little storm which dumped a bit more snow, but now it’s pretty mild. Most days are high teens low 20’s and it’s starting to get humid. I hope it’s not too humid here during summer. I hear it is. We’ll see – maybe like a frog in increasingly hot water I’ll get used to it.

    I am starting to get a bit jaded by the tipping. For those who don’t know, in Australia we pay our serving staff reasonable living wages, so tipping is entirely voluntary and is usually only given for superlative service, particularly in the posher restaurants. Here, because they pay absolutely appalling wages (one serving lady told me $2.95 per hour at our favorite diner), they live on the tips. So why isn’t the food cheaper at most places? They’re not paying their staff, which has to be one of the biggest costs. I’ve come to expect $30-$40 bills (About $50-60 AUD) for simple lunch for me and Tanya, something that will cost in Australia no more than $AUD20-25 for a much higher quality meal.

    However, saying that, serving staff are generally extremely polite and helpful. Australians do not make good serving staff as we expect to be treated like humans no matter what. I like that. However, getting stuff I want is also nice.

    Driving on the roads here is a load of fun. There’s no speed cameras (yet), and although the surface of the roads make some of Sydney’s roads look like F1 race tracks, everyone speeds here. Usually 10-15 mph (a good 20-30 km/h) above the speed limit. The local freeways are 55 mph (88 km/h). If you don’t do 65, you’re going to get nailed by big ass trucks. The cars usually do 65-70, and a bit more in the left lane. I don’t mind speeding, but sometimes these folks are nuts. It was hailing cats and dogs the other day, and I was still tailgated by a moron in a large SUV.

    The SUV is king here. And they’re bigger and more numerous than you’d expect. The lady next door has a truck which could fit in an entire kindergarten of kids in its massive flatbed, but she only has a small Chihuahua (which suffers from insane tiny barky dog syndrome), and as far as I can tell, she doesn’t garden or go off the road. This is pretty typical. I’m glad we bought something that weighs nearly 1400 kg as if we’d gone with the 1200 kg Jazz/Fit, we’d probably be flattened by now.

    Our car is going well, even if it’s drinking like a V8 and putting out like a lethargic 4 cylinder. The old VW 2.0 was derisively called 2.slow by many folks. VW made this I5 engine specifically for the US market and it’s crap. My old 1.8t NB would have caned this engine’s arse. The engine just doesn’t feel like 110 kW or one half the engine of a Gallardo’s (to which is apparently related). I would have preferred the current 2.0 TDI found in Australia and Europe, but it’s not coming to the USA until next year, and may be not at all for the Golf/Rabbit. The 2.0 TDI absolutely canes this engine. It’s faster, quieter, much more economical (easily 40 mpg instead the 15 or 16 mpg (about 15 l/100km) we’re getting now) and it cruises the highway with authority due to its immense torque. The I5 just has a fabulous noise when you press the loud pedal. Oh well. This is the car we have, and we’ll have to live with it.

    We’re going for our driver’s license soon. One thing we have noticed is just how long it can take to do basic things. It took us three trips and over four hours to open a bank account. Beyond providing additional paperwork, this is unbelievable. Laura took nearly 6 and a half hours to get her license. I’ll let you all know how we went soon.

    We’re suffering from a series of break-ins at the moment. Some thieves are targeting this complex, stealing car parts to order. Last night, all the Civics lost their airbags. Last week, it was SUVs and tires. They stole all four wheels from the SUV right outside our window, leaving it on Pepsi crates. The Pepsi crates couldn’t hold up so much truck, and so by the end of the first day, the truck was resting its weight on the disk brakes. The bastards doing this had better watch out – most of the folks who live here are military types and are pretty buff. I personally wouldn’t want to cross paths with them. We’re pretty spooked at the moment, and we’re taking photos of suspicious activities. Hopefully, the police will catch them before some of my neighbors do.

    On the positive side, work is great. The guys are a cut above anyone I’ve worked with before in terms of web app security. For the first time, I’m not the only one who knows what they’re talking about and in fact, I may not be at the top end of the curve. They’re also really understanding of our little health crises. Jeff’s wife, Jen, is encouraging Tanya to get pregnant. Jeff – you need to watch out man, Jen wants another one. 🙂

    We looked after Jeff and Jen’s elderly dog, Daisy for a month whilst they were on holidays. Daisy is such a cutie; she wasn’t a burden to look after her at all and I know Tanya loved the company. I know I miss her snuffling and snoring, and the way she lies on our feet when we were watching TV. I know Daisy made Tanya pine for her boys back in Australia. Tanya is looking into volunteering at the animal shelters. I wouldn’t be surprised if we end up as a temporary adoption center ourselves, particularly if the rescued dogs look white and fluffy.

    Lastly, the travel to all these great places has been wonderful. Next week, I’m in Miami again, and after that I’m in NYC for a day. Awesome. More photos will appear shortly.

  • Appearing at PHP Columbia tonight

    Come one, come all. RSVP here:

    http://php.meetup.com/372/

    I will be making a pretty cool announcement. 🙂 More tomorrow.

  • On injections

    A fair number of years ago, I had the “pleasure” of reviewing an application written in ASP. Unfortunately, it had over 2000 SQL injections. I do not know what happened to the company, which produced legal case management software, but it would have taken a great deal of work to re-engineer the code to be safe. Why then, some six years later are injections still all the rage?

    Injections, are to put it in the simplest possible terms, are the simple result of intermingling instructions with potentially hostile user supplied data. This paradigm, although powerful, has failed. As Dr Phil says, “how’s that working for ya?”

    So we have to move on. Luckily, this post is not all bad.

    HTML injections

    It’s becoming increasingly hard to ensure that output is properly encoded, especially as I18N becomes more popular. Will encoding data to be XSS safe be viewable to non-US readers? Hard to say. I’ve been working with Benjamin Field (or more precisely, I farmed out) the re-implementing the Microsoft AntiXSS library API to PHP. This is nearly done. Once it is ready, we’ll make it available.

    However, I’m still worried as it’s not the simplest, default way to output. When the simplest way to output is wrong from a security stand point, mistakes will be made.

    SQL injections

    Seriously, we have the technology to stop these today. Both strongly typed parameterized queries (a.k.a bound statements) and most forms of ORMs and Active Record systems are SQL injection resistant. Stored procedures are mostly safe, but are at risk if a certain lack of care is demonstrated.

    LDAP injections

    Want to be someone else? It’s easy today. This is the great unexploited attack vector for *serious* applications. Toy apps don’t use LDAP, so most researchers do not concentrate on it. But you betchya that most large orgs and govt types have signed up for the “SSO magic bullet” and landed themselves with a LDAP shaped white elephant. They may not be even aware that they are running LDAP. It’s certainly not made clear in many of the marketing materials. How do architects who have never coded understand the risks?

    Today’s LDAP code are eerily reminiscent of the SQL days of yore. Here’s a typical LDAP login method (I have worse, but for this I’ve borrowed from php.net’s manual page):


    $ds = ldap_connect($ldaphost, $ldapport) or die(“Could not connect to $ldaphost”);

    if ($ds) {
    $username = “some_user”;
    $upasswd = “secret”;
    $binddn = “uid=$username,ou=people,dc=yourdomain,dc=com”;
    $ldapbind = ldap_bind($ds, $binddn, $upasswd);

    if ($ldapbind) {
    print “Congratulations! $username is authenticated.”;
    }
    else {
    print “Nice try, kid. Better luck next time!”;}
    }

    Yes, not only can you choose your location within the ldap tree, you can also do XSS if you’re clever.

    XML

    Don’t even get me started. Creating uninjectable XML functionality is a PhD in itself, and once it’s done, I doubt the resulting XML would be anywhere near as useful as it is today.

    Injections will continue to occur to why the USA still has pennies and $1 bills: they didn’t remove the old form from circulation. This is the only solution: ensure the safer solution is available by default (and is the easiest method to use), and remove the old unsafe methods. Make it HARD or IMPOSSIBLE to do it badly.

  • Patently evil

    Mark Curphey, a really smart guy I respect for his work founding OWASP and creating the first edition of the Guide, lost a goodly percentage of my respect today:

    I did some patent review work in Dallas recently. I traded my security consulting time to a company who in return provided their legal firms time for my patents. I have been living and breathing patent strategies for the last few weeks.

    One of our advisors sent me back comments to a provisional “elevator pitch” I put together. As always brilliant feedback and very valuable suggestions. Surround yourself with brilliant people and its hard to fail!

    As a customer of many companies, the thing I worry about the least is whether they’ve spent effort on things which add no value to me. I worry extensively about small companies that invest valuable time and money on worthless pursuits, such as patents or marketing when there’s no products to be had. Of course, this list is missing the vast majority of the real wasters.

    There is no point in investing in or buying into any company who burns valuable startup resources on worthless evil patents. Focus on beating your competition by simply being better than them or offering a unique service… and then do it again a little later so your competition still has to catch you. The world does not owe you a 17 year license to sit on your arse, milk consumers and stifle competition.

    Patents are evil on so many fronts, it’s hard to list them all. Here’s some that come to mind:

    • Money is wasted on patent lawyers. Patent lawyers are a pestilence on society. Sorry, Jeff, but I’m so glad you got out of that game
    • Patents add no value to the economy of ideas or the general economy. They produce no value to a nation’s GDP, but hold back competition and a natural market’s growth
    • Patents are an anticompetitive weapon to squish competition who came up with fundamentally the same idea as you but foolishly or bravely chose not to patent the patently obvious
    • Patents are not assets until they earn income by squishing the competition or milking other companies for licensing fees, milking the consumer or pure extortion cos they have no choice but to buy from a limited, stifled market. Patent battles are only useful after point (1) has wasted a six figure to seven figure sum for your average fight on worthless patent lawyers and mucky court battles.
    • Sooner or later, all the patentable ideas will have been patented (many patents already significantly overlap), and it’s just who has the most serious patent lawyers and deepest pockets who can dictate who can innovate or provide services.

    This is wrong. Imagine how many schools and hospitals could be built in third world countries for the value of the patent battles and licensing fees in the Valley alone. Patents are an insufferable evilness and must not be allowed to pass.

    Mark, there’s no point in trying to ensure you don’t fail, you’ve already failed for being the latest sucker to take the poisoned patent chalice. You founded OWASP on the basis of openness and inclusion in an industry notorious for its secretive and proprietary ways. Reconsider before joining the dark side.

  • Top 10 2007 is done

    The document is a complete re-write from scratch, and is totally up to date. It’s 34 pages of goodness wrapped in a shiny new document format. Essentially it’s over all bar the shouting… which comes next! 🙂

    The document will be uploaded to our Wiki in the next week (post-board approval). If you want your review points or changes to be included, you will need to be on the Top 10 mail list to make the suggestions or changes. To join the OWASP Top 10 mail list (it’s free!), go here:

    OWASP Top 10 Mail man interface

    I am particularly interested in hearing from people in the

    • PCI DSS arena
    • Department of Homeland Security
    • NIST
    • – Your nation’s equivalent of the above two if you are outside of the USA
    • If your organization has previously adopted the OWASP Top 10 2004
    • Vendors in the WAF, automated code review, and other automated tool arena (yes, we finally discuss if these automated controls are likely to work, but as we don’t know about every product, the more advice we can get the better)
    • Frameworks, particularly the PHP team, J2EE / Struts / JSF / Hibernate / Sun / BEA, JBoss, etc, and of course Microsoft’s folks in the .NET team

    The last two bullet points are REALLY important as we make some stringent suggestions about how best to code to avoid the Top 10 weaknesses and we want to ensure that it really is the best advice. If you can’t be seen contributing publicly, feel free to e-mail me… vanderaj (at) owasp.org.

    UPDATE >> Here it is!

    http://www.owasp.org/index.php/Top_10_2007

    Andrew

  • The usual suspects and what to do about them

    I’ve been busy on the Top 10 2007 with Dave Wichers and Jeff Williams. I’m very close to finalizing a draft release right now. This process made me think, how can we eliminate these issues? Why should every developer have to learn how to fix the same problem? We know On some frameworks, some classes of application programming error are history. Obviously, we’re not going to be able to fix business process or logic issues, but I’d prefer people working on that than wasting time searching mountains of code looking for every last vulnerability.

    So over the next week or so, whilst I’m traveling and theoretically have more time (i.e. less TiVo!), I’ll pump out what’s wrong with the current model, and propose how it might be fixed. Permanently.

    Some of my recommendations will be hard to swallow, but the alternative (“same old, same old”) has failed, and failed miserably for years. It’s time for something new, or in the case where it works real well on another framework, let’s adopt their ideas and maybe even improve on it a bit. Up first is our old friend XSS.

    XSS

    xss-table001.png

    The table shows just how wrong the old way (PHP) is. I made the number up in the difficulty column, arbitrarily setting it to 10 / 10 for the weakest solution, and then thinking carefully about what would be required in the other platforms to come to the same desired point: a safe application. In this round, J2EE using any of of the common presentation layers wins hands down. Sure, you can do bad things in J2EE and .NET, but the important thing is that it is not the default. You have to work at being insecure. But when you need to be, those frameworks allow you to be as insecure as the next guy.

    Given the likelihood that a PHP developer is no better or worse than a J2EE or .NET developer, the PHP application requires more care and thought to get right. This means, in the entire universe of webapps (regardless of language), a larger percentage of PHP applications will have XSS issues than other frameworks.

    What’s needed to get it right?

    With PHP, there’s no real solution other than … a very ballsy decision to make PHP 6 XSS safe by default. PHP 6 is Unicode. Let’s make the Unicode output functions XSS safe by default, and output a E_STRICT warning when apps use print or echo. Obviously, there will need to be a way to output HTML dynamically, but this is the corner case, not the default. Let’s make the devs who need REAL html do the hard work, rather than make all devs do the hardwork, everywhere.

    With .NET, all controls need to be XSS safe by default and have an encoding property, and it should be set to true by default. Enough are properly done right now to protect the usual newbie programmer, but it’s wrong to assume that even advanced devs will remember to encode everything. Where a value is stuck into a field that is likely to be displayed without encoding, a warning should show in the debugger.

    With J2EE, the java compilation step should issue a warning when the old style <%= … %> is used un-nested. <%= … %> is required to put values into messages and bean:write to do useful work. But if it’s just on its lonesome, that’s XSS right there.

    Tomorrow: Injections…

  • Research time

    A few weeks ago, the announcement of the PDF hole made it clear that the age of stupid XSS vulnerabilities is still with us. Is it time for me to surf in a read only sandbox? XSS is so old school, and yet so damaging. It is so SIMPLE to prevent, but so HARD to stamp out. I was disheartened.

    But then today rolled around.

    We had a board meeting tonight and I’m excited with what we have planned, and it’s re-invigorated me tremendously. It’s a very exciting time to be in the midst of the OWASP community right now.

    I hereby declare 2007 the year of pro-active webappsec research. Not looking for or researching new vulnerabilities, but researching and developing long term effective methods to close down common holes which plague browsers and common frameworks. It’s time to kick XSS, CSRF, injections of all types in the slats and make it impossible for folks to say “well, I didn’t know” or “that’s too hard / costly / time consuming”.

    We have a range of projects we’re doing this year, and I will make it my task to ensure that OWASP builds the knowledge, tools, patches, and so on to eliminate wide swathes of wepappsec retrobugs. Let’s see how I go in 345 days or so.