cat slave diary

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.

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.

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.