afongen

The Open Web Application Security Project has released version 2.0 of their Guide to Building Secure Web Applications and Web Services. Many, many improvements over version 1.

It’s well worth reading, but production was rushed a bit to get it ready for release at Black Hat, so you might want to wait for an early update (2.0.1). I’ll have more comments once I get a chance to read through more of it.

Update: Version 2.0.1 of the guide has been released, with a revised cryptography chapter.

I’ve been asked a couple times recently about virus protection for Macs. There are several commercial options, but I’m inclined to use ClamXav, a free virus checker that uses the open source ClamAV antivirus engine.

You can gain some additional protection by not logging in with an administrator account. Doing this reduces the impact that an attack can have. The account I use every day has no special privileges. I’ve set up a separate user that exists solely as an administrator account. When I need to install software, the GUI installer prompts me for the admin username and password. From the command line, I just use sudo for everything, and occasionally su when there’s a lot of typing involved.

This is nothing new to security-minded folks, but even some long-time Unix users who wouldn’t dream of logging in as root don’t think about it on their Mac. It took me a while to make this switch, even after I decided it was a good idea.

It’s also worth noting that you can and should avoid running as admin on Windows. Aaron Margosis has put together a page with what you need to know to run Windows as non-admin.

I use del.icio.us with wild abandon. I thought that might put an end to the “quick links” blog entries, but as it turns out a few recent items merit being called out.

• The Microsoft patterns and practices group have put a security wiki on Channel9.
• Threats & Countermeasures wiki, “a community web site dedicated to discussing, documenting and sharing information security threats and countermeasures.” It’s launched with a lot of content I’ve mentioned before.
• Amit Klein explores security issues of devices between the client and the server: “Meanwhile, on the other side of the web server”.
• Justin Rogers has a new article on MSDN, “Understanding and Solving Internet Explorer Leak Patterns.”. Closures are exceedingly useful but it’s important to note where they might cause problems.
• Josh McAdams interviews Mark Jason Dominus on Perlcast. MJD’s book, Higher-Order Perl, is one of the most exciting things I’ve read recently.
• The Shock of Being Shocked, a wonderful essay in response to the Amnesty International report critical of US activities.
• On Obsidian Wings, another marvelous essay: More Things We Throw Away.
• Did I mention that I’m going to YAPC::NA? :-D

More “real” entries soon.

Ivan Ristic, author of the new and well-received book Apache Security, has released a PDF of the chapter on PHP to accompany the Apache installation and confguration chapter.

What a good resource. I’ve really got to read Apache Security. It’s on my list, but since I don’t spend my days immersed in Apache anymore, it hasn’t been a priority. Buit these two chapters are quite good, and I’m making security a bigger part of my job, so I’ll have to make the time for the book.

The last few days I’ve been reading through the first beta of the OWASP Guide to Building Secure Web Applications, trying to find time to submit my comments and corrections. Aside from a section on “scripting” languages that I think is pretty harsh, it’s shaping up into something very good. There’s a large section on phishing that surprised me: I hadn’t considered what I could do as a developer to reduce the likelihood of phishing, beyond user education (which seems hopeless). Good stuff.

I haven’t written much about threat modeling yet, but believe me I will. I’m just waiting until I finish writing up my talk, which I was sorely tempted to turn into an hour-long exploration of threat modeling instead of what I promised the conference planners. I mention this now because the Microsoft Patterns and Practices group has released a collection of articles on Threat Modeling Web Applications, well worth a read.

A lot of the best resources on threat modeling are coming out of Microsoft, including a chapter in Michael Howard and David LeBlanc’s excellent second edition of Writing Secure Code, a chapter in Threats and Countermeasures, and of course to cap the bunch, Frank Swiderski and Window Snyder’s comprehensive book, Threat Modeling. You’ll find more at del.icio.us.

My web application security testing presentation at the MnSCU IT Conference last week went alright, though not as well as I’d hoped. For all I know I’m the only one who was disappointed, though, and that’s because I had too-big plans for it. It could have been improved by cutting about 20 minutes of content and planned for more audience interaction: stepping through a threat modeling session, for example, or tried live pen-testing. This was indeed what I intended, but it didn’t pan out. I spent a lot of time preparing for the talk — reading, thinking, hacking — but in the end gave inadequate preparation to actually prepping the talk itself, especially being ruthless about what did and did not end up being included. At least I had handouts this year, although I’m already catching heat for my refusal to share the presentation slides. I maintain that the slides are useless outside the context of the talk itself, though that may just be arrogance on my part.

