Hobo Security Hole
Reported by umur.ozkul (at gmail) | December 2nd, 2010 @ 09:54 PM
Using the curl command a hacker can fill up your hobo web site with unwanted data. Create permissions are not working on direct posting in Hobo 1.0.1
I verified the problem using webrat, capybara in selenium mode, functional tests and from command line using curl.
I found a fix
I made a change in the file lib/hobo/model_controller.rb
def hobo_create(*args, &b)
options = args.extract_options!
attributes = options[:attributes] || attribute_parameters || {}
if self.this ||= args.first
this.user_update_attributes(current_user, attributes)
else
self.this = new_for_create(attributes)
# this.save #Original Line
this.with_acting_user(current_user) {this.save} #SUGGESTED FIX
end
create_response(:new, options, &b)
end
Using "this.with_acting_user(current_user) {this.save}" instead of "this.save" fixes the problem.
Why people are not encountering this problem? Because using the application in the web interface hides the problem. If you are a guest and only admin is allowed to create then you don't see the admin button and you cannot post. However somebody can execute a curl command and fill up your whole database.
I am using Hobo 1.0.1 . I did not verify this condition with newer versions of Hobo.
This problem was referred in the previously invalid ticket #879 claiming that the problem exists only in the functional testing environment.
Comments and changes to this ticket
-
-
Betelgeuse December 3rd, 2010 @ 07:59 AM
I tried testing this with curl and got stopped by rails CSRF protection. Can you give the curl command you used so I don't need to figure out how to go around CSRF?
-
umur.ozkul (at gmail) December 3rd, 2010 @ 12:38 PM
I did try without CSRF protection
#application.rb self.allow_forgery_protection = false -
umur.ozkul (at gmail) December 15th, 2010 @ 02:20 AM
This is my work around at the moment: http://conceptspace.wikidot.com/blog:hobo-security-hole
I am patching hobo inside my rails project so that it will deploy OK. -
Matt Jones December 15th, 2010 @ 06:06 PM
Couple notes on this:
-
should probably use
this.user_save(current_user)as this encapsulates thewith_acting_user/savepattern. -
if Guest users can't hit the write actions (new/create/edit/update), you should probably be including
before_filter :login_required, :except => [:index, :show]in your controllers. This will both give a more reasonable behavior (redirect to login instead of showing 'Permission Denied') and trigger the builtin support for HTTP Basic authentication (for an XML API, for instance).
-
-
Matt Jones December 15th, 2010 @ 06:44 PM
- State changed from “new” to “resolved”
On further review, this was caused by this commit:
https://github.com/tablatom/hobo/commit/e2976ee734d47bf0968f96e168b...
The call to
this.savewas essentially moved from insideuser_update_attributes(where it triggered a create permission check) to outside, whereacting_userwas nil and no create permission fired. This is now fixed in 1-0-stable, master and the rails3 branch.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Domizio Demichelis
Matt Jones