The Anatomy of a Twitter Storm

Hi! I'm @johnwilander and yesterday I unwillingly created a Twitter storm.

#GodIsNotGreat and Twitter Trends
It was Friday afternoon in Stockholm, Sweden and I came across a tweet with the interesting tag #GodIsNotGreat. Earlier that day I had read about famous atheist and writer Christopher Hitchens passing away but there was something else going on around this tag. In the tag stream I read about christians threatening tweeters using the tag and several claims that Twitter had pulled the tag from the trends list.

I couldn't find the tag in my trends list nor in the US or European list. Still, tweets with the tag were pouring in. In the stream I found a tweet from @HillyFoz saying:

"So Twitter, it's ok for #reasonstobeatyourgirlfriend to trend but you saw fit to put a stop to #GodIsNotGreat ?"

Apparently #ReasonsToBeatYourGirlfriend had been a trend. Now that's interesting too. So I wrote The Tweet what would become a Twitter storm:

As you can see in the screenshot, numerous people eventually retweeted this.

I could see the amplification within a minute. Suddenly around 10 people had retweeted it and new retweets where being reported faster than I could open them on the activity tab.

At this point I reviewed my tweet and saw that I had claimed something I couldn't back up with a source or a reference. Such things make a about-to-be-PhD blush a little :). Soon enough I started to get complaints. I considered deleting the tweet but decided to let it live on to see what this storm would be like.

Here Come the Trending Bots
Time for the first bot to spot me. Apparently I was trending in the UK:

While the retweets, complaints and comments were pouring in I quickly became a trend in USA and Canada too:

About 30 minutes later the spam bots had caught on and I started getting all kinds of weird stuff. Some of them I couldn't tell if they we're real people or bots. For instance this (not even a reply to my tweet):

I did not respond :).

The final bot step was when the @favstar50 bot congratulated me to my first 50+ favorited tweet.

Trying to Find a Source
Some of the complaints I got where getting nasty so I thought I might be lucky enough to find a source and patch my earlier tweet. UK online paper Huffington Post gave me at least half an excuse as they wrote:

"The hash tag #GodIsNotGreat also began trending, which was followed by a storm of protests by the religious, many unaware that the hash tag was a tribute to the author's passing.


Twitter reportedly removed the topic from the trending lists following threats of violence towards the creators of the hash tag. The irony that Hitchens book, one that makes stark the link between religion and violence, had stirred the religious to then threaten violence was not lost on the twitterati."

But my antagonists quickly dismissed Huffington Post as a bad source and also pointed out that they said "reportedly" which I failed to do in my 140 chars. So much for the patchwork.

The Day After
When I got up Saturday I checked my email. Well ...

I had got quite a few new followers. Woot! But I guess most of them will unfollow when I go back to tweetin' about JavaScript and application security. Easy come, easy go, huh? Note the browser tab for Twitter with 19 new notifications that dropped in while I was taking the screenshot.

I checked my Klout score:

It looks like the revenue diagrams Uncle Scrooge has on his wall :).

Later I found out that Gizmodo had written an article about it – Shutup, Twitter Isn't Censoring Your Dumb Trends. There, in the middle of their bashing was my tweet! Luckily, Gizmodo didn't dig out the source but rather took poor Jessica K's commenting retweet as an example. Phew.

Lessons Learned
My lessons learned:

• I should probably check the sources of every tweet, not just my tech tweets.
• Rumors spread extremely fast on Twitter. As long as the message is interesting, people retweet.
• Twitter trends are not based on volume, they're based on derivatives, or speed if you will. If the increase of the #GodIsNotGreat tag would have been steady it would have still been a trend. But it wasn't.

REST and Stateless Session IDs

Nowadays there's a general reluctance to introduce (more) server-side session state because of scalability. And there's specific reluctance to session state in RESTful web services, due to design principles.

In the stateless requirement of REST we read:

"The client–server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource." [Wikipedia]

This is a tough requirement, especially if we want features such as authentication and sessions.

So, can we have session ids without server-side session state? Yes.

The Relation Between Sessions and Authentication
There's often a tight relationship between authenticating users and holding their sessions. Anonymous sessions are not very sensitive whereas authenticated sessions have to be protected against hijacking, fixation, forging, and replay. Actually, a valid session token authenticates the session, so you're basically authenticating yourself every request. Which leads us to the first stateless session solution ...

No Sessions => Authenticate Every Request
If session ids are in fact authentication tokens we might as well use the mental model of no sessions, instead authenticate each request. The old HTTP Basic Authentication does this by storing your username and password for subsequent requests. But there are more advanced versions such as authentication in Amazon's S3 REST API.

