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 > > > > > > > > > > > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com 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
