Best practice: How to obfucate key in URL? Use AUTOINT vs. GUID, UUID, SequentialGUID?

[Thorsten Eilers]

Best practice: How to obfucate key in URL? Use AUTOINT vs. GUID, UUID, SequentialGUID?

Good morning,

Up to now, I use in almost all tables an autoincrementing INT as my primary key.
In my opinion this is perfectly OK for supporting tables, but I don’t want to have an easy guessable key transmitted and exposed via the URL to the user. I don’t want the users see, how many items for example are in parts of my database. Prevent them from editing the key in the URL by counting up, for example.

What is Best Practice regarding cfwheels to prevent this?
Change INT (autoincrement) to

1. GUID as primary key, created by SQL server

2. UUID created by the app via coldfusion

3. use INT internally as primary key, but have a second key (GUID or UUID) in another row and use this key for URLs, has it exposed to the public?

4. Use chwheels inbuild URL key obfuscation? I think it’s not that strong?

Or use a sequential GUID instead of a normal GUID? Some say it’s better to index, therefore faster?

Also I have a third column, called publicID. It’s in the moment a CHAR(10) type. It’s created by an algo, does only have easy transmittable characters by phone. I use it to expose it to users to refer to an item. It’s like an item number. Is this good practice? I create a new publicID, check, if it’s already in the database. If yes, I create a  new one. Will this slow down the db very hard, if the database fills up and the occurency of already existing publicIDs will increase?

Thanks for your attention.
How do you handle this?
Any comment is appreciated
Thorsten

[Tom King]

Re: "4. Use chwheels inbuild URL key obfuscation? I think it’s not that strong?" - don't do this, a) it's being dropped in 1.2, and b) it's guessable, i.e not unique.

T

[tpet...@gmail.com]

<soapbox>

i see no reason to obfuscate a key in the url, its totally worthless for a security perspective. if you're worried that someone can modify data in your database by incrementing the value in the url, then you're got WAAAAY bigger problem in your application.

I think this comes from a lot of tutorials that i see out there that demonstrate retrieving a record from the database like so:

<cfset meeting = model("meeting").FindByKey(params.key)>

That statement right there is completely WRONG! The right way to do it is to not only use the key (the primary key) of the object when retrieving the record, but also the relation to the user (the foreign key):

<cfset meeting = model("meeting").FindOne(where="meetingid = #params.key# AND userid = '#session.userid#'")>

By doing that, even if the user is logged in, they can only retrieve records that belong to them.

</soapbox>

[Chris Geirman]

Tony,

What about the case where the user is an admin, and hence shouldn't be restricted to seeing just their data, but all user's data?

Chris

--
You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/V1QE6yDr6CcJ.

To post to this group, send email to cfwh...@googlegroups.com.
To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cfwheels?hl=en.

[tpet...@gmail.com]

of course, but that isn't too hard to do:

<cfif session.isAdmin>

  <cfset meeting = model("meeting").FindOne(where="meetingid = #params.key#")>

<cfelse>

  <cfset meeting = model("meeting").FindOne(where="meetingid = #params.key# AND userid = '#session.userid#'")>

</cfif>

[Chris Geirman]

well played sir, well played

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/FqJRp-0s30gJ.

[Thorsten Eilers]

Morning,
thanks for your input.
And sorry I made my point not clear enough. I will try to explain it in more detail.

Tony, your are right, reagarding security to prevent showing a record an integer is absolutely fine, if you take measures like you provided.

I am thinking more about the case for example the number of all/new users for a given timeframe has to be obfuscated.

Let's say on 1.1.2013 there are 100 users in the database and the url for the latest entry is like ?userID=100.
On 1.2.2013 the url is like ?userID=187 for the latest entry. So by just looking at the userID someone would knwo. Aha he's got 87 new users in february.

For some cases I would like to prevent this.

Therefore I am asking what's the best way to do this?
Via
- a UUID of Coldfusion
- a GUID of the database
- a Sequintial GUID of the database to allow better indexing

To have
- internally the ID as int autoincrement
- a second column for the UUID?

What do you think?
Regards
Thorsten

[tpet...@gmail.com]

a guid column would work just fine.

seriously though, i really think that you're over thinking this and creating more work for yourself then need be.

given your example, the only way someone can see and search for the all user records is if they controlled the site because the site was written for them. in that case the scenario you present is mute since who care if they can figure out. if the site is a multi-user environment, then the id would be assigned across all users so the scenario would never happen.

plus, think about this. don't you think the site administrator is going to want some sort of report that tells them how many people joined their site for a given range and criteria? that report right there would trump what you're trying to prevent.

[Cathy Shapiro]

I agree with Tony, but wanted to earn my chocolates, so I wanted to
bring up some solutions that are built into wheels.

One is to use routes so you are never showing ids in the first place
on your public facing site.
Instead of users/show/32 you can create a route to show them by name
or by a UUID
Chris has a great tutorial on this you can follow (episode 9).

The other thing you can do is create a filter so the only people who
can edit the record are people who have permission.
So in your controller init you could have something like:
<cfset filters(through="loginRequired", only="create,update,delete")>
and then you can add the function:
<cffunction name="loginRequired" returntype="void" output="false">
<cfif NOT structKeyExists(session, "currentuser")>
<cfset redirectTo(route="login")>
</cfif>
</cffunction>

> --
> You received this message because you are subscribed to the Google Groups
> "ColdFusion on Wheels" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/cfwheels/-/yOIJx2Q2H-0J.

>
> To post to this group, send email to cfwh...@googlegroups.com.
> To unsubscribe from this group, send email to
> cfwheels+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cfwheels?hl=en.



--

Flash Pro Design
4646 Poplar, Suite 517
Memphis, TN 38117

Phone: (901) 921-1767
Fax: (901) 685-9054

http://www.flashprodesign.com

[Thorsten Eilers]

Hi Cathy, I think you definetly deserve the chocolats. ;-)
I will have a look at Episode9 from Chris regarding the routes.

For users logged in I setup some filters.

Thorsten

[George]

<soapbox 2.0>

Obfuscating URLs is not as ridiculous as some responding would have you to believe. The obfuscated key is not meant to prevent hacking, it is to prevent monkeying. The URL is there on top of the page always staring your user in the face. By obfuscating it, you make it a little less intuitive, thus mis-directing those who stayed at a holiday-inn express last night from thinking they are smarter than they really are. The people who are the largest problem on most sites, are not hardened anon hackers, their doups who think they know how a systems works because they can see it work in the URL. Those who really know security, know that everything helps and nothing is 100%. You harden your targets both visually and programmaticaly but please don't incorrectly tell people that is worthless. It may be incomplete, but not worthless.

Also, I don't think programmaticaly is a word, but I use it anyway!

</soapbox 2.0>

[Chris Geirman]

well said George

--

You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/S4yoJN-Dp6IJ.

[tpet...@gmail.com]

security by obscurity is absurdity

[George]

fortune cookie programming

[Jacob]

Seems like you have this solved, but here's a good piece on securing query param data: https://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL%27s
Basically it describes two methods. Tamper proofing by passing origVal and hash of orig value then checking the hash server side and then symmetrical encryption which also obfuscates the param value.

[Risto]

I always just use GUID/UUID if you just want to make it difficult for someone.