They use a custom HTTP scheme based on a keyed-HMAC (Hash Message Authentication Code). To authenticate a request, you first concatenate selected elements of the request to form a string. You then use a shared "AWS Secret Access Key" to calculate the HMAC of that string, i.e. you sign the request. Finally, you add this signature as a parameter of the request.

GET /photos/puppy.jpg HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Mon, 26 Mar 2007 19:37:58 +0000


Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=


Looking deeper into how this scheme works you find the following spec:


Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;


Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );


StringToSign = HTTP-Verb + "\n" +
________Content-MD5 + "\n" +
________Content-Type + "\n" +
________Date + "\n" +
________CanonicalizedAmzHeaders +
________CanonicalizedResource;


Canonicalization of course requires some processing such as converting headers to lower-case and sorting them lexicographically. The date works as a timestamp and narrows the replay window.

The server then does the same signing with the shared secret associated with the AWSAccessKeyId. So we're switching from server-side session state to more cycles and latency on both client and server.

Worth noting:

• Signed requests are much stronger than mere session ids. Cross-site request forgeries will be mitigated with this scheme.
• By authenticating all requests with a shared secret we don't have any time-bound sessions or timeouts. Just fire whenever you want.
• The persistent shared secret is much more sensitive than a temporary session id. A cross-site scripting attack will steal the shared secret which is much worse than session hijacking. This means the scheme is less suitable for browsing sessions and more suitable for machine-to-machine communication.

Stateless, Hashed Session ID and Salt
The server can generate session id cookies by hashing usernames and a random global salt:

sessionIdCookie_v1 = username ":" SHA256(username + global salt)

The salt is used for all sessions but only valid for a certain timeframe, say 15 minutes. A new salt is produced every 5 minutes and incoming session ids produced with the previous but still valid salt will be exchanged for a new session id with the fresh salt. That means a session timeout of 15-5=10 minutes.

If we truly want to go stateless we cannot kill such a session since that would require a server-side table of revoked session ids. So in the stateless case an attacker will have a 15 minute replay window in which he/she will refresh the session and have endless access.

Stateless, Encrypted Session ID
By just storing a server-side symmetric crypto key we can effectively decrypt incoming session IDs and trust their contents. Imagine a cookie based on:

sessionIdCookie_v2 = AES_GCM(128 bit key, auth tag, username + timestamp)

This means we don't have to store each session ID. Instead we pay the price of decrypting incoming cookies and checking that the timestamp is within a timeframe, say 15 minutes. For all incoming session IDs older than 5 minutes we regenerate a new cookie to effectively run a 15-5=10 minute session timeout window.

Again, if we want to go stateless we cannot kill such a session since that would require a server-side table of revoked session ids. So an attacker will have a 15 minute replay window in which he/she will refresh the session and have endless access.

Conclusion
There are three competing parameters to prioritize between:

• Server CPU cycles per request
• Server-side session state
• The replay window

The tradeoff between CPU cycles and memory footprint will change with new technologies such as non-blocking IO in node.js. So yesterday's best practice might not be valid today.

The difference between regular session hijacking and hijacking of stateless session ids is that successful theft of a stateless session id authenticates the attacker even if the victim has logged out. Remember, the server doesn't store the session state. And even if the server would store the boolean isLoggedIn for each user, an old session id will still be valid if the user logs in again, as long as it hasn't timed out.

So ask yourselves what your tradeoff between CPU cycles and server-side state is. Then consider the replay+refresh leverage of a successful cross-site scripting attack.

Friday JavaScript & Web Dev Links

I'm summing up some reading tips for JavaScript and web development. Just thought you'd like 'em.

JavaScript

Command-Line JavaScript on Rhino
So you want to write command-line JavaScript on Rhino? Here's how you do it on Mac OS:

1. Download Rhino 1.7R2: http://www.mozilla.org/rhino/download.html
2. Unzip Rhino in for instance Applications/Utilities/Java
3. Download JLine: http://jline.sourceforge.net/
4. Unzip JLine in for instance Applications/Utilities/Java
5. Move jline-0.9.94.jar to /Library/Java/Extensions
6. In a shell: cd /Applications/Utilities/Java/rhino_1_7R2
7. In the very same shell: java org.mozilla.javascript.tools.shell.Main

Code away!

Building Large-Scale jQuery Applications

A good read on RIA architecture and links to lib and framework choices, not only for jQuery junkies:

http://addyosmani.com/blog/large-scale-jquery

JavaScript Primitive Types Becoming Objects

About JavaScript's primitive types and how they become objects when their properties are used:

http://javascriptweblog.wordpress.com/2010/09/27/the-secret-life-of-javascript-primitives

Scoping and Hoisting in JavaScript

If you haven't looked into scoping and variable assignments in JavaScript, read this and improve your programs:

http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-Hoisting

'String'.replace() Only Replaces First Instance