Out of this, two resolutions:

• In my Copious Free Time, I will put together presentations to have them ready and to give myself time to hone their delivery. I already have a list of topics, so I’m on the way.
• I will write more about security here, starting by turning my presentation into a couple articles. Expect them in a week or two, depending on how often I can wrest the laptop away from Kiara.

I expect that I can make good on these without too much trouble.

The conference itself was good. No breakout sessions really stood out as fantastic, life-changing events, which is a shame. The best part was probably long conversations with colleagues, something for which there’s never opportunity at the office. (It’s funny how talking about early Christianity and the process of how texts enter the canon tends to drive others from the breakfast table. :)

I came back from the conference exhausted and a week behind in my reading. Somehow I expected to be able to sleep and read a whole lot more than turned out to be possible.

Update: I’ve posted my presentation notes.

One of the problems in writing secure software is that security is too infrequently considered as part of the requirements or design phase, while of course it needs to be planned throughout the software development process. I have never worked on a project in which there were clearly documented security requirements. Security ends up being part of the process, but only because I’m a bit of a freak about these things. The danger is, of course, just what you always hear: that security is considered so late in the process that it entails a re-architecting and missed deadlines. If deadlines cannot slip and security is an afterthought … well, the problem with that should be obvious.

Off the top of my head, a few ways that identifying security requirements can help:

• Identify vulnerabilities in standard security mechanisms (e.g. an authorized user can still do Bad Things).
• With clear requirements, developers can implement consistent, centralized approaches to security. If developers just have to make their best guess as to what it means to be secure, you’ll end up with 1) widely varied practices because everyone’s off doing their own thing, and 2) inconsistent quality because, frankly, some developers don’t know how to think through security issues. Even if they do, they may be too close to the code to consider its assumptions objectively.
• Staff development: as mentioned, too many developers are ignorant of secure programming techniques and possible attack vectors. Addressing security early may force the issue.
• Raise awareness of security concerns among users / customers.
• Ensure that requirements for a given project are consistent with policies, requirements, implementations already in use.
• Notice how I slid the dreadful word “policy” in there? I believe that security design and implementation should flow from — or at least be traceable to — up-to-date security policy that sets a clear and reasonable direction. By identifying where requirements may be out of sync with policy, we can ensure that policy remain current and meaningful (assuming that policy is flexible and responsive :-).
• And of course, assure that security is addressed throughout development.

Lately I’ve been knocking around the idea of misuse cases as a way to elicit security requirements. I was introduced to the concept by a series of articles by Gunnar Peterson outlining a secure development process (PDF: parts one, two, three). You may already be familiar with use cases, a technique for identifying and describing functional requirements of a system, what the software should do. Misuse cases describe what a system should not do. For each feature or use case, a development team explores how that feature could be deliberately abused or misused, and from these explorations develop misuse cases and security requirements.

Here’s a basic use case diagram; a misuse case is identified with inverted colors:

In this basic diagram, I started with a use case, “Add Comment.” An obvious (and frustrating) abuse of the system is comment spam. This prompted the creation of two new use cases, “Moderate Comments” and “Run IP Blacklist,” to prevent the Add Comment Spam misuse case. Already, just by identifying potential misuses of a system, we’ve built out the requirements to make the system more sound.

Granted, this is neither the best example of a use case nor of a security concern that I could have come up with, but you get the idea.

The heart of a use case is not the diagram, but the textual description. Guttern Sindre and Andreas L. Opdahl, among the first to formally describe misuse cases, suggest a template (PDF) adapted from popular use case formats. It’s worth reviewing.

Here’s the problem, though: I am wary of creating excessive documentation and worry that misuse cases could be taken too far without improving security. Of course, any documentation can be carried to an extreme and prevent actual development getting done. If a project calls for use cases, then I think that misuse cases can help identify security requirements early in the development process and keep them there throughout. I think I’ll hang onto the idea.