The new security features in Firefox 4

The new security features in Firefox 4.

• Content Security Policy (CSP). This is completely new opt-in security innovation and it's among the first to address the Internet plague called cross-site scripting (XSS). Currently Firefox 4 is the only browser supporting CSP but Webkit browsers (Chrome and Safari) are developing their own flavor. The feature lets the developer specify a whitelist of source domains for JavaScript, images, media, and styling. The servers passes on the whitelist policy in a response header and the browser then enforces the policy for all subsequent resource loads when rendering the page. CSP also demands that all JavaScript code be loaded from files and not be inline. Since XSS attack code typically is either from a domain not on the whitelist or inline, the browser will not execute it if CSP is enabled. Coming up with the correct whitelist and moving all your JavaScript to files will be a burden on developers so adoption will take time. Twitter has already deployed a CSP on mobile.twitter.com and will enable it for twitter.com after a trial period (http://engineering.twitter.com/2011/03/improving-browser-security-with-csp.html).
• HTTP Strict Transport Security (HSTS). This is also a policy mechanism. It allows developers to tell browsers that this domain should only be accessed over SSL and the certificate may not cause any browser warnings. The policy is again sent via a response header so you would think it could be included in CSP. But there is a crucial difference. HSTS also specifies a time for how long in the future the browser should enforce it. After all the policy directive is about future requests. So the browser caches the HSTS policy for a whole domain and possibly for its subdomains which is fundamentally different from CSP which applies its policy to each page individually and allows a new policy on every request. PayPal have been one of the main contributors to HSTS and have deployed a policy for some time. HSTS is already supported by Chome and the Firefox plugin NoScript.
• X-Frame-Options (XFO). Again, a response header security directive, originally a Microsoft innovation. It specifies whether the page should be allowed to be framed by another page or not. As such it's a partial countermeasure for clickjacking. But it really shouldn't be presented as such, rather a non-framing option for developers.
• ES5/JavaScript Strict-Mode. Another Firefox first. JavaScript, formally named EcmaScript, is evolving and in version 5 there is an opt-in "strict mode" which gets rid of many of the nasty things in earlier versions. Attackers love the old oddities whereas developers hate them. So we can probably look forward to a fairly good adoption rate out there as soon as other browsers implement it (current statushttp://kangax.github.com/es5-compat-table).
• Do-Not-Track (DNT). This is a privacy feature requested by the US Federal Trade Commission and jointly designed by Stanford Security Lab and Law School. It's an opt-in request header, i e sent by the browser not the server, which specifies that the enduser doesn't want to be tracked. This is of course a major issue for advertise-driven companies such as Google and Facebook who earn money on tracking endusers and serving them in-context ads. Security professionals are arguing that nobody will be able to know if they've been tracked anyway so we'll probably have to wait for large enduser adoption and a public lawsuit on some major company before DNT starts to mean something.

The 5 Complexity Dimensions of Software

I've used this image on countless occasions in my talks on software and on application security. I got it from an academic research presentation back in 2004 or so.

The 5 Complexity Dimensions of Software

 

Complexity in this regard means complex for humans to understand and contribute to.

1. Scale. The larger the system, the more complex.
2. Diversity. The more frameworks, languages, integration techniques, tools, platforms, and design patterns used, the more complex.
3. Connectivity. The more connections, the more complex. This relates to coupling.
4. Dynamics. The more number of states or the larger state space, the more complex.
5. Refinement. Over time every living piece of software is refined, optimized, and polished. Corner cases are found and handled, and regression test suites grow. Refinement drives complexity.

In the context of application security there's always a relation between security and complexity. The more complex a system gets, the higher the risk of security vulnerabilities. Therefore managing application security is partly about managing the five dimensions above.

Sadly, computer science undergraduates rarely meet or learn about this kind of software complexity. That's why industry is reluctant to hire them. Solving 100 coding assignments comprising 200 lines of code each, just doesn't equal developing a system of 20,000 lines of code.

Tomorrow I will give a talk on why and how CS undergrads at Linköping University should learn about software complexity.

A Client-Oriented OWASP

Right now there are tons of thoughts, ideas, and discussions on where OWASP should go. I'm beginning to see an image of a Client-Oriented OWASP (thanks Dinis, for finding the word). In that image there are great initiatives as well as a few things we have to set straight.

Current New Initiatives
A few samples of the thoughts going around: Jeff Williams sent his OWASP 4.0 email, I wrote about the gap between appsec and developers, Mark Curphey wrote about OWASP reaching a tipping point, and Michael Coates wrote about a vision for OWASP.

Since then Michael started the Defenders Community and I started the Developer Outreach Initiative which will become the Builders Community shortly.

Client-Oriented Part 1 – Builders and Defenders
If you combine the Defenders and Builders initiatives, a new, more client-oriented OWASP emerges. Client-oriented in the sense that we put more effort into understanding and helping the IT industry who builds, operates and maintains web applications. On the less technical side we're doing this already with processes and guides – great!

But on the more technical side, OWASP needs to mix up the pentesting and appsec tooling with how to defend and how to build secure webapps. And that for me means Builders and Defenders projects but also gearing our conferences and chapters more towards builders and defenders.

I'm not saying we should cut down on pentesting or scanning tools. I love pentesters and ethical hackers. Heck, I read and retweet your blogs daily. I'm also very interested in static analysis tools, proven by my publications in the area in 2002 and 2005. I'm just saying we need to address a larger crowd and get more balance into our efforts.

Client-Oriented Part 2 – Dealing With Independence
"Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security." —About OWASP

Independent or unbiased has two parts in my opinion:

1. OWASP should be independent in the statements it publishes, all the way from chapters to the board.
2. OWASP should not avoid certain projects, results, or discussions only because some individual/corporate member or sponsoring organization will be upset.

Right now I think OWASP is doing fine on number one. I hear no bashing nor promoting of brands or vendors except for publicly thanking them for their support. Thank you supporters!

But number two is worrying me. At AppSec NYC 2008 there was a talk on comparing static analysis tools called "NIST and SAMATE Static Analysis Tool Exposition" (video). Some well-known brands were in the study. But the speaker refused to show figures for individual tools. There seemed to be a consensus in the community that we should not present anything that could be interpreted as negative for certain vendors, not even if the test setup was made totally transparent. That's a violation of point two above, in my opinion.

2.5 years have gone and we're still not using our independence to compare and test appsec tools. Why? John Steven, an OWASP leader with immense experience in static analysis has published serious obstacles to comparing static analysis tools but they are all saying "Just don't make your tool choices based on a general comparison" which is good advice. We should tell people that. But we still need to start putting appsec tools to the test.

Creating the Client-Oriented OWASP means we'll have to start doing independent, client-oriented research. And if OWASP has been implicitly silenced before I will not take it anymore. Here's a list of ideas:

• Commit to Stefano Di Paola's brand new OWASP Myth Breakers Project.
• Create a space for customer comments on appsec tools (free as well as commercial). Something like AppStore reviews, good and bad.
• Start to compare blackbox and whitebox scanning tools. I suggest we go for a synthesized testbed (i.e. a controlled environment) and invite tool vendors/builders to take part. They get a workday to configure their tools and then we go. The testbed, configurations, and versions will all be published along with due reservations such as John Steven's.
• Start to organize free pentests and design reviews of open platforms. In the best case we cooperate, in the worst case we make our information public in an ethical way to help clients make the right choices.
• Sign the Open Letter to WebAppSec Tool and Services Vendors: Release Your Schemas and Allow Automation

Let's Get the Outreach Started

The developer outreach mailing list now has 52 subscribers. And we're starting right now. Here's the plan in which you can join directly.

Reach out to developers you know or work with, asking what their security itches are. A two week first iteration, so "deadline" is March 10. Whatever you get back you can dump to john.wilander[@]owasp.org and I'll organize it. Please ask developers:

1. Years in software development:

2. Programming languages most used:

3. What are your software security itches in design & code (not working, too complex, can't find it etc):

(And please make sure we don't taint this by asking ninja security guys. ;)

Developer Outreach Initiative

Today I sent out an email to hopefully kick start OWASP's developer outreach. Recipients were an interesting mix of developers and appsec experts. If you want to join us just subscribe to the Developer Outreach mailing list.

Here's the content of the initial email:

The Problem

The web is developing at great speed and I love it. But when I read that the average website has nearly 13 serious vulnerabilities I get sad [1]. It's hindering us from doing more stuff on Internet. Douglas Crockford even suggested we scrap the current HTML5 spec and fix cross-site scripting first [2]. We have a problem.

Developer Outreach

I'd like to get rid of those 13 vulnerabilities per site and I'm convinced designers and developers of web frameworks and applications are the ones who can make it happen. We just have to get the right things into their toolboxes. This has been called "developer outreach" and currently it's a failure.

Proposed Solution – Security Itches

My first proposition is this: Instead of pushing coding guidelines and security tools onto developers I think we should start by asking them "What are your security itches?". Whatever we get back will be our starting point. Maybe we'll pick ten itches and publish good solutions.

   What if they have the *wrong* itches? Well, the goal of the outreach is 1) to find out what developers think, and 2) address their itches to build some well-needed credibility. Before we have credibility we cannot push coding guidelines. And if developers think SSL certs are their primary problem that *is* important.

Proposed Solution – Open Test Data

Security people tell developers to "do input validation". Input validation is no news to developers. The problem is defining the data model and testing the input validation. We can do something important here – building opentestdata.org. I own the domain and dream about the following beautiful community effort:

   You go to the site and can either "submit test data" or "download test data". On the submission page you can anonymously enter e.g. a Portuguese postal address, an Indian human name, a Swedish postal/zip code ... or 100 SQL injection strings. The effort is almost zero.

   On the download page you choose your format and download in context. "We have European customers so we want European human names, postal addresses, and phone numbers". Developers will love it. And that's where we can start promoting security testing!

Questions for You

• First question – do you like these ideas? Are they the right way forward? Would you like to be part of making it happen?
• How should we ask for security itches? And how do we collect answers? Email? Remember we'll probably get one-liners as well as small essays.
• How do we get the test data site flying? App and infrastructure? Auditing à la Wikipedia with a couple of dedicated moderators?

References:

[1] https://www.whitehatsec.com/home/assets/WPstats_fall10_10th.pdf

[2] http://blip.tv/play/g_MngeaxVgI (jump to 20:55)

Fears & Hopes for OWASP

As I leave the OWASP Summit 2011 in Portugal several questions and thoughts are tumbling around in my head. Is the Summit format the right way to do productive conferences? Are we becoming a paperware organization? Will the right people run for the board considering all the formalities? Is the appsec community failing because of an attitude problem towards developers?

I don't like long blog posts so I have split it up. Here's the menu:
1. New OWASP Board – My 10 Questions
2. Security People vs Developers – Does OWASP Have an Attitude Problem?
3. OWASP Paperware Project – Will Non-Code Projects Take Over OWASP?
4. The Summit Is the Right Direction

The OWASP Summit Is the Right Direction

I was on the organizing team for the OWASP Summit 2011. Not as deeply involved as Sarah, Dinis, Lorna, Jason, Deb, Sandra, and Paulo ... but I did organize the four Browser Security sessions.

I truly believe that the Summit format is the way OWASP conferences should go. We should not try to compete with Black Hat, Defcon, BSides or whatever conference out there. We should do something different, geared towards productivity.

Below is how I setup the browser security track and my humble suggestion for making a difference:

1. Prioritize People when Planning
The success of your session boils down to people. If you're at a workshop and "the guy who has all the answers" is not there the workshop is not going to be productive. So my overall goal was to get the right people there. However, you cannot start by inviting people, you only need to start with it as your top priority.

2. Build a Draft Agenda
To be able to successfully invite the right people I had to have a relevant draft agenda. So I spent a weekend watching various webcasts of talks from the people I wanted to invite. From that I built my draft agenda. I basically adopted their agenda and tweaked it with some personal stuff.

3. Reach Out to Key Players
Now that you have a draft agenda you can reach out to key players you already know and that are likely to say yes. Ask them what they think of the draft agenda and more importantly, ask if they would consider co-chairing a topic or two. Get their names up there.

4. Market Your Heroes
When you have a first couple of key players onboard it's time to get the buzz started. Tweet about it. Blog about it. Talk about it. And make use of the heroes who are already booked.

5. Reach Out in Waves
Now you need to get key players onboard that you did not previously know. It's time consuming so I do it in waves. A good weekend with the right inspiration you can hunt down a few more of the people you need to get there, explain the agenda and who else is going. Make use of your network and CC people who might be able to vouch for your workshop. As soon as you get people hooked ask if they want to be involved.

6. Have Faith
A lot of the so called key players are very busy. You may have gotten a confirmation four weeks ago but not heard anything since. Just make sure you send them updates every other week anyway. They'll come. Have faith.

7. Work Onsite
At the workshop you need to tend to practical stuff. I think I was the only session chair who cleaned all the tables up on stage before my sessions. Fresh blocks of paper, new water glasses, no garbage. Also make sure you have an announcement up on the big screen and walk around reminding people that it's only 10 minutes to you session. Do not underestimate what this kind of lightweight service can do for your session.