Preventing user from changing ID number in URL

Howdy all, My help desk site I am building uses a URL variable for the ticket ID when the admin or user is viewing details, and I seem to recall reading somewhere that you can write your code so that if the user decides to change the ID number in the URL, it will default to the one they originally opened, thus keeping the user from viewing other tickets unless they go back and click on another one to open. Does anyone recall where this example is? I did a quick search but could not find it. Thanks, Bruce

Store it in session.TicketID and don't pass it along via the URL at all. ----- Excess quoted text cut - see Original Post for more -----

This isn't exactly what you were asking about, but if your main concern is someone getting to see the details of a ticket that they shouldn't see, I recommend using an UUID for either the PK or a solid Secondary Key (if you are already using an auto incrementing Int as the primary key). Then pass the UUID through the URL, no one will likely ever find another string that matches your ticket numbers. =] -- Alan Rother Adobe Certified Advanced ColdFusion MX 7 Developer Manager, Phoenix Cold Fusion User Group, AZCFUG.org

That would work except that they get to the ticket via a link. I guess I could make it into a button link and pass the session variable that way. Phillip Vector wrote: > Store it in session.TicketID and don't pass it along via the URL at all.

Well, I'm assuming that you have a set of links and the user clicks on one and it goes to the ticket.. Right? If so, once the link is clicked, do another query (the same that brought up his list of tickets) where ticketID = #url.ticketid# If it's showing up as no records, boot him out, cause a BSOD on his computer and send an email via cfmail to the paramilitary strike force to his house. :) ----- Excess quoted text cut - see Original Post for more -----

> My help desk site I am building uses a URL variable for the ticket ID > when the admin or user is viewing details, and I seem to recall reading > somewhere that you can write your code so that if the user decides to > change the ID number in the URL, it will default to the one they > originally opened, thus keeping the user from viewing other tickets > unless they go back and click on another one to open. Does anyone recall > where this example is? I did a quick search but could not find it. Can the server tell the difference between someone clicking a link, and someone entering an url in the address window of the browser?  That's what you have to contend with.  My hunch is that it's just an http request either way, so there's really not a way to do what you're looking for. -- Josh

>Can the server tell the difference between someone clicking a link, and >someone entering an url in the address window of the browser?  That's what >you have to contend with.  My hunch is that it's just an http request either >way, so there's really not a way to do what you're looking for. Exactly. I usually just add code on the server-side that double-checks the ID and make sure the user has access to it, and if not, bumps them to an error page. --- Mary Jo

I would suggest: Do a search on the url id and verify the current user is allowed to access it, if they are then set a session variable like 'session.lastticket', if they are not allowed, then do a search for the 'session.lastticket' if it exists.  Last resort cflocation them to the home page. This won't stop them from changing the url variable, but it will stop them from viewing unauthorized info. William ---------------------------------- William Seiter ColdFusion Web Developer / Consultant http://william.seiter.com Have you ever read a book that changed your life? Go to: http://www.winninginthemargins.com Use PassKey: GoldenGrove You'll be glad you did. ::-----Original Message----- :: ::Sent: Tuesday, May 06, 2008 3:21 PM ::To: CF-Talk ::Subject: Preventing user from changing ID number in URL :: ::Howdy all, ::My help desk site I am building uses a URL variable for the ticket ID ::when the admin or user is viewing details, and I seem to recall reading ::somewhere that you can write your code so that if the user decides to ::change the ID number in the URL, it will default to the one they ::originally opened, thus keeping the user from viewing other tickets ::unless they go back and click on another one to open. Does anyone recall ::where this example is? I did a quick search but could not find it. :: ::Thanks, :: ::Bruce :: ::

