4 lessons learned from teaching at Rails Girls Berlin

This is just a little post recapping some of my experiences from the last RailsGirls Berlin workshop. By the way, we’ve got a new workshop upcoming this Friday and you can still register! Most of this is a reminder to myself in order to be an even better coach at our next workshop 🙂

1. irb can be great for teaching – but confusing as well

I love irb for teaching. You can show many things quickly and instantly. And you get feedback. You can play. It’s awesome.

However, especially for real beginners it is kind of confusing, even more so if it is the first time that they work with a console. So it’s hard to distinguish what irb is and what the normal console is. In a later mentoring session I also had someone who disliked irb as a whole and rather wanted to write a real program with real files. Everybody likes to learn his/her own way 🙂

However my main take away with irb is the following: Be aware of the nesting! And by that I mean missing parentheses and keywords! You know the result: irb is waiting for the matching keyword/parenthesis. Beginners often don’t notice this and are just wondering why it isn’t working and behaving like with all the others. During our introduction to Ruby this was one of the most common blockers I saw, especially when we started working with blocks. So to get them out of this: Ctrl + C

2. Restart the server after installing a new gem

We all know this one. In order to pick up on some changes the rails server has to be restarted. Although when you’re teaching multiple students it’s sometimes hard to remember. So if a step involving a new gem isn’t working make sure it is installed and restart the server.

3. Save the damn file

Yes save it. Please do. I know it’s the simplest thing in the world but we are sometimes so used to saving our files that it doesn’t even come to mind anymore. I once spent 15 minutes discovering that an unsaved file was the cause of an error. Before that another coach had already spent ~30mins on the same problem. We checked everything until we noticed the little star next to the file name in the tab bar. Then we saved the file, which we had previously looked at like a million times, and everything went well.

4. Explain, but simplify

Explain what which part does but don’t aim for perfection or total correctness. In other words: Lie to simplify. Focus on the most important knowledge. I gave very short introductions to the MVC-pattern (while looking through the code) and refined them until the student seemed satisfied.

And don’t omit the explanation. I know that Rails involves a lot of magic and it might be hard to explain, however I heard from some students that nobody explained the distinct roles of the model, the view and the controller to them. They didn’t know what happened where. This left them really dissatisfied. They’ve built this awesome thing but had no idea how it works.

I hope that these tips might be helpful for you when you are coaching. There are probably some more of these to come after the next workshop 🙂

Secure your Rails apps!

It is time to secure your Rails apps! I mean it is always time to do that, but (as you might have heard) github just got hacked. So if you have a public facing Rails app you should really ask yourself “Can I be sure that our security standards are better than the ones of github?”

What happened?

A russian programmer started an argument about the mass assignment vulnerability and how Rails could provide better protection against it. However the issue got closed again and again as it was basically argued that securing the app is the responsibility of the programmer. So he took a different approach, demonstrating that the vulnerability is even present in one of the biggest and well-known Rails applications: github itself. He managed to make a commit to the Rails master branch, which turned into a lengthy discussion including some memes. He also created a ticket which appears to be from the future by abusing this vulnerability. For the sake of completeness, he informed github of the presence of these vulnerabilities first. You may also want to checkout github’s summary about the incident.

I don’t want to discuss whether his actions were right or wrong, but in the end Rails changed the default for new apps to make this vulnerability less common, which is a good thing to my mind.

What is this mass assignment vulnerability?

The mass assignment vulnerability is described pretty well in the Rails security guide – which you should absolutely read in its entirety! Basically the problem is the following:

Whenever you scaffold generate code for some resource in Rails, which is pretty common, you can see a snippet like this for creating a resource:


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

What this does is create a new user, with all the attributes set to the values that got transmitted from a form and are now in the params[:user] hash. This is very concise as here you can mass assign everything the user entered: name, email, description etc. Cool right? This is why it’s not only generated but also written pretty often. Yeah so far so good.

The problem starts when you got some attributes in your model, which you don’t want your users to have direct access to. For instance the boolean admin, determining if a user is an admin or not. The attacker may use tools to manipulate the html form and hence the transmitted parameters to include the key value pair: admin: true ! So params[:user] may look like this:

params[:user] = { name: 'Evil', email: 'evil@example.com', description: 'I am an admin soon', admin: true}

And all of a sudden our newly created user is an admin and can do everything he/she wants to do – which was totally unintended by the developer! Of course this also works with updating records and not just with creating them.

This issue is actually pretty damn well-known and was also a big story during the start of the Diaspora social network (among many other vulnerabilities).

Holy sh**! What can I do to protect my app?

Well in general it is pretty easy to protect against this kind of attack you just have to add attr_accessible to all your rails models. This white lists the attributes, that can be assigned during mass assignments. Everything else can not be assigned during mass assignments. So for our example this would look like this:

class User < ActiveRecord::Base
  attr_accessible :name, :email, :description
  # rest of class omitted
end

Notice that admin is missing from the attributes after attr_accessible. That’s because we don’t want to have it mass assigned during creation/update. So now go ahead and secure your Rails applications, or stay for the pro-tip…

Pro-tip: Use Brakeman

Brakeman (can also be found on github) is a static analysis tool (fancy term for: looks at your code, doesn’t execute it), looking for vulnerabilities. So it is a vulnerability scanner for Ruby on Rails. It takes a good look at your source code and informs you of any found security vulnerabilities including the confidence of the scanner that this is indeed a problem (e.g. not a false positive). It seems to find mass assignment vulnerabilities very reliably and it also informed me of a possible Cross-site scripting (XSS) vulnerability in my Rails version (3.2.0) and recommended an update to 3.2.2, as this version fixes the problem. So it is also pretty up to date and I can only recommend it. Now go ahead and gem install brakeman or add it to your Gemfile.

However the default output isn’t very beautiful on my system and hides many important parts so I’d recommend you to run:

brakeman -f html -o brakeman.html path/to/app

For a bit prettier html output. Hope that this helps. And don’t forget to add this brakeman.html to your gitignore. Oh by the way: they also have a plugin for Jenkins/Hudson.

So now go ahead and make your Rails apps more secure!

Resources page online

Hey folks,

just a quick post: I just created a page containing many of the resources I stumbled upon while learning about programming, software engineering, web development, that I found extremely useful. Most of them are free so go and check the resources section out!
This list is also a good indicator of what I might write reviews about in the future.

I hereby want to thank each and every author of the referenced material for their contributions. This is my way of saying thank you, I hope that through my blog some more people find those great resources. I also hope that I can help all the people who are looking for resources in order to learn about Ruby, Rails, web development or any other stuff.

Also if you feel like there are any good resources in the form of guides or tutorials missing please let me know (via comments or ways described in the About section) . I would enjoy this and feel free to share this if you think someone might have use for it.

So once again: Go and check out the Resources section (or simply click on the link on the top right!).

I hope that this may be of use to you.

Tobi