cat slave diary

I’ve been busy over the weekend.

I met with Blake Turrentine at a diner near where I live. We had a good long discussion over breakfast on the future of the Guide 3.0.

The Guide 3.0 will be about how to design apps and code securely. That’s it. Only positive controls will be discussed unless the negative controls rule right now. For example, the Services “Databases” section will contain only the following sub-sections: Best practices (use an extremely low privilege account unique to your app, use an encrypted connection, store the connection credential securely, etc), Active Record / ORM, prepared statements, stored procedures.

The pattern in each sub-section will most likely be:

• What to do right
• Risk level of this control (All, Low, Medium or High risk apps)
• Why this works (using ESAPI if it’s got something to say about this control)
• Code snippets doing it right
• What this prevents (links to the testing or code review guide and any publicly known attacks using this mechanism)

There will be a “Worst Practices” sub-section containing Dynamic queries, and Stored Procedures Gotchas (discussing string concatenation, calling out to native features, and the use of exec, etc). The idea is that if there’s zero noise on bad controls, you’re more likely to do the right things, particularly if there’s supporting code.

It should be nice and short, especially in comparison with the 2.0 version as there will be only links to testing or code review material. There’s no point in repeating that material.

Although pen testing is considered sexy and a little bit naughty by the meejya (and thus “newsworthy” when plainly it is not), coupled those folks who consider themselves hard core l33t haxors get to go to all the nice parties with ladies of negotiable value, I think pen testing is not the best way to deal with crappy paradigms. If you’re still using dynamic queries, you have soooo much work to prove that you’re “safe”, and every few years when a new technique that exploits the root cause comes along, you’re hosed.

However, if you had spent far less time and money to use one of the three “safe” methods above, you’ll be “safe” for most values of “safe”. We have seen zero mechanisms to attack prepared statements in the last eight years. That’s a very successful control. Therefore, testing for SQL injection is sort of pointless and we can move onto the real golden apples, like direct object references and business logic flaws.

The Coding Top 10 will be a distilled version of the same material, but by necessity, it will concentrate only on ten items, instead of may be 200-300 items. Neil Smithline has agreed to take a shot at it, so I need to touch base with him this week.

In both cases, I’m looking for a healthy dose of contributors as there’s no way I could do the amount of out of hours work I put into the OWASP Guide 2.0 again. Tanya would kill me for a start! If you think you can help out, please join the OWASP Guide and Top 10 mail lists, and shout out!

Please don’t do it because you want to be invited to all the sexy parties and have ze ladies fall at your feet, or to get wealthy on the residuals. I will make this prediction right now: neither document will be feted by the press, and neither document will get much traction at the trendy conferences. Even though they will be the best things to help developers and businesses code properly ever written. Let’s make a start and see how things go.

In other news, all my talks for OSCON were rejected again. Why did I bother? I should have paid attention my last year’s rant. Most likely, I will have to give up on submitting papers to certain open source developer’s conferences as honestly, why bother doing the work of doing the research, creating the paper and slides only to be rejected? Luckily, two of my submissions were from colleagues, so I didn’t squander a lot of resources on those talks, even though for example, I’m working on porting ESAPI to PHP, which is the subject of one of the rejected talks.

I’ve identified the following security talks for those security folks still considering going to OSCON (although I’d recommend saving your money for OWASP USA as we already have a schedule of 45 web app sec talks in three tracks, and two full days of tutorials, including several two day courses where you’ve got an actual chance of learning something. Just saying.)

