> -----Original Message----- > From: Michael Ross [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 5:23 PM > To: CF-Talk > Subject: RE: Hacking" a shared SQL server > > > Coming out of left field here as I haven't read everything but > what about in your code getting a random number, checking to make > sure its not in your table then insert it. Just run a loop.
I think this is not a good idea -- talk about resource intensive. I've always done things assuming that all URL and FORM variables can and will be changed by the end user at some point, so if I have something like http://www.mysite.com/mypage.cfm?ProductID=463, I follow the best practices such as using cfqueryparam for any variables I am going to plug-in to my SQL, or by using stored procedures. The first example would be a typical end user surfing a site. They can remove the ProductID, add SQL to create a SQL injection attack, change the value of ProductID to a non-numeric value; it doesn't matter because my code will handle all of that. But what about an administration section where you trust the users a bit more (yeah, right...) What if you had the same URL except that ProductID 463 was being called up to edit? Say you stick the ProductID in a hidden form field and the end user cooks up their own form with a different ProductID but the same information. Now you have duplicate products with two different ProductIDs. One solution to having end users not mess with primary key values in this way is to either pass them through session or client variables or make sure that you set up a correct permission system so only the users that have backend rights only have access to the appropriate forms. Bad Apple Syndrome can and will happen -- therefore a good logging system is imperative if you are worried about loss of data integrity stemming from the potential apathy of miscreant employees inside your organization. I guess the bottom line is, if you don't want a value to be changed by the end user, don't pass it in a way they can access it. Anyone can get up and go to another computer and physically hijack the browser session, of course. So in that respect it's never 100% safe in an intranet environment. People leave their browsers open; it's a fact of life. I'm sure someone can give me a good example of why to not use sequential primary keys, however. So I am ready to learn why this might not be as secure as using a hash or GUID, given my methodology and security practices for handline this data, of course. Just because someone can look at ProductID 10 by changing the current one in the URL doesn't really bother me. If you don't want an end-user to look at ProductID 10, then it should be secured so it can't be gotten to by that user unless they have the appropriate permissions, meaning that you can't hope that the user didn't get a link to ProductID 10 pasted in an email or copied from another employee's open browser window, whether the ProductID was hashed, GUID'd, or not. --Andy ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
