You just need unique keys that aren't in order. The hard part is coming up with an algorithm to do this with. Many people just use GUIDs, but they can be a bit of a problem when it comes to performance. Like any database question though, the best answer is to ask your DBA.
-Matt > -----Original Message----- > From: Tony Carcieri [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 12:45 PM > To: CF-Talk > Subject: RE: Hacking" a shared SQL server > > so how do you prevent that from happening? > > -----Original Message----- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 3:27 PM > To: CF-Talk > Subject: RE: Hacking" a shared SQL server > > > Actually there is nothing wrong with using an integer for a primary key. > The trick is to make sure they aren't in sequence, so that people can't > guess other keys. > > -Matt > > > -----Original Message----- > > From: Tony Carcieri [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 12: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/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
