Exposing id'd

Rails
1

I have been working on a small app that started with some scaffolding.
Some of my actions still have the structure where the id’s of things are
passed on the url for gets.

Whats the best way to avoid the security problems that this creates?

I am sure that there are many pages written on this topic but I guess I
have been searching for the wrong things.

Thanks

Gareth

2

On 1/7/06, Gareth R. [email protected] wrote:

I have been working on a small app that started with some scaffolding.
Some of my actions still have the structure where the id’s of things are
passed on the url for gets.

Whats the best way to avoid the security problems that this creates?

I am sure that there are many pages written on this topic but I guess I
have been searching for the wrong things.

You can use Routes to remove those id values (though I wouldn’t call
them a security problem.)
http://manuals.rubyonrails.com/read/chapter/65

Also, if you define “to_param” in your models, you can make setting up
those routes even easier:
http://dev.rubyonrails.org/ticket/812

3

Wilson B. wrote:

On 1/7/06, Gareth R. [email protected] wrote:

I have been working on a small app that started with some scaffolding.
Some of my actions still have the structure where the id’s of things are
passed on the url for gets.

Whats the best way to avoid the security problems that this creates?

I am sure that there are many pages written on this topic but I guess I
have been searching for the wrong things.

You can use Routes to remove those id values (though I wouldn’t call
them a security problem.)
Peak Obsession

Also, if you define “to_param” in your models, you can make setting up
those routes even easier:
http://dev.rubyonrails.org/ticket/812

The issues that I am concerned about is just having users be able to
hack a url to give them access to something that they shouldnt have
access to. I probably should check that the current user has permissions
to see the thing that they are lookin for in each of the actions.

How do other people deal with this ?

Gareth

4

Gareth R. wrote:

The issues that I am concerned about is just having users be able to
hack a url to give them access to something that they shouldnt have
access to. I probably should check that the current user has permissions
to see the thing that they are lookin for in each of the actions.

How do other people deal with this ?

As a rule, security through obscurity is a bad idea. It’s better than
nothing, but not by much. If you are concerned about who sees a record,
you need to set up some method to check and ensure that the user is
actually entitled to see it. Exactly how you do that will depend on
your application and user model.

5

Kevin O. wrote:

Gareth R. wrote:

The issues that I am concerned about is just having users be able to
hack a url to give them access to something that they shouldnt have
access to. I probably should check that the current user has permissions
to see the thing that they are lookin for in each of the actions.

How do other people deal with this ?

As a rule, security through obscurity is a bad idea. It’s better than
nothing, but not by much. If you are concerned about who sees a record,
you need to set up some method to check and ensure that the user is
actually entitled to see it. Exactly how you do that will depend on
your application and user model.

Agreed. I was planning on doing both but not sure how or if its possible
to avoid exposing the ids urls.

Gareth

6

In general, you should assume that users can get to any URL in your app.
As
Kevin suggests, you need to write code to stop them WHEN they get to the
right URL, rather than just preventing them from knowing what the right
URL
is.

For example, the Salted Login code uses a before_filter in each
controller
that should be protected. A user can only got to a protected URL if
they’re
logged in.

Obviously, you want something more granular than that- it’s not just
that
they’re logged in, it’s that they have certain rights on the particular
thing they’re viewing or editing. Again, as Kevin suggests, you need to
decide what those rights are and how they work for your app, and then
code
it.

7

Gareth R. wrote:

Agreed. I was planning on doing both but not sure how or if its possible
to avoid exposing the ids urls.

Gareth

Keep in mind that users can bookmark pages if you put the id in the URL.
If you want them to be able to do that, you need to keep the id’s there.

One approach I have used in the past to hide the id is to stuff it into
the session hash.

8

On Jan 7, 2006, at 3:40 PM, Gareth R. wrote:

I am sure that there are many pages written on this topic but I
http://dev.rubyonrails.org/ticket/812

The issues that I am concerned about is just having users be able to
hack a url to give them access to something that they shouldnt have
access to. I probably should check that the current user has
permissions
to see the thing that they are lookin for in each of the actions.

I have a ticket in, with code attached, to provide one answer to this
question:

http://dev.rubyonrails.org/ticket/2408

–
– Tom M.

9

On 1/7/06, Gareth R. [email protected] wrote:

access to. I probably should check that the current user has permissions
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

One thing to keep in mind is to always use associations for finding
things when you’ve got them set up. For example, you have a User
model and an JournalEntry model, and a User has many JournalEntries.
If you want users to only be able to access their own journal entries,
just be sure to access the entries through the user object. So
something like this in your controller:

entry = session[:user].journal_entries.find(params[:id])

This ends up being the same as
JournalEntry.find_by_id_and_user_id(params[:id], session[:user].id),
but it’s obviously way more concise and logical.

Anyway, that’s a pretty simple way of making sure that people don’t
get to view something they shouldn’t. As far as restricting access to
controllers and individual actions, you can look into using the
UserEngine which implements basic RBAC.

Pat