Category: OWASP

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 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.

Well, I’ve had a bit of a holiday … doing work, and it’s time to pick up the pen and start writing again.

I was struck by the Wiki at just how hard it was to edit and get it the way I want it to look. Even more so when my free time coincides with poor or non-existent network access. Right now, I don’t need to fight the tools. Neil Smithline has a tool which can Wiki-fy a Word document, so my plan is to work in Word (again) and get regular re-publishes to the Wiki. That way, I get maximum productivity where I don’t need to fight the template (I can just write words), and we all benefit once the work is done.

Over the last day or so, I’ve looked at the OWASP Guide 2.1 (a draft which is essentially what you see in the Wiki as 3.0), and it’s not pretty. There’s lot of … interesting … advice in there. I know I (re-)wrote a bunch of it (well, most of it), but it’s proof of the pudding – choose one of “quick, secure, cheap” and you get your priority. The priority last time was to make BlackHat in 2005, a Herculean task that took me out of commission for months afterwards. I was so burnt out from doing stupid insane hours (basically a full day’s work and then a full day’s work at night on the Guide followed by 4-6 hours sleep and doing it over again), that after it was done, I ended up watching more Tivo than doing geeky stuff or going out with friends.

I’m taking the “secure” path this time. The Guide 3.0 is going to be much shorter. In fact, I’m generally going to start over unless there’s some good text already. There’s two reasons for this:

• We want to change the license from the GNU FDL to the Creative Commons Sharealike license, and we can’t do that right now. It would take a long time to find everyone and ask them to assign their (C) to the OWASP Foundation, and if even ONE of the previous authors / contributors / editors cannot be found, we cannot relicense. Now, I know many folks think, “do first, apologize later”, and in general most folks who contribute ANYTHING to an open source effort must realize that they’re efforts are working towards the Foundation’s goals, not particularly theirs… but in this case, we live or die by looking after our copyrighted works. If we want to ensure that others do not copy without attribution, we also have to do that too. It’s a moral thing.
• Much of the previous content really belongs in the (Penetration) Testing Guide, and a significant chunk would be good for the forthcoming Code Review Guide. There’s remarkably little in the current 2.1/3.0 Wiki draft for building secure software.

So that needs to be created. And once I go down that path, I may as well make the effort to re-structure the Guide into a proper security architecture format:

Introduction / Frontispiece

Security Architecture & Secure Design
– Principles
– Policy
– Regulatory environments
– Risk Management and Threat Risk Modeling
– Asset Classification
– Secure by design
– Initiator / Approver
– Help Desk / Administrative interfaces
– Secure Coding Standards and Methodologies

Identity Management
+ My family and other animals, or Evidence of identity and the user management life cycle
– Questions and Answers – still stupid after all these years
– Providing advice on storing strong credentials

+ Authentication & Session Management
– When to use 2FA vs passwords
– Designing for federated authentication
– Designing for federated trusted authentication
– Transaction signing – Authenticate the transaction, not the user (necessarily)
– Signing calculators
– Flow diagram for SMS / e-mail trx signing
– Flow diagrams (2FA, certificate, password)
– Common controls (idle timeouts, etc)
– Protecting against common attacks (Brute forcing, phishing, etc)

+ Access Control
– Coarse (access to system at all)
– Medium (access to secured resource / secured function)
– Fine (access to particular datum i.e. Direct Object References)
– Building indirect object references
– Attacks (forced browsing, direct object reference, etc)

Data Protection
– Designing highly protected systems
– Asset classification and legal requirements to protect data
– NOT using / storing certain types of data
– Privacy
– Secure Communications
– Secure Storage of sensitive information
– State management
– Pattern
– In a “normal” web app, Ajax, and web service

Integrity
– Data validation
– Output encoding
– File system

Accountability
– Designing high value systems – preventing fraud and promoting accountability
– Designing for incident response / forensics
– Auditing
– Logging
– Error handling

Availbility
– Protecting against injections
– The pattern of badness and how to protect against it
– XSS
– CSRF
– SQL / MDX
– LDAP
– XPath
– …
– Denial of service
– Buffer overflows
– Concurrency and race conditions

Services
– Traditional (OS, e-mail, etc)
– Web Services
– Ajax (JSON, and plenty of other topics, etc)
– REST
– XMLRPC
– .NET Remoting
– JNDI and JMS

Ensuring Quality
– Software quality assurance – how to test web apps properly (and where to go after here)
– Configuration
– Deployment
– Maintenance

Index
– Index
– Glossary
– References
– XSS Cheat Sheet (after permission is sought again)

