4 ms·
In the case of Diaspora it was a less subtle and more obvious issue. They just weren't checking for authorization, as in: def destroy @album = Album.
by lgeek 15y ago
In the case of Diaspora it was a less subtle and more obvious issue. They just weren't checking for authorization, as in:
def destroy
@album = Album.find_by_id params[:id]
@album.destroy
[...]
end
when the second line should have been something like:
user.albums.find_by_id params[:id]
But, well, they're both pretty bad mistakes.
- zdouglas 15y agoPalpability is in the eye of the beholder. There's a lot of talk in the GH issue comments dismissing GH's "obvious" failure of not using `attr_accessible`.
- patio11 15y agoNope, Diaspora also had this exact issue, which would let you use anything where a params hash updated a user model to e.g. overwrite their credentials or encryption keys. The specific exploitable example I found would have let you do it even if they had been checking authorization to update objects properly, because the attacker could reassign his own objects as the victim's objects with arbitrary attack payloads, one of which being sufficient to compromise the victim's account. When I wrote a journal article about it my recommendation was that Rails ship with ActiveRecord::Base.attr_accessible(nil) by default, because otherwise vulnerabilities of that nature were virtually inevitable.