May/June 2018 issue of acmqueue The May/June issue of acmqueue is out now



Security

  Download PDF version of this article PDF

ITEM not available

acmqueue

Originally published in Queue vol. 9, no. 3
see this item in the ACM Digital Library


Tweet



Related:

Arvind Narayanan, Jeremy Clark - Bitcoin's Academic Pedigree
The concept of cryptocurrencies is built from forgotten ideas in research literature.


Geetanjali Sampemane - Internal Access Controls
Trust, but Verify


Thomas Wadlow - Who Must You Trust?
You must have some trust if you want to get anything done.


Mike Bland - Finding More Than One Worm in the Apple
If you see something, say something.



Comments

(newest first)

Don Park | Wed, 27 Apr 2011 17:25:25 UTC

Weapons of Mass Distraction

I have exclusive access to early-release versions of this paper (not true), and there are many serious, yet easily avoided typos. This paper never had the luxury of being both publicly available and impossible to read at the same time.

** end sarcasm **

A core tenet of open source software and agile development, IMHO, is to release early and often in small increments right from the start. A justification for releasing early when others might deploy it publicly is to look at whats at risk. The updates and photos put on this service have arguably no value. Reading user records for an already encrypted password and email address is probably the most sensitive. The encrypted password has no value so that leave email addresses. A low-enough risk especially when compared to the benefits of getting the source code out to a community of software developers as fast and as early as possible to get development moving as quickly as possible.

Overall, this paper is a great writeup of common mistakes in writing rails code.


Ryan | Wed, 27 Apr 2011 12:52:11 UTC

It's pretty safe to say that the Diaspora developers are (or at least were) pretty much novices when it comes to Rails development - they've made plenty of stupid mistakes which are easily avoidable - infact Rails makes it easy to avoid them!

For example, attr_accessible / attr_protected have been around for years and protect against mass-assignment - even MongoMapper (not part of Rails itself) has implemented them: http://mongomapper.com/documentation/plugins/accessible.html

When it comes to finding objects in the database, they can scope them to a particular user account using something simple like current_user.albums.find(params[:id]). Why they are even using 'find_by_id' instead of just 'find' (which effectively does the same thing and is the most common use) surprises me further.

Of course, since this article was written they may have corrected their mistakes. I certainly hope so because it's embarrassing to the Rails community.


Sandro | Fri, 01 Apr 2011 00:21:50 UTC

Quote: "No amount of improving frameworks, however, will save programmers from mistakes such as forgetting to check authorization prior to destructive actions."

Not entirely true. A web framework based on capability URLs requires no authorization checks because the authorization is encapsulated in the unguessable URL itself. This is the power of combining designation with authorization. See the Waterken server for an example.

Of course, this approach has its own problems, mainly on the user end when interfacing with such URLs.


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.