Although I am not looking forward to writing every night again, at least this time I have a good basis to work from and I’m not trying to write three Guides in one. I am probably underestimating the effort required, but I hope to bring this in under 150 pages, delivering basically a chapter a month or so (about 10 pages per chapter) to the OWASP Guide list to be peer reviewed, code snippets and diagrams created. Once we are nearly there, with some luck, we can send it to the publisher.

Why don’t I want a co-author? I tried that in the past and although help was offered, only a few rare individuals submitted work afterwards. Some of it was excellent, but much of it needed re-writing due to technical errors or outright hinky prose. The Testing Guide shows that the quality varies so much when you DO get help that it’s simpler to write the text yourself.

I will gratefully accept help with the editing – editing the text once complete is a very necessary step, and it’s certainly much easier for folks who are unaccustomed to writing large books to edit than to write from scratch. There’s a world of difference between writing a blog entry and a book. I think it’ll just be faster this way, and hopefully, a bit higher quality. Of course I could be wrong!

Off to fire up Word.

It would have been nice to get Web 1.0’s security fixed first before starting on Web 2.0. And before Web 1.0 was … the mainframe.

In my time with health care providers, at one of the world’s largest telcos, at various largish Australian banks, and over the last few weeks teaching mainframe folks about secure coding techniques, I’ve come to a conclusion: we’re in a crisis. Not only have we not really solved the necessary problems in Web x.0 land, we haven’t been keeping an eye on the ball in the most important area of all: where the value lies.

Critical nationally protected infrastructure all use mainframes to process the value of our lives:

• Banking (money – a necessity, which allows you to buy housing)
• Logistics (getting stuff from A to B)
• Defense (making sure we’re protected)
• Food chain (eating – a necessity)
• Government (unfortunate necessity)

Pretty much covers Maslow’s Hierarchy of Needs in every way – modern life would not be possible without mainframes. We cannot:

• house ourselves (buy houses with a mortgage),
• eat (we no longer farm or hunt ourselves and rely on getting access to food at supermarkets (who use mainframes to keep stock levels and understand what their customers are buying) which requires shipping – and most large logistics firms use mainframes for everything from load optimization through billing and scheduling
• or even get water depending on your water utility.

I look back wistfully at seminal security papers and works from the 1960’s and 1970’s. I feel miffed that this 40 year head start has been squandered. Almost everything we’ve “discovered” in web application security is old news to these researchers. Their programmer contemporaries are still out there, building mainframe apps, and they do not know anything about the old research, let alone the new. “Web apps? Not my job, governor!”

Today’s mainframe devs do not know the core principles – confidentiality, integrity, and availability (except for performance reasons). Key security principles such as defense in depth, complete mediation, and validation are no longer practiced, even though the old code lived and breathed it.

In my discussions with mainframe devs, they struggle with basic security concepts, and even in some cases, the need for security at all. After all, the attackers know nothing of the mainframe and they can’t get on to the system. Right?

In the end, the fault partially lies with the application security community. We in web application security know no mainframe stuff. I don’t know anyone competent to review COBOL, RPG, PL/1, IBM assembly language (!), or a host of 4GLs. I don’t know anyone who knows a jot about RACF, ACF2, and all the security mechanisms available on mainframes since before I was born.

Very few know anything about TPF, MVS, z/OS, CICS, and VM. And yet, taking even one of these – TPF – could reward study for years. It powers all the airlines, the travel industry (Galileo, the world wide booking system used by everyone who travels, is a TPF application), and even 911 emergency response systems. And yet, I must admit I’ve never heard of it until last week, and yet I’ve worked around folks who used mainframes for the last 15 odd years. What chance does that newbie .NET coder who needs to have a secure ordering system involving a mainframe as a backend? We have no advice.

So we can’t properly review applications that use mainframes … except to treat them as black boxes. And that is wrong! Most large organizations have a 30-40 year investment in their applications and they’re not going to re-write in a Johnny come lately language like Java or C# just because we can’t review old code. There are literally billions of lines of COBOL out there, and it … runs the world. There should and MUST be a way we can review this code.

What needs to happen in the security research community?

We need to research the security concerns in commonly used mainframe languages (COBOL, RPG, PL/1, assembly) on top of common platforms (z/OS, others) using their common data stores (DB2, and so on). We will break old/new ground here. Probably this stuff was being thought about back in the late 70’s early 80’s, but was never published. I think our field’s brightest researchers simply stopped looking at commercial environments around this time.

We need to understand their native toolsets to provide key security architecture deliverables, such as using RACF to provide authC and authZ services. The mainframes have a rich set of security tools… but no one uses them any more.

We need to become competent in reviewing these older systems and applications, so we can provide reasonable advice

We need to be choosy about what to review – there’s simply so much code at every large firm and government agency and basically no one to review it

Although OWASP should be publishing the results of this work, maybe we as the security industry should have an extended residency with the IBM Redbook folks to get access to the real deal (do you have a mainframe?), peer review our work, document all our findings and get it back in the hands of the mainframe devs in a timely fashion.

What needs to happen on the mainframe side of the fence

Business requirements should reflect in the security architecture. We know that mainframe has almost all if not all of the necessary support of a “modern” security architecture:

Data protection

• Confidentiality. Most mainframes have an inbuilt HSM. Few sites are using this feature! What a waste. Let’s get this out there and encourage the use of hard core encryption
• Integrity. Most of the protocols in the SNA stack have inbuilt integrity controls, and yet once they are mated to TCP/IP, the common protocols such as ftp, x3270, and access to MQ is all unencrypted and has no integrity controls. This needs to change

Identity management

• RACF is basically as old as me. It supports everything a SSO vendor would happily sell a Java site and has done for over 30 years. It now supports modern pass phrases, LDAP support, and so on. These “advanced” features should be in use at more sites.

Event management

• I still need to do more reading, but I can’t imagine that the systems which power banks has no audit or logging features. Let’s learn how to differentiate between logging and auditing, and ensure these logs are protected from unauthorized use.

The folks on the mainframe need to understand the powerful tools and native platform support they already in their possession. This requires training and support from their vendor. IBM? Hear me.

We in the security research community can’t possibly understand every possible version of every language and platform out there. It’s time to start consolidating around a few common platforms and languages. I propose the security industry sticks to supported platforms and languages as IBM has a chance of rectifying any problems we find.

This will be painful for many, but it’s like the pains the accounting industry went through in adopting the GAAP. We can’t and should not audit a planet’s worth of loose receipts.

I am not hopeful that any of this will change any time soon. I am willing to have a dialog with any and all mainframe folks. Let’s talk.

It’s time to get moving again. The Top 10 2007 is out. So it’s time to look at the raison d’être of OWASP – The OWASP Guide. The OWASP Guide is a compendium of best practices, what not to do (in 2003-2005), how to test for a problem, and occasionally comically bad English. I did 18 hour days for nearly six months back in the day to get it out the door, something that is just not possible these days as I have my insomnia mostly under control.

My view is that we need four smaller books:

1. OWASP Secure Lifecycle Guide for Requirements, Architecture & Design
2. OWASP Guide to Writing Secure Applications
3. OWASP Testing Guide
4. OWASP Code Review Guide

That way, we can farm out the materials that exist in the Guide today to the appropriate books, and make it much more lightweight. Being 300 pages is fine, but honestly, I doubt anyone besides me and the translators have read it in its entirety. I don’t think the average work-a-day developer has the time nor the inclination to read yet another fat book, particularly one that they themselves don’t see as being particularly useful to their primary role: pumping out insecure code, leaving time for instant messages and a few quick rounds of killing fellow cubicle dwellers … in whatever FPS du jour.

Schneier stated recently in one of his famous counter points with mjr, that he believes that the security industry shouldn’t exist and that penetration tests (paraphrasing) should read and then shredded. Seriously, if you’re waiting until the pen testers tell you that you have a problem, it’s far too late. Software engineering must make the jump from being a cowboy nation of lazy and uneducated coders to being a repeatable, safe art. That’s why I work in the area I do – fixing the problems before they are problems. Then it’s basic risk management. And folks have been doing risk management for years, well before the current security industry sprang up. There are snake oil sales folks in our industry without a doubt, but there are many skilled and useful folks as well. I hope I am one of the latter.

Back to the Guide… There’s a need for the OWASP Wiki to be in sync with these master works. This is an ongoing problem; I don’t know how to solve it. Writing a book one page at a time is ineffectual and wasteful. Editing a massive tome even more so. Wikis have their place though, even if the Wiki fan boys hype it beyond its actual capabilities. The Wiki way is not the book way. To a Wiki fan boy, this is actually not a problem. But to me, as a lover of narrative and meaning, the dictionary like slabs of text are like context-less ships passing in the night. There’s no thumbing around there without maybe missing something important. The Wiki is great as a dictionary; terrible as a learning platform. I love puttering around great Wikis like H2G2. Towel Day is May 25. Don’t forget your towel.

No matter which way you slice it, someone has a lot of work to do to translate a book into a useful and helpfully hyperlinked Wiki, and a truly awesome Wiki is nearly impossible to fold back into a book.