Most languages don't stored connection information in a central repository - you have to provide credentials at code time. Unless your file system is insecure (ie, everyone can see everyone's code), other developers on that box would be unable to connect to your database.
--- Billy Cravens -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2: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
