I personally always use uniqueidentifiers for primary keys, it's just a perference of mine. are they harder to work with? in my opinion, no, they are just as easy to work with as integers. do they add some "extra overhead" and "extra access time" to the application? if they do, i have never seen it and the day you can, I'll start calling you The Flash. UID, in my opinion, add little layer of extra security to your app. Anyone with a pea for a brain can edit the url or form fields that are passed and change the value of your variables. if you're using integers, you could easily start "poking" around in the app by change the variables. with UID it's a little more complex to guess. I'm no god when it comes to SQL server, so if you have been taught differently and are comfortable with the methods that you use, use them. don't just change the way you program because i do something different. there are probably some benefits / limitations on using UIDs as primary keys that you could find in groups.google.com.
Anthony Petruzzi Webmaster 954-321-4703 [EMAIL PROTECTED] http://www.sheriff.org -----Original Message----- From: Tony Carcieri [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:21 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server Also if you're the type of person that likes to use integers for primary keys instead of unique identifiers, then I can see you getting at anything in the database from a stored procedure. woah woah....call me dumb here, but by unique identifiers what do you mean? I ALWAYS though integers were the method of choice be cause of access time. please fill me in as ints were the way i was taught and if i should be doing something different, by all means "stick my head to a monitor with a railroad spike!" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:09 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server granted that that is true. however doesn't CF or any other programming language do the same thing. and if the way your getting at the data is by using form and url parameter, then it's very easy for me to do from the website and not even bother to try hack the database. using client variables and session variables make this a little harder but not impossible. Also if you're the type of person that likes to use integers for primary keys instead of unique identifiers, then I can see you getting at anything in the database from a stored procedure. Anthony Petruzzi Webmaster 954-321-4703 [EMAIL PROTECTED] http://www.sheriff.org -----Original Message----- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:00 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server Suppose you stored all your customer information in your database. Your application only used stored procedures to read and write data about these customers. I could just use those stored procedures to read your customer data and steal it. So the fact that I could only execute stored procedures doesn't stop me from accessing your data. -Matt > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 11:52 AM > To: CF-Talk > Subject: RE: Hacking" a shared SQL server > > elaborate > > Anthony Petruzzi > Webmaster > 954-321-4703 > [EMAIL PROTECTED] > http://www.sheriff.org > > > -----Original Message----- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 2:47 PM > To: CF-Talk > Subject: RE: Hacking" a shared SQL server > > > If I only have access to run your stored procedures then I could still > access you data through the stored procedures. That IS a security > problem. > > -Matt > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 11:39 AM > > To: CF-Talk > > Subject: RE: Hacking" a shared SQL server > > > > well them let me ask you this. if i locked down my database to the > point > > where they can only access the stored procedures that I want them to, > then > > what do I care if they get ahold of the password to the DSN. They > would > > only > > be able to do anything that I didn't allow them to anyways. > > > > I'm NOT trying to start a fight here. I just don't understand why I > would > > care about someone "hacking" or stealing passwords to a DSN that is > > totally > > locked down. Plus I don't get what you mean when you said "even being > able > > to call those stored procedures is a serious security issue, as I'm > sure > > you're aware." If I let them have access to something and they run it, > > then > > it isn't a security risk. Now if they were able to run something that > I > > didn't give them access to, then we have a problem. However, since I > gave > > them access to run the stored procedures, I don't see a security risk. > > > > > > Anthony Petruzzi > > Webmaster > > 954-321-4703 > > [EMAIL PROTECTED] > > http://www.sheriff.org > > > > > > -----Original Message----- > > From: Dave Watts [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 2:25 PM > > To: CF-Talk > > Subject: RE: Hacking" a shared SQL server > > > > > > > you're wrong on this billy. by doing it this way, the only > > > thin a person can execute is the stored procedures that you > > > allow them to. they will not be able to use cfquery to do > > > queries directly against the database. i have been doing > > > this for around a year now, and have been trying to find a > > > "hack" it for a year now too. I haven't been able to do so > > > yet. > > > > Either you're not trying very hard, or you misunderstood Billy's > argument. > > Basically, if you've got a shared CF server, and the usernames and > > passwords > > for each individual datasource are stored persistently on that server, > > then > > the key to being able to access another database is to retrieve those > > usernames and passwords. By default, they're usually in the registry. > So, > > if > > a developer can write code on the server, and that code can read the > > values > > from the registry, then they can gain the same level of access to the > > database that the other application can. > > > > Now, admittedly, by properly securing the SQL server you can limit > what > > any > > CF applications can do (just calling the allowed stored procedures), > but > > even being able to call those stored procedures is a serious security > > issue, > > as I'm sure you're aware. > > > > By the way, you ought to post your SQL Server presentation on your > CFUG's > > web site, so that others can enjoy it - that sort of stuff is good for > > people to know, and there are often questions on this list about those > > things. > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > voice: (202) 797-5496 > > fax: (202) 797-5444 > > > > > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