How about adding a querystring hash to your querystring. Follow me on this... Your links will change from href="myPage.cfm?id=5" to href="myPage.cfm?#buildLink("id=5")#". The buildLink (or whatever you call it) UDF will make a hash of your querystring plus a local salt, plus a session salt. buildLink will add the hash to your querystring, and produce something like this: href="myPage.cfm?id=5&secure=65ARE634HN4S564GA6" But that's not all... Have buildLink also encrypt your URL. Even the basic cfusion_encrypt() function will work. Your new link will be like href="myPage.cfm?9867BNS85NS95H9R86HS87R6H85S7FD8G" Then just add a filter on the other end to decrypt your encrypted query string, recreate the URL scope variables and verify that the string, minus the "secure" param (the hash) is the same as those other values, plus your salt values, hashed. Even still, it will not be 100% unhackable, but it will be closer. -- nathan strutz http://www.dopefly.com/ ----- Excess quoted text cut - see Original Post for more -----

Obscurity still isn't security though.  Better yet, run whatever security checks are necessary when displaying a ticket to verify the person logged in should be able to view it.  That really is the only way to be sure sensitive data isn't exposed to others.  All someone would need was a copy of the link or a network sniffer to pull out ids of tickets other people were viewing even if they were obfuscated (UUID's). ~Brad This isn't exactly what you were asking about, but if your main concern is someone getting to see the details of a ticket that they shouldn't see, I recommend using an UUID for either the PK or a solid Secondary Key (if you are already using an auto incrementing Int as the primary key). Then pass the UUID through the URL, no one will likely ever find another string that matches your ticket numbers.

Yeah, that would work. When they log in, their role is stored in a session variable so I could just do the check that way. Brad Wood wrote: ----- Excess quoted text cut - see Original Post for more -----

> Yeah, that would work. When they log in, their role is stored in a >  session variable so I could just do the check that way. That's the ticket! Then all you gotta watch out for is XSS session stealers...  :-P -- Limit the vectors whenever possible... /me tells himself

I agree with brad in that only those people with access to the ticket should see it, then it doesnt matter if they manipulate the id it gets them nothing. Having role based security or resource based security will help prevent unauthorized users from manipulating the url to view a ticket that they shouldnt have access to.  That does tend to make things a bit more complicated though when designing your security framework. -- Gary Gilbert http://www.garyrgilbert.com/blog

> Obscurity still isn't security though.  Better yet, run whatever > security checks are necessary when displaying a ticket to verify the > person logged in should be able to view it.  That really is the only way > to be sure sensitive data isn't exposed to others.  All someone would > need was a copy of the link or a network sniffer to pull out ids of > tickets other people were viewing even if they were obfuscated (UUID's). Amen. There really is no problem with passing an int id in the url as long as some other variable to identify the user is also passed in and the neccessary security checks are performed. In SmarterTicket, the id is the user's email address. So a combination of user identity and ticket identity is required to view the ticket. You can choose to use a UUID or continue with using your plain ol int pk. I'd guess using a UUID would be better here; obscurity + security = obsecurity! Dominic -- Blog it up: http://fusion.dominicwatson.co.uk

This is really the only acceptable solution. If you care about security, you need to verify every user action. >Yeah, that would work. When they log in, their role is stored in a >session variable so I could just do the check that way. > >Brad Wood wrote:

Obscurity still isn't security though.  Better yet, run whatever security checks are necessary when displaying a ticket to verify the person logged in should be able to view it. ~Brad -- That's what we do. Each of our invoices is referenced in an invoice table by a few different pieces of data, the most important of which is the invoice number and the customer's account number. The ID in the url gets checked to see if the logged in account number is in the same row as the invoice and if not they get a "not a valid invoice under your account" error. Mike

> Obscurity still isn't security though.  Better yet, run > whatever security checks are necessary when displaying a > ticket to verify the person logged in should be able to view > it.  That really is the only way to be sure sensitive data > isn't exposed to others. This really is the only correct answer. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Training: Adobe/Google/Paperthin Certified Partners http://training.figleaf.com/ WebManiacs 2008: the ultimate conference for CF/Flex/AIR developers! http://www.webmaniacsconference.com/