In a sense, you're right. But my point wasn't about particular permissions. I was pointing out that saving the username/password in the CF Admin allows anyone who can write code on that box to perform whatever actions you have established in your database. In other words, there's no way to say that Directory A can only access Datasource A, Directory B can only access Datasource B, etc. Your security model restricts end user actions and provides a bit of obscurity, but it doesn't avoid the "global datasource" issue.
(is there some way to do this type of security using sandboxes? My experience with Adv. Security is extremely limited) --- Billy Cravens -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:09 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. Anthony Petruzzi Webmaster 954-321-4703 [EMAIL PROTECTED] http://www.sheriff.org -----Original Message----- From: Cravens, Billy [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:02 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server This has nothing to do with securing the database. It's a matter of how datasources are defined in the CF administrator. Usually, the username and password are defined and saved in the CF administrator, so the code only has to specify the datasource name. No matter how strong you lock down your SQL Server, when you save the username/password in the Administrator, it has the same effect as having no security (if someone can write code on the box and knows the datasource name). --- Billy Cravens -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 12:50 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server that's because you didn't secure your database like your suppose to. I'm actually doing a presentation tonight for our CFUG about securing your SQL database. In a nut shell what you should do is create a user for the database (let's say the DB name is TEST) and give them DENYDATAREADER and DENYDATAWRITER access to the database. yes that is correct, it isn't a mistype. Then what you do is with the sa account, create your tables and your stored procedures. you can use another account that has db owner previledges, you just have to make sure that the same user owns both the tables and the storedprocedures. You can use the stored procedure "sp_changeobjectowner" to change the owner of an object if need be. Then after you created your stored procedures for your database, you give the user only EXEC permissions for that stored procedure. Now even if they get the username and password, what can they access. nothing. they can't even see what tables you have. all they can do is execute the stored procedures that you allow them to. this is a very rough example. if your in the south florida area tonight (don't know where you are), go to the CFUG meeting at the Hillsboro Compusa in Deerfield beach at 7:30pm. I will go into detail about this tonight. Anthony Petruzzi Webmaster 954-321-4703 [EMAIL PROTECTED] http://www.sheriff.org -----Original Message----- From: Ken Wilson [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:33 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server >let me know of any coldfusion hacks Hmmm, you acknowledge pulling data from a "very desirable" table on a site you don't manage and now you want us to send you CF hacks? :) But anyway, does your host not setup username/password on the databases? Ken -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:11 PM To: CF-Talk Subject: Hacking" a shared SQL server hey guys, i just thought about this, and it's making me feel uneasy about using shared SQL server. ok, i did a test hack on a live server. As you know in SQL Enterprise, you're able to see the database names of other people sharing the SQL server. and by looking at the names you can probably guess what they named their DSN. I got lucky, and nabbed one. I pulled out the table names from sysobjects. Then pulled out the field names from a "very desirable" table using columnlist, then was able to pull out data! I was appalled! Because my DSNs are named after my site and anyone could have just done with I've done, but with a different intent. But the only way they will get that far is if they know the DSN. And to prevent that would be to never us an obvious DSN. name it something like "Hys72hs"!!!!! I had that fear in my mind way from the beginning, but I had thought that the DSN only works if it is being requested from a certain site!!! and also, can someone tell me how many webHosts turn off the CFREGISTRY tag? Or if any host even have it on at all? I attempted to retrieve the DATAsource names from using that tag, but good thing this host turned it off. Also, please let me know of any coldfusion hacks you guys might know. This is, of course, so you and I can have better security! ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. 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
