Tuesday 6 March 2012

What Grails developers can learn from the Github/Rails Mass Assignment Vulnerability

In short: Github's security was breached due to a "vulnerability" in Rails. Grails also suffers from the same vulnerability, but there are ways to protect your app. Check your code for instances of:
new DomainModel(params)
and replace them with bindData or command objects. When using bindData, use the "includes" option - it is safer than "excludes". The following regular expression might help you find some offending code:
new .*?\(params\)

In addition, make sure that all your domain objects have comprehensive constraints to protect from malicious users. For more info, read on.

Over the weekend, Github suffered a security breach that allowed an unauthorized user to make a commit to the main rails/rails repo. Fortunately, the user had no malicious intent, and only made the commit to bring awareness to the issue. Whether this was the best approach to achieve this is another discussion, and not the subject of this post.

Github quickly resolved the issue, but thousands of other Rails sites out there are vulnerable to the same attack. Unfortunately, many Grails apps are also liable to have the same issues. Before I go into why this is, and how you can mitigate it, here's a bit of background.

Weapons of Mass Assignment

Rails, just like many modern web frameworks, allows you to quickly create an object using the request's parameters. In Rails, this code looks a little like this:

@user.update_attributes(params[:user])
- or -
@user = User.new(params[:user])

Basically, what is happening here is that any of the user instance's properties that have a corresponding request parameter get the value of that parameter. In this case, imagine the User object class had at least two properties:
  • name
  • isAdmin
Now imagine that the request to create a user had one parameter, name. Under normal operating circumstances, this would work - but it is inherently insecure. An attacker only has to guess that a property exists on the User object with the name 'isAdmin', then add isAdmin=true to the HTTP request. When they do this, the user will be created with isAdmin set to true. Bad news.

This is known as the "mass-assignment vulnerability" and is, along with mitigation strategies, described in many places - including the Ruby on Rails Security Guide.

What happened at Github?

According to the github blog, the "malicious" user used the mass-assignment vulnerability to compromise the form that allows you to set authorized SSH public keys for your repo, and added his public key to the rails repo, effectively giving him permission to directly commit there.

What about Grails?

Grails also has the concept of mass assignment, but tends to refer to it as "data binding" or "batch updating". It is covered in detail in the Grails Reference, but i'll summarize it here.


//Create a user object, initializing it with values taken directly from the request.
def user = new User(params)
- or -

def user = new User()
//Update the user object, with values taken directly from the request.
user.properties = params
This is exactly equivalent to the ruby code I posted above. It also suffers from the same vulnerability. Any property on the User object that grants that user elevated privileges will be open to attack via HTTP.

If it's insecure, why would anyone use it?

Well, two reasons:
  1. Many people don't know it's insecure
  2. They RTFM. But only briefly.
To address my first point, most Grails developers, like those using any other language/frameworks, are mid-level devs under pressure to get features out. In this situation, it's also unlikely that their code will get peer-reviewed, and unlikely that they'll benefit from an experienced developer pointing out the error of their ways. This is what has happened in the Rails world, and I'm sure it's happened with Grails too.

So, what about the documentation? Grails docs are awesome. They've improved leaps and bounds in the last couple of years. They're clear, concise and accurate. However, in this case, the security risks and mitigation strategies are buried deep down in the topic of data binding. "Data Binding and Security concerns" appears as the 7th and final section, after the section entitled "Data binding and type conversion errors". Up until this point, every example shows the use of the new User(params) method of object creation.

So this in combination with inexperienced developers pushed for time, eager to please the powers that be, gives us a perfect storm. Very fews devs will know about the risks of batch updating and fewer will know how to avoid them. It also doesn't help that Grails scaffolding also uses the new User(params) method of object creation. It doesn't really have a choice right now, since the scaffolding scripts can't make a good guess which properties to include in the batch-update, and which to exclude. They could perhaps just use bindData (see below), including all of the object's properties. But that doesn't seem to illustrate much of a point.

So, what should I do?