• Securing the PHP environment with phpsecinfo, by Ed Finkler. This should be good - I’ve used it before and it’s a pretty cool way to tie down PHP properly. And Ed has contributed Inspekt to OWASP, and therefore he’s cool by me.
• PHP: Architecture, Scalability and Security, by Rasmus. Rasmus knows what he is talking about, but I don’t know how deep the security aspect will be. Hopefully, enough as it’s a three hour talk.
• PHP Taint Tool: It ain’t a parser, by Luke Wellings, a friend of mine from Australia who now lives with his lovely wife in Columbia MD. I’d love to see this tool in action.
• Hack this App! PHP security workshop, the usual sort of scare the punters talk common in talks at conferences I attended about 5-10 years ago. I really hope there’s some solutions in this one. There’s no point in saying you have a problem unless you have a solution, which is what all three of my submitted talks were. Especially the one on securing PHP apps and ESAPI for Java (although we have a completed .NET and soon a PHP port now)
• Perl Security, three hour talk by Paul Fenwick, also an Australian of my acquaintance
• How to improve quality and security automatically in your open source projects with static analysis, by David Maxwell (Coverity). Hopefully, this is just not a vendor plug, but even if it is … it is about solutions, and I like that.
• Security 2.0: Emerging Trends in Web Application Security, by Chris Shiflett. Also a friend, but sadly, not Australian.

So five talks and two three hour longer talks. Here it is in graphical format for you:

A couple of the talks are likely to not offer that much in the way of solutions. Sadly, no Ruby, Python, administration, database, emerging topics, or people security talks. Worse, there are no Java security talks, which for an semi-incomplete track, I found sort of astounding, especially as I submitted two Java security talks and one PHP talk. The official “security” track has two three hour talks, both detailed above. Even if you look at it from the point of view of OSCON having 16 tracks, hopefully with equal time for all of the tracks assuming there was a lot of competition for speaking slots, there should be 215/16 = ~ 13.4 security talks, not 7.

Although I am glad my friends are accepted whilst talking about security, I think OSCON needs a new program committee. This one is broken.

Jim asked a great question - what is the current state of the nation for HttpOnly? I’m glad he asked!

Pass - read/write cookie protection

• IE 7.0
• Firefox >= 2.0.0.5
• Firefox 3.0 beta
• Camino 1.5.4

Barely Pass - read only cookie protection

• IE 6.0
• Opera 9.50 beta

Fail - no cookie protection

• Safari 3.1
• Firefox < 2.0.0.5
• Opera 9.2.6 (currently shipping stable version)

Coverage of HttpOnly Support

According to my Google Analytics account, 93.6% of browsers support HttpOnly for preventing being read. The worst offender is Apple, with a marketshare of 5.3% on my heavily trafficked site. They have no support whatsoever. In fact, they’ve had a bug outstanding for some time that no one is assigned. BAD APPLE!

Conclusion

Most sites do not use cookies for anything other than the session ID. This is best practice. In these instances, there is NO REASON for them to read or write the cookie using JavaScript. Although there are ways around HttpOnly (some work better than others, depending on your browser), it is worthwhile for frameworks and app server vendors to send this tag automatically. Those very few folks who really need to be pwned should have the ability to turn this protection off.

I’m working (slowly) on porting ESAPI to PHP. This will be great!

So just in case I keep on having a life after hours, Jeff kindly created an ESAPI for PHP project. If you care about PHP security, come help us finish the port. It’s only 3900 lines of code, and I’ve ported like a 1000 of them already.  

Why ESAPI? 

Well, it’s a ready to use secure coding package. The ESAPI library is not about avoiding attacks, it’s about software engineering for web app security. ESAPI deliberately targets around 80% of security features of the average application (whatever your application is!) with the reference implementation, and for that 80% it does security 100% right so you don’t have to.

ESAPI covers nearly the entire OWASP Top 10, and some other issues besides:

• User object*
• Authentication* membership management classes - we have coded createUser, and friends, login, logout (with safe session and cookie termination), disable account, generateStrongPassword, automatic password hashing including salts, etc. 
• Access control*
• Access Reference Maps* - direct to indirect object reference maps. No longer do you need to jump through hoops to protect primary keys, files and other things that people can trivially tamper. Instead of filename=report.pdf, you can now trivially turn this into filename=4fd8Xz
• Encrypted configuration*. No more clear text passwords in config.php
• Encrypted and integrity protected cookies*
• Encrypted and integrity protected hidden fields*
• Hard core encoding utilities*, such as HTML, JSON, XML and LDAP encodings that only do whitelisting
• Easy to use Encryption support … with only access to SHA256 and AES other quality algorithms. No MD5 or DES here.
• Easy to use strong random number support … no more weak random values
• Executor* - safely call the operating system
• Integrated intrusion detection* - security events are automatically generated and logged
• Integrated Logging* - using log4php by default
• CSRF token management* 
• Thresholds* - automatically set rates for certain actions to help prevent brute forcing
• Validation libraries* that help you do white listing by default 
• Test suite to prove coverage and test all functionality 

Things with a star (*) are simply missing from PHP today, which is surprising considering EVERY SINGLE web application MUST have them. This is despite 5698 functions being defined in PHP today.  

If the PHP core folks want to talk about adopting these in PHP by default, OWASP would be more than happy to donate the code and re-license as appropriate. All PHP applications deserve this level of security.

So, please feel free to join us.

My current research is mainframe security as it applies to web applications. This is where the high hanging fruit (the golden apples) lie. If you can

a) fake or bypass authentication
b) fake or bypass authorization
c) spoof logging or otherwise destroy accountability
d) interact directly or indirectly with a deeply nested service of value
e) manipulate data to violate integrity (creation, update or delete)
f) view data (read)

you are most likely to pwn the high hanging fruit. It’s actually amazing to me how LITTLE information is available on securing this stuff, and how often products which are marketed as “enterprise ready” and “secure” are actually not worth running a faulty bidet let alone left in charge of multi-trillion dollar a day roles.

Then there’s the dumb architectures which often use clear text protocols, unauthenticated transfers (often using ftp or worse), batches with no integrity and no accountability controls, and so on. This field is amazing that no one has taken the time to really learn how to do it properly. It is not 1969 any more. The days when the data center was guarded and that’s how the punch cards arrived and the tapes left no longer apply.

However, there’s a few protocols and common transports which need some help first. I’m going to blog on those in the near term future.

In larger organizations, the back end of a web application is a mainframe. The mainframe is the final frontier of application security:

1. Uses a platform few if any in the application security industry know about
2. Those who do know mainframe security rarely interact with the outside
3. IBM trains young devs in how to program COBOL, RPG, or PL/1 for its large institutional clients, but they rarely - if ever - get taught the fundamentals of security, risk management, or even the basic security features of their platform and language
4. Most of the security features of the mainframe’s core languages simply don’t exist. For example, standard COBOL does not support SHA512. It has to call out to do that.

This is a shame as the mainframe is actually a damn fine security platform:

• One authC/authZ framework to rule them all. And it’s actually pretty good.
• A transactional model which is inherently thread safe
• Mandatory access control to data if you desire 
• Logical partitioning of hardware and resources in water tight sandboxes that Dinis Cruz wishes was in .NET (sorry, Dinis, couldn’t resist)
• All modern IBM mainframes come with a hardware security module (HSM, a crypto card which can store keys and do safe crypto processing)
• and on, and on, and on… 

The problem is that most mainframe code does very little to protect itself. The original risk model is a 3270 green screen dumb terminal running in a locked down environment with fairly hardcore presentation layer access control (generally a menu system) being used by trusted staff members who liked their jobs. That same code is now not only well past the age of consent, it’s done the binge drinking thing, grown a goatee, moved out of home, shaved the goatee, and is thinking seriously about starting a family. And suddenly, it’s being hooked up on a blind date with code of negotiable value who likes to party by picking up all the keys in the bucket. Metaphorically speaking. You know where this is going. In a typical web application scenario, we have the following architecture:The usual problems we have here include:Authentication We talk to MQ via… one single connection. So does the database. So what’s the big deal? Well, in many systems, database queries are designed with this in mind. If you don’t, we have direct object reference attacks which result in loss of fine grained authorization. But let’s assume our data architect was clued in, and we see SQL like this:

SELECT * FROM orders WHERE orderID = ... AND userID = ...

or

SELECT * FROM orders WHERE orderID = ... AND roleID in (SALES_ROLE, MANAGER_ROLE, ...)