String.prototype.replace, i.e. 'yourString'.replace(), only replaces the first instance of the regexp. So beware. Twitter made the mistake and got vulnerable because of it. Read about it and a suggested patch:

http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design

Non-Blocking JavaScript Loading (and more) With head.js

With Head JS your scripts load like images - completely separated from page rendering, and in parallel!

http://headjs.com

Web Development

RESTful Design, Patterns and Anti-Patterns

A nice webcast on REST design. For instance brings up the idea of session ids with constant state on the server. But as always, I wonder when the CSRF storm is going to hit all these REST services out there?

http://www.parleys.com/parleysserver/indexing/presentation.form?id=1397

Chrome Web Dev Extensions

Google Chrome is becoming many web developers' favorite browser. The bundled developer tools are good. But check out the extensions too, for instance the CSS reloader:

https://chrome.google.com/extensions/featured/web_dev

iframe Loading Techniques and How They Affect Performance

Want your iframes to stop blocking and allow onLoad to fire earlier? Check these techniques out:

http://www.aaronpeters.nl/blog/iframe-loading-techniques-performance


Did I miss a good resource or read? Just fire away below.

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.

Another OWASP Paperware Project, Anyone?

Summing up the OWASP 2011 Summit I fear OWASP is becoming more and more paperware and less and less software. On the Summit's fixed schedule we had 15 technical sessions and 27 non-technical sessions (my interpretation). That's almost two thirds non-tech.

The only guys I saw actually coding at the summit were people we had invited and that are not OWASP leaders (Powerpoint slides with code do not qualify as coding). At the same time OWASP is getting desperate about not reaching developers.

The solution is in my opinion to cut down on paperware, pdfs, Powerpoint presentations, guidelines, and policies. Developers want code, not Word documents. I tried to bring this up during the OWASP Secure Coding Practice session but failed to convey my view. Who would have thought a coding guide did not contain code?

If you hand a document to a developer that says "Do canonicalization" you will not get canonicalization in the application. But if you hand a developer code snippets in a relevant language that show a couple of instances of canonicalization problems and how the solution could look you will get a change.

So, why do we still have all these guidelines and policies that talk about code? I believe the reason is that the authors don't know how to program. Guys writing appsec guidelines typically cannot code themselves and developers can smell it a mile away.

Do you believe OWASP needs to reach developers?
Are you right now working in a word processor rather than an IDE?
Stop!

Developers believe in other developers and working code. You want to change how they play? Get in their game.

Security People vs Developers

"Developers don't know shit about security". That may very well have been the most retweeted quote from the 2011 OWASP Summit. I heard it from stage firsthand and I wrote the original tweet about it, adding "Well, I got news. You don't know shit about development".

I truly believe this is one of OWASP's biggest problems. I hear it all over the place – frustrated appsec people claiming that developers and managers are ignorant, lazy, or untrained since they don't prioritize security. But it's we, the appsec people who are ignorant, lazy, and untrained! And that's why we're failing in developer outreach. We keep going to our own conferences, pushing Powerpoint slides, discussing unsexy web 1.5 code, and still think we're on the top of the hill. We're at the bottom, guys!

I've done surveys with 200+ developers to figure out how security is prioritized. In general, this is the picture:

Software Priorities According to Developers

1. Functions and features as specified or envisioned
2. Performance
3. Usability
4. Uptime
5. Maintainability
6. Security

When I tell appsec people this they typically go "Yeah! See, that's the problem. We should be much higher on that list!" No. No, no, no. We belong at level six and unless we appreciate and understand how security fits in with functions, performance, usability, uptime, and maintainability we will keep being ignored by developers.

Why? Well, a featureless system is useless. A security feature that hits performance notably is out. A system with poor usability will bring no business so usability is above security. "Uptime, hey that's a security thing!" No. Just because DoS attacks hit your uptime doesn't mean we own the issue. Many things affect uptime such as release and deploy cycles, maintainability, caching, scalability, configuration, and patching (no, not just security patching). Finally, maintainability affects ROI much more than security in the general case. Thus, security == level six.

Appsec friends, let 2011 be the year where you go to training to learn what's important in software and where security fits in the big picture. Then we won't hear anymore jokes on ignorant developers in 2012. Instead we'll be humble and get things done.

New OWASP Board – My 10 Questions

At the OWASP 2011 Summit I attended some of the sessions on OWASP Bylaws and OWASP Governance. I agree we need to update and define roles and duties but there are more urgent issues.

Discussing the board is complicated if you're not natively English speaking. Asian, South American, and European OWASPers tend to know English appsec terms but they do not know the nuances in what's being said about governance. This effectively means only English speaking people will define how OWASP should be governed and mainly English speaking people will run for the board. Today the board consists of 4 Americans, 1 Irish, 1 Portuguese living in London, and 1 Belgian. That is neither representative nor good for OWASP.

