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)