and the Open Web Application Security Project (OWASP) list of Web application vulnerabilities (http://www.owasp. org/ index.php/Top_ 10_2007), which would have helped catch all of the issues discussed in this article. While Web application security might seem overwhelming, the errors discussed here are elementary and can serve as an object lesson for those building public-facing software.

IlluSTra TIon By SerGIo alBIaC

A cursory analysis of the source code
of the Diaspora prerelease revealed on
the order of a half-dozen critical errors,
affecting nearly every class in the sys-
tem. There were three main genres, de-
tailed below. All code samples pulled
from Diaspora’s source at launch
(note: I have forked the Diaspora pub-
lic repository on GitHub and created a
tag so that this code can be examined:
https://github.com/patio11/diaspora/
tree/diaspora_launch) were reported to
the Diaspora team immediately upon
discovery, and have been reported by
the team as fixed.

 

authentication ≠ authorization: the user Cannot Be trusted The basic pattern in the following code was repeated several times in Diaspora’s code base: security-sensitive actions on the server used parameters from the HTTP request to identify pieces of data they were to operate on, without checking that the logged-in user was actually authorized to view or operate on that data.

#photos _ controller.rb def destroy

@album = Album.find _ by _ id params[:id]

No authorization check.

album.destroy flash[:notice] = “Album

#{@ album.name} deleted.” respond _ with :location =>

albums _ url end

 

For example, if you were logged in to a Diaspora seed and knew the ID of any photo on the pod, changing the URL of any destroy action visible to include the ID of any other user’s photo would let you delete that second photo. Rails makes such exploits very