practice

DoI: 10.1145/1941487.1941503

Article development led by queue.acm.org

A Ruby on Rails app highlights some serious,
yet easily avoided, security vulnerabilities.
BY PatRICK mCKenzIe
Weapons
of mass
assignment

In May 2010, during a news cycle dominated by users’ widespread disgust with Facebook privacy policies, a team of four students from new York University published a request for $10,000 in donations to build a privacy-aware Facebook alternative. The software, Diaspora, would allow users to host their own social networks and own their own data. The team promised to open-source all the code they wrote, guaranteeing the privacy and security of users’ data by exposing the code to public scrutiny. With the help of front-page coverage from the New York Times, the team ended up raising more than $200,000. They anticipated launching the service to end users in october 2010.

on September 15, Diaspora (https://joindiaspora. com/) released a “pre-alpha developer preview” of its source code ( https://github.com/diaspora/diaspora). I took a look at it, mostly out of curiosity, and was struck by numerous severe security errors. I spent the next day digging through the code locally and trying to

get in touch with the team to address them, privately. The security errors were serious enough to jeopardize the goals of the project.

This article describes the mistakes that compromised the security of the Diaspora developer preview. Avoiding such mistakes via better security practices and better choice of defaults will make applications more secure.

Diaspora is written against Ruby on Rails 3.0, a popular modern Web framework. Most Rails applications run as very long-lived processes within a specialized Web server such as Mongrel or Thin. Since Rails is not thread-safe, typically several processes will run in parallel on a machine, behind a threaded Web server such as Apache or nginx. These servers serve requests for static assets directly and proxy dynamic requests to the Rails instances.

Architecturally, Diaspora is designed as a federated Web application, with user accounts (seeds) collected into separately operated services (pods), in a manner similar to email accounts on separate mail servers. The primary way end users access their Diaspora accounts is through a Web interface. Pods communicate with each other using encrypted XML messages.

Unlike most Rails applications, Diaspora does not use a traditional database for persistence. Instead, it uses the MongoMapper ORM ( object-relational mapping) to interface with MongoDB, which its makers describe as a “document-oriented database” that “bridges the gap between key/ value stores and traditional relational databases.” MongoDB is an example of what are now popularly called NoSQL databases.

While Diaspora’s architecture is somewhat exotic, the problems with the developer preview release stemmed from very prosaic sources.

 

security in Ruby on Rails Web application security is a very broad and deep topic, and is treated in detail in the official Rails security guide (http:// guides.rubyonrails.org/security.html)