This prevents the attacker from seeing records which are not owned by the user, or in the latter case within the correct role. Mix and match to suit your requirements.Back the mainframe. We talk to the mainframe through something like MQ or SNA Server. The mainframe is running a piece of code written explicitly for a 3270 or 5250 terminal using menu level security or even better with a proper protection profile from RACF. Back in the day, each of these semi-smart terminals had their own logical address (LU) telling the sys prog who was logged in, where it was, and way more importantly… that a trusted staff member was doing stuff.When exposing mainframe transactions to the enterprise, the industry’s first shot at SOA was the Enterprise Message Bus, later renamed Enterprise Service Bus and lately seen down in the docks sporting the SOA name tag now that we’re doing exactly the same stuff as we were doing in the early 90s … using unreliable web protocols instead of reliable mechanisms like MQ, Biztalk or SNA Server.Next week, we start to see why it’s important to not only impersonate the correct user, but not to give the transaction more privileges than you need. 

I’ve had the manuscript of this book for about two weeks now. I approached this review from the point of view of having had a contract to write an Ajax security book myself, with No Starch Press. I actually approached Billy to see if he wanted to help write my book at Black Hat in 2006, but I never followed through… on either the book or chasing Billy down and getting on with the job. For those who wait, are those who do. Congrats to Billy in chasing down a publisher and getting a good co-author, and most of all - getting it done! Writing books is a hell on the social life, and I can’t imagine how many all-nighters they pulled to get this out the door.

So onto my mini-review.

The Good

Is it just a re-hash of old presentations? No. The book breaks some new ground, and fills in a lot of the blanks in all of our presentations and demos. I hadn’t heard of some of these attacks in book form before. The examples improved my knowledge of DOM and other injections considerably, so there’s something there for the advanced folks as well as the newbies.

I really liked the easy, laid back writing style. Must come from the laid back Atlanta-based authors (ps. I love it there). I don’t like it when authors write as if they are better than you by using big long words. Big long words just make my head hurt. Luckily, Billy and Bryan’s text is straightforward and easy to understand. They get across the concepts in a relatively new area of our field, coining at least a few terms (cross-site flashing, for example).

The structure flows pretty well, building upon what you’ve already learnt. They bring you up a little bit at a time. That’s not to say that there’s nothing here if you’re a Jeff Williams or a Jeremiah Grossman or RSnake - there is advanced stuff, but the authors have to bring the newbie audience along for the ride. I think they do this in a way that helps the newbie more than it helps the experienced folks - but that’s fine: the experienced folks are already au fait with much of the discussed techniques.

The bad

Well, there’s not much wrong with the book. I would have preferred more real live examples rather than “cheating” with Firebug, but that’s a small quibble. If you can do it with Firebug, you code will be pwned sooner or later.

Billy and Bryan spend a bit of time repeating the old hoary “no new attacks in Ajax” meme which is big with the popular kids (mainly because their products can’t detect or scan Ajax code yet and still want money from you), and then spend the rest of the book debunking their own propaganda with a wonderful panache that beats the meme into a bloody pulp and buries it for all time. Yes, there is a lot of old stuff that has crept back in, but honestly, Ajax is *different* in some areas, and it creates new attack surface by definition. There’s nothing really wrong with saying “hey, here’s JSON injection which is new” or “hey, here’s a hybrid Ajax CSRF attack worm, and that’s new”, “hey, you’re adding 25,000 lines to run in the untrusted browser, I reckon the attack surface is going to be bigger and more easily exploited”.

The book also fails to deal with framework authors in any major way. There are so many (bad) Ajax frameworks out there right now. You can accidentally create one if you scratch some code the wrong way. In my view, web application security can only be improved by targeting the frameworks (in the hundreds) rather than targeting the huddled millions who code for a living. However, the book will only sell in the tens of thousands if you target the poor bunnies cutting code. In my view, I would have liked it if the book had covered what *frameworks* should do. Maybe this could be fixed in the second edition.

The Ugly

