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