As a developer who is using Grails, you should use this as a wake up call. Never write code that uses this style of batch updating, and review your controller code, removing any examples of it you can find. Take a look at the docs and understand the mitigation strategies for this issue. In short, they are:
Using bindData

//Update the Person object, with values taken directly from the request - including only properties known to be safe
def p = new Person()
bindData(p, params, [include: ['firstName', 'lastName]])

For more, see the bindData docs. You'll notice that there are ways to blacklist/exclude certain properties - this is ok, but it is more prudent to always white-list/include allowed properties instead.

Using the subscript operator

//Retrieve a Person object, and update it with values taken directly from the request - including only properties known to be safe
def p = Person.get(1)
p.properties['firstName','lastName'] = params


This is a "white-list" approach, that achieves the same as the bindData method above, but only works on Domain Objects. It is also not as flexible as bindData.

Using Command Objects or Action Arguments
Command Objects are explained in the docs too, but in a different section. They enable the developer to create a class that has very similar characteristics to domain objects. By including the command object in the parameter list of a an action, Grails will automatically initialize the command object with the values taken from the request. This is not dangerous, because this object will not be directly saved to the DB, but instead probably passed down to a service layer where its properties will be accessed directly. For example:


class UserController {
def authService

def create = { CreateUserCommand cmd ->
if (cmd.hasErrors()) {
redirect(action: 'createForm')
return
}

authService.createUser(cmd)
}
}

class CreateUserCommand {
String username
String password

static constraints = {
username(blank: false, minSize: 6)
password(blank: false, minSize: 6)
}
}


If you have one or two properties you need to update, you could use action arguments (new in Grails 2.0). They allow you to do something similar:


def create = { String firstName, String lastName->
def user = new User(firstName: firstName, lastName: lastName)
// save the user, checking for validation errors
}


Important: None of these mechanisms guarantee safety. You can never trust any input that comes from a user, even if using one of the above strategies. Use the Grails validation mechanism to its fullest. Sanitize your input before saving it down to the DB. Basically, assume your user is out to get you.

What about the Grails Framework?

Thankfully, the Grails core team is wanting to address this, and are asking for feedback from the community. Here's mine...
Update the docs for all Grails versions
Remove examples of the insecure method of creating objects, and replace it with bindData. Move the "security" paragraphs to the top of the section on data-binding. This will make it clear that security is of primary importance, not an after-thought. As I mentioned earlier, the docs are great - this minor tweak will make them even better.
Introduce a dataBindable static property
Grails doesn't have an equivalent of Rails's attr_accessible or attr_protected attributes. But it should. For example:


class User {
//Fields listed here would not be processed bindData, or new User(params)
static dataBindable = ["username", "firstName", "lastName"]

String username
String firstName
String lastName

boolean isActive = false
int failedPasswordAttemptCount = 0

Date dateCreated
Date lastUpdated

static constraints = {
//strict constraints go here
}
}
Crucially, a class with an empty or missing dataBindable property would not be processed at all by bindData or other batch updating mechanisms. This is a harsh breaking change, but makes it clear that the developer must think about security. Since it is a breaking change, there should be a configurable "legacy mode" that could be configured to "true" to enable old behavior for all objects, or it could also be configured to a list of classes or namespaces to enable gradual migration. "dateCreated" and "lastUpdated" should never be updated via bindData or similar.
Update the scaffolding scripts
With the introduction of the dataBindable property, the scaffolding scripts can be smart enough to inspect each domain class and understand which properties should be included in a generated "bindData" statement in the controller code. As a consequence of this, the scaffolding UI would do one of:
  • Not display properties that are not in the "dataBindable" property
  • Update these properties using explicit setters in the controller code, with comments explaining why this is so.

In Conclusion

Grails isn't immune from this kind of vulnerability - in fact it is likely that many Grails apps suffer from it. Use what happened to Github as inspiration for auditing your code, and make sure that you use sensible methods of handling data from HTTP requests. I hope both the Grails framework and its community are able to benefit from this weekend's events.

Thursday 3 February 2011

It is all about Tweet Shortening, not just URL shortening

In short: Break the habit of using cryptic short urls and then adding some context to them manually. Instead, use a shortened version of your [brand] name as your domain, then write each "URL alias" in the style of a short facebook status update. For example:
http://acree.gr/likes_the_VW_ad
If you're tweeting, you can then use the rest of the 140 characters much more efficiently - or not at all.

The Background

A few months ago, I decided to buy a domain name in Greece. Now, I love Greece, but that isn't why I did it. I dit it because I wanted my own, private, URL shortening service: acree.gr. It was primarily an excuse to geek out, but also served as a way to separate myself from millions of other tweeters - my tweets with link would always contain personalized short URLs.

A few days ago, I got around to building it. Sure, I could have bought it, but I wanted the challenge of maintaining it and hosting it too. To make a short story shorter, it is now live. I used it for real this morning, in this tweet. To save you a click, here it is:



After I had written it, I realized that I had saved myself a few characters by using a facebook style status update as the URL. Sure, that is handy, but there is another benefit too. Whenever anyone shares that link, your opinion/fact will be shared immediately, without requiring any additional context or anyone to click on anything. You are helping to ensure your voice does not morph as it is shared. If you are a brand or celebrity, that is pretty powerful. I'm sure someone has done this before, but I haven't seen it. In effect, acree.gr isn't a URL shortening service, it has become my personal Tweet Shortening Service.

Tweet Shortening in Action

The link to this page is http://acree.gr/invented-tweet-shortening. It might be a bit longer than the average bit.ly link, but that URL is working much harder than most. It is not just a reference that goes alongside some context, it IS the context. That can be the tweet on its own. For example, I could tweet about this blog post as follows:
I wrote a blog post about being smarter with URLs: http://bit.ly/fxvEXf
But instead, I think I'll just tweet:
http://acree.gr/invented-tweet-shortening - kind of.
Pompous? Definitely. Inaccurate? Maybe. Concise? Yes. Intriguing? I hope so. Effective? We'll see. (For the record, I don't really believe I've invented anything)

How to start get your own Tweet Shortening Service

In the off chance you want to join in, you can follow these steps:
  1. First of all, you should buy the domain you want to use to identify yourself. You might want to check out iwantmyname.com as a start.
  2. Now, you want to get a white-labeled URL shortener. I rolled my own, but I wouldn't recommend it for most people. It looks like ShortSwitch is a good option. For the majority of individuals, their $4 a month plan should suffice.
  3. Start writing short tweets! I suggest your first should be something like: "http://yourna.me/loves-short-tweets" linking to this blog post of course :-)

The problems with Tweet Shortening

There is one main reason why Tweet Shortening might not work: people will habitually (even automatically) shorten a URL and then manually add context to the cryptic link they've just produced. It is what they have been doing for months/years. Some apps even do it for you (TweetDeck, for example). In the process of this habitual/automatic shortening, the context rich URL will be lost. For example, if you enter the context-rich link to this post (http://acree.gr/invented-tweet-shortening) in TweetDeck, it auto-converts it to http://bit.ly/fxvEXf. Damage done. Thankfully, you can disable this otherwise useful feature. Those smart folks at TweetDeck were also kind enough to make it easy to toggle on and off on a per-link basis.

That's it! I'm enjoying messing around with short tweets, I hope you do too.

Wednesday 10 November 2010

3 Days In: Some RockMelt Tips and Tricks

UPDATE: I have 50 Rockmelt invites, on a first come, first served basis. Click here for your invite! Sorry, all the invites were used in only 45 minutes...

It's been almost 3 whole days since I got hold of RockMelt, a new social media web browser. It has been fun playing with the new features, and I've learnt a few tricks that have made it more fun. I thought I'd share them here. This isn't a complete list, please let me know if you want to contribute your own tip.

Learn the lingo, get an edge

An "edge" is a simply a toolbar that appears at the edge of the screen. RockMelt has two edges out of the box, the friend edge (on the left) and the app edge (on the right).

The friend edge will show you either your friends that are online, or your favorites (more on that later). The app edge integrates with Facebook and other apps to shows you feeds (perhaps it should be called the feed edge?). Common feeds to have here are your Facebook feed, your Facebook notifications and your Twitter stream. You can also consume other feeds such as blogs or news. Read on for a easy way to choose your feeds.

Side note: Graph geeks amongst you may well have though an edge was a relationship between two friends - but no, in RockMelt, it's just a toolbar.

Share a link with a friend, in a couple of clicks

Like a page you're looking at? Want to share it with someone in particular? That's pretty easy.

Drag and drop the URL from the address bar (using the globe or the padlock ) onto your friend in the friend edge on the left. Then choose one of the options:



Type your own message, and your done!

Open search results in way that suits you

Take a close look at the search results pane, and you'll see two features you may find useful:
  • If you would rather open each search result in a new background tab, click on the small plus icon that appears when you move your mouse over each result.
  • If you decide you want to see your search results in one tab, just like a search in most other browsers, then click the "View in tab" link at the top.

I also use the arrow keys to quickly preview each result, then the enter key to go there.

Let RockMelt feed you

After a little while, RockMelt can start suggesting new feeds for you to consume. Use the browser for a few days, then use the the "Add Feeds" button on the app edge (on the right) to have RockMelt automatically suggest feeds for sites you've been using. Click the star next to a feed to add it to the app edge.

Get friendly with the address bar

You can get to your friend's Facebook profile pages easily in RockMelt. Just type their name into the address bar, click on the suggestion, then click on your friend's profile image that appears.

Pick favorites

Chances are you've got a lot of friends. Cut down the noise and choose some favorites. The easiest way is to add favorites is to:

  1. Click on the star in the online/favorite toggle button at the top of the friend edge.

  2. Click the "Show Friends" button towards the bottom of the friend edge.

  3. Use the search box to find the friends you really want to know about, then make them a favorite by clicking the star next to their name.

  4. (Optional) Unfriend everyone else. :-)

Business up front, party in the back

Being so connected to your friends is great, but what if you need to focus on your work and not get distracted? Use the Ctrl-Shift-Space key combo to take the edges off your RockMelt. Think of it as a modern-day Boss Key. If you want to hide just one of the edges you can use the Ctrl-Shift-LeftArrow and Ctrl-Shift-RightArrow to control your "friend edge" and your "app edge" respectively. The same key combo will bring them back.

Use your invites, wisely

RockMelt seems to give out an invite or two every couple of days (so far!) It also very cleverly suggests friends that have requested an invite, so hook a friend up, send them an invite - you're sure to get more. Use the "Open Invites" button to send invites to the friends who you know really want one.

Monday 25 October 2010

virtuwell launches

Note: The opinions expressed in this post (and all others) are my own and are not necessarily representative of those of AKQA, HealthPartners or any party involved in virtuwell. Please read this press release for more information.

Today is a good day. This morning, at around 7am PST, HealthPartners launched an application called virtuwell. It was created in partnership with AKQA (the company I work for) over the last 15 months or so.

The premise of the application is simple. If you or your kids are feeling sick and you are short of time, or perhaps if you don't have insurance, then virtuwell may be for you. It offers online diagnosis and treatment (including prescriptions) at a very affordable cost - it may even be covered by your health plan.

As Technical Architect, virtuwell was definitely the most challenging project of my career. We were responsible for developing the entire application, and had to meet the strict security and quality requirements that come hand in hand with a healthcare app without sacrificing a clean, friendly user interface. On top of that, I've had to master an entirely new technology stack. We have all learned a lot.

As a recent arrival in the USA, I have barely began to understand the challenges facing the health system here, but I am proud to have been part of a passionate and dedicated team that has made strides towards making healthcare more accessible to all.

It is also my mother's birthday.

As I said earlier, today is a good day.

Friday 18 June 2010

Alfresco 3.1.1 and paragraph tags

Right now I am getting to grips with the finer details of an Alfresco v3.1.1 installation. It has been fun*.

Today's quest was all about stopping the TinyMCE plugin that Alfresco uses from wrapping absolutely everything in a <p> tag. Usually I love <p> tags. Way more than I love <br>tags. But not all content entered through a CMS should be wrapped in them.

I found this bug report, which mentioned a rather drastic way of fixing it, but also gave some clues as to another, less invasive, way. The hunt was on. A few hours later (it would have been a few minutes if I had thought to clear my browser cache), I came up with the following:

(DISCLAIMER: The following changes will be lost if you upgrade/replace your Alfresco installation. But since this issue doesn't occur in any other version of Alfresco, that should be ok.)

Step 1: Open up <tomcat>/webapps/alfresco/scripts/ajax/xforms.js

Step 2: Find the definition of alfresco.constants.TINY_MCE_DEFAULT_SETTINGS (it is near the end) and change it to be:

alfresco.constants.TINY_MCE_DEFAULT_SETTINGS =
{
theme: "advanced",
mode: "exact",
plugins: alfresco.constants.TINY_MCE_DEFAULT_PLUGINS,
width: -1,
height: -1,
auto_resize: false,
force_p_newlines: false,
encoding: "UTF-8",
entity_encoding: "raw",
add_unload_trigger: false,
add_form_submit_trigger: false,
theme_advanced_toolbar_location: "top",
theme_advanced_toolbar_align: "left",
theme_advanced_buttons1: "",
theme_advanced_buttons2: "",
theme_advanced_buttons3: "",
urlconverter_callback: "alfresco_TinyMCE_urlconverter_callback",
file_browser_callback: "alfresco_TinyMCE_file_browser_callback",
forced_root_block: false,
force_br_newlines: true
};


Note the two last lines.

When you are done, all you need to do is clear your browser's cache, and go edit some web content in Alfresco. Anything you create from now on will no longer be wrapped in the usually wonderful <p> tags.

*This depends on your definition of fun.

Wednesday 16 June 2010

New version of FBConnectAuth released: 1.0

One year on, I've just released a minor enhancement to the tiny open source project I created called FBConnectAuth - Facebook Connect Authentication for ASP.NET.

This release contains two enhancements:
  • It supports Facebook's new Graph API Javscript SDK (but remains backwards compatible)
  • It works in partially trusted environments
It is specifically targeted at .NET 2.0 (as was the previous release) for the benefit of those who don't have control over their production environment.

Interestingly, I noticed that the new Graph API requires the use of the Facebook Application's "Application ID", rather than "API Key". This means that an example of using FBConnectAuth looks with the Graph API like this:


//Note this is the "app id", not "api Key"
FBConnectAuthentication auth = new FBConnectAuthentication(appId,appSecret);
if (auth.Validate() != ValidationState.Valid)
{
// The request does not contain the details
// of a valid Facebook connect session.
// You'll probably want to throw an error here.
}
else
{
FBConnectSession fbSession = auth.GetSession();

string userId = fbSession.UserID;
string sessionKey = fbSession.SessionKey;

//This is the Graph API access token
//(available only when using the Graph API)
string accessToken = fbSession.AccessToken;

// The above values can now be used to communicate
// with Facebook on behalf of your user,
// perhaps using the Facebook Developer Toolkit

// The expiry time and session secret is also available.
}


If you are interested, go take a look.

Tuesday 11 May 2010

Random Grails tip: Using a DB reserved word as a domain class name in Grails

We recently came across a situation where we couldn't our Grails app was failing because it was trying to create a table with the name of 'Condition', which turns out to be a reserved word in MySQL... We worked around it by changing the name of the table to 'conditions' by using the Grails ORM DSL, but it turns out there is another way.

Backtick to the rescue...
Hibernate allows you to use backticks (`) to indicate that a name should be escaped - you can simply use this in your grails mapping. For example, we could have used:


class Condition {
String property1
String property2
...

static mapping = {
table '`condition`'
...
}
}


To be honest, I'm not sure why Grails and/or hibernate don't escape all table and column names by default (I'm sure there is a good reason) - there is an open JIRA issue in Grails around this very problem...