I'd like to see the OWASP board grow more diverse. Therefore I will ask the questions below to the members who run for the board. Note, this is not a requirements list, rather parameters I'd like to see diversity in.

1. Which human languages do you speak?
2. In which parts of the world have you lived at least 3 months?
3. Have you shipped production code? How long ago?
4. Please provide a list of web technologies you consider yourself proficient in (markup, styling, scripting, server-side code, server configuration and operational setup ...)
5. What is your typical appsec role (pentester, trainer, developer, project manager ...)? Are you a consultant, vendor, or do you have an appsec role within an organization?
6. Please provide a list of appsec activities you consider yourself proficient in (code auditing, threat modeling, SDLC implementation ...)
7. Have you run or are you running an OWASP chapter? Which?
8. Have you run or are you running any OWASP projects? Which?
9. Do you have a college or university degree? (No requirement, I just want the right mix)
10. Do you have a postgraduate degree? (I'd like to have at least one on the board)

There are no correct or preferred answers to the questions above. I only want to ensure we have people from as many parts of the appsec community as possible. For me that's more important than knowing all the English terms in our bylaws or policies.

65,000 New Jobs in Sweden 2011

Sweden is in a better economic and fiscal shape than most other OECD countries, says OECD. That situation means labor demand is growing and The Swedish Public Employment Service today announced its predictions for empoyment in 2011.

"A total of 65,000 more are expected to get jobs during the year and the number of occupations where there is a shortage of labor is increasing steadily. Most difficult for employers to find staff will be in the computer professions, engineering professions and construction trades because there are too few trained."

Here's their press release in Swedish. You can translate it with Google.

If you have IT skills – welcome to Sweden!

Countdown Challenge for OWASP Summit

The official OWASP Summit Challenge is out – a JavaScript fighting arena where your script should show its name more prominently than its competitors. The first round attracted 8 contestants and "dross" scored the first point. Check out all the scripts and the next round of competition: http://makeXORbreak.com

The challenge starts the countdown to one of the most important meetings in application security history. February 8-11 we invite you all to join round-table discussions with industry and research leaders on how to solve XSS and enhance browser security, which appsec metrics work, security of HTML5 and EcmaScript 5 and more. We truly believe that crucial things can happen in a social, productivity-oriented environment. That's why OWASP is going all-in on the Summit.

Google will be there. Mozilla will be there. Microsoft will be there. Facebook will be there. PayPal will be there. Apache will be there. The world's top appsec companies will be there. The authors of (my) favorite appsec books will be there.

OWASP Summit 2011

Best thing of all? You are most welcome to join!

Running Civ IV on HFS+ Case-Sensitive

This post is completely unrelated to application security but since I struggled for two hours not finding my specific solution anywhere I just though I'd post ...

How I got Civ IV working on my Mac OS X with case-sensitive file system (HFS+ case-sensitive).

The basic trick is to create a new case-insensitive disk image using the disk utility tool in /Applications/Utilities. Do it with the following specs (taken from this blog post):

• Name: caseinsensitive (or any other lower-case name of your liking)
• Size: Custom 30 Gb (it will only use up the space you need anyway)
• Format: Mac OS Extended journaled (i e not case-sensitive)
• Encryption: None
• Partitions: No partition map
• Image format: Sparse bundle disk image (this makes sure you only use the space necessary)

Now you uninstall Civ IV from your regular drive (most probably from /Applications) by deleting these folders and files:

• "Civilization IV Gold" folder which contains the game applications
• "home folder\Documents\Civilization IV" folder
• "home folder\Documents\Civilization IV Warlords" folder if you have Civ IV Gold Ed.
• "home folder\Library\Application Support\Civilization IV" folder
• "home folder\Library\Application Support\Civilization IV Warlords" folder if you have Civ IV Gold Ed.
• "home folder\Library\Preferences\com.aspyr.civ4.plist" file
• "home folder\Library\Preferences\com.aspyr.civ4warlords.plist" file if you have Civ IV Gold Ed.

Then you install Civ IV from your DVD to the newly created disk image named "caseinsensitive". I additionally created a folder structure on the new disk image using these shell commands (don't know if they're needed):

• mkdir /Volumes/caseinsensitive/Documents/
• mkdir /Volumes/caseinsensitive/Documents/Civilization\ IV
• mkdir /Volumes/caseinsensitive/Library
• mkdir /Volumes/caseinsensitive/Library/Preferences
• mkdir /Volumes/caseinsensitive/Library/Application\ Support
• mkdir /Volumes/caseinsensitive/Library/Application\ Support/Civilization\ IV

Finally you just start Civ IV from the new disk image. Happy gaming!