The book concentrates far too much on attacks, and not enough on building and architecting secure Ajax applications. This is typical of the usual penetration tester mindset, which gets you the hot girls and invites to the swankest parties. However, it leaves a lot to be desired from the software engineering front. We have to stop treating security like a black art - it has to move to being the very way we code, so much so that it hurts if we do it the bad old way. However, penetration testing is far sexier that software engineering, and I’m sure this will not hamper sales in any way (c.f. Hacking Exposed, etc).

Conclusion

If you are writing or reviewing Ajax code, you need this book. Billy and Bryan have done a stellar job in a nascent area of our field, and deserve success. Go buy this book. I can’t wait for it to come out.

I am constantly amazed by the sheer lack of security in the average “enterprise” tool. I’ve looked at many over the years, and most are designed to the “soft squishy center” anti-security model. Typically:

• They do not implement any form of strong authentication, nor any facility to integrate with known strong authentication solutions
• They do not implement any form of strong identity handling, so when someone is logged into component A, it’s nearly impossible at component D to determine who is doing a particular action (see accountability below)
• They do not make it easy to implement end-to-end access control (fine, medium, and course grained), so most of the time, authZ is equivalent to “do what the hell you want to do”, allowing the golden apples to fall very easily
• Often they do client-side stupid tricks and can be trivially tickled into doing something really dumb
• Accountability is simply missing. Yes, many systems have logs, but they are business irrelevant. My personal view is that if a business person doesn’t care about a log entry, it’s not worth collecting. Accountability is the key here, not 1 GB of logs per day
• Data validation misses the business rules allowing tweaking of the golden apples, particularly on the way out. That old mainframe or ancient database is no more trustworthy than a slightly dodgy user
• Modern business scenarios (business / trading partners, extranets, etc) are very poorly done
• Encryption, if it is done at all, is of the crypto toy variety or the folks leave the keys in the door. But 95%+ of the time, it’s not even there, and yet here is all the value of the business, just lying there waiting to rustled under the covers

A counterpoint to this is forum software. Admittedly, I help write forum software in my copious spare time (read: none at all), but considering that in most cases, the value of the asset being protected is precisely zero dollars, it’s amazing just how many security controls are relevant (and useful). They do what they do well, and yet they have to implement - through repeated and automated attacks - pretty much all of the OWASP Guide’s suggestions.

I honestly wonder why folks think that “enterprise” software is somehow magically safe or scalable.

One of the really cool things my job allows me to do is go teach developers and managers about application security.

In the past, I’ve half jokingly said “when the revolution comes, X will be first against the wall”, where X is a product or company who has no clue about security and worse, they pissed me off. Well, I felt the wall and the hood with these students - they wanted to revolt!

My crime? For daring to suggest that they do not belong in production.

READ MY LIPS! DEVELOPERS DO NOT BELONG IN PRODUCTION! END OF RANT

We have to end the developer cult where they believe they are a black magi sending code from on high. Those days never really existed. It was only because any old oxygen bandit* could get paid (and paid well) to write crap. Guess what? Crap may be the state of the art of today, but you’ll have to do better, and soon. 

Real engineers are fallible, but they know this and design around it. Coders seem to think they are magically immune from engineering problems, and do not code in any defense in depth. One of the key ingredients for software security is production management. And part of that is that developers do not have logins for production systems. They do not have access to promote code by themselves. They do not need special features just because they are developers. 

Developers need to learn basic production hygiene. I help teach it, but they have to accept it and live the life. If you are a developer, and you have access to development, it’s time to lose those credentials. If your code has backdoors that let you do more than anyone else, that’s a sackable offense at many financial institutions and government shops.

Let’s start being engineers instead of cowboys. 

* Oxygen bandit. adj. Someone who breathes air they don’t deserve, is able to dress themselves in less than 30 minutes, and who is able to drag a few controls onto code someone else developed. For more details, see one of my favorite sites.

It’s sort of ironic funny when a blogger who is against FUD in the security industry get pwned by sploggers.

Seriously not safe for work: