Hacker News new | past | comments | ask | show | jobs | submit login

Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications.

Example:

XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper (h), which you could use to escape content that you knew to be vulnerable.

Unfortunately, many Rails users did not use this feature in all places they should have used it. As a result, many applications (Twitter included) suffered from whack-a-mole XSS vulnerabilities.

We were unable to solve this problem in the 2.x branch, because automatically escaping all text being put onto the page would be a massive breaking change and would break every app in existence.

Further, simply escaping all text would not really solve the problem. For example, the "<form>" tag generated by Rails itself should not be escaped, while any of its contents or attributes provided by the application should. Asking the user to take on the responsibility to mark Rails-generated content as not needing escaping would reintroduce the same problem we had before: people would "unescape" things too eagerly, and apps would tend to have vulnerabilities.

The solution was to release a plugin for Rails 2.3 users (rails_xss) and change the default in Rails 3. It isn't perfect: there are still cases where applications have to mark strings as "safe", and applications that have to do so often might have the same problem, but I think we did a good job, all things considered.

This case is quite similar. Rails provides all the tools necessary to have a secure application (attr_accessible is the equivalent of h), but many apps don't use it correctly (or at all). In short, a Rails security default seems to be wrong, insofar as "wrong" means that many people fail to use the security feature, causing their applications to be vulnerable.

As with the XSS feature, fixing this problem requires some thought. Simply changing the default would break a lot of applications in the wild. Like XSS, it's probably correct to do so anyway here. However, like XSS, we should make sure that we have done everything we possibly can to mitigate the additional cost associated with complying with the new default. If it's too painful, many people will overeagerly bypass the feature, reintroducing the very issue we were trying to protect them from.

In this case, I have proposed a solution that I think will mitigate a lot of the problem (https://gist.github.com/1974187), and we will likely ship it as a Rails 3.2 plugin. This will allow us to gather feedback about unexpected consequences and ensure that when we change the default for Rails 4 (which has not even shipped a prerelease yet), it actually mitigates the security problem in the vast majority of Rails applications.




Every C programmer has the tools they need to not create buffer overflows _and yet buffer overflows are abundant_.

Saying "we'll provide the tools and insist that developers use them safely and securely" is a bullshit answer, and always has been.

You're either secure by default, or not at all. In this case, not at all.


These issues need to be nipped very early on before they get too big to handle. Microsoft was stuck in this situation for many years because they had decided to favour compatibility over security. Rails now has a wide footprint on the web, and it all makes it even more important to enable it to be properly locked down.

I hope this marks a turning point in the way the Rails team think about security.

ps At least Rails no longer allows web crawlers to delete resources by issuing GET requests.


What do you think of doing it this way http://blog.ricodigo.com/blog/2012/03/04/an-alternative-to-a...?


I don't necessarily like having to have every ORM/data library have to know about this concern...


I don't like the suggestion. It enforces a 1:1 relationship between controller and model.

I'd rather have the model and the ORM be pulled apart and the model make this distinction.

Or create another class that knows how to safely pull values out of a params list and use it to create a model.

But it's bad enough that the controllers "look" like they belong to a model in default Rails generators. This creates a certain amount of laxity in programmer's thinking. It boxes their thinking in instead of letting their thinking go free.


@wycats any chance of you creating a screencast of how to tackle Rails security from your experience with Merb/Rails?

Thanks again for your hard work and being a public voice on the issue.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: