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