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. I was just thinking about this issue today myself since I'm currently working on something that involves the privacy issues of a lot of users. My initial thought was to do something such as just using Encrypt() and Decrypt() to put all variables encoded into one long form/url string. Though on a page with a lot of links, that would be way too CPU intensive, and its just a hack job around a good security plan (though I can see its usefulness as just one small part of a plan-- I tend to encrypt any somewhat sensitive or easily altered data in Client/Cookie/Session scopes for instance). The solution would be to make a role based security scheme to take care of that problem. In theory, it shouldn't matter if someone is manually entering in ID's of things via Form/URL strings which they want to see so long as you are checking their permission level to that specific record. 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. As others have said, you could probably just use GUID's if you are that worried. The additional layer of security would negate the minute added CPU time needed to generate GUID's if the application needed the additional security. Again, if you are controlling / checking access to records (essentially treating all data from forms and URL's as if it were a virus), it shouldn't be a problem to begin with. One of the other things I could think of being bad about using plain incrementing integers is that unless you start at a random point of assigning ID's, people could perhaps get a general idea of how many records for that type of data exist in the database. Random ID's (a la Access) are very problematic if you ever need to 'upsize' data to a different database server or environment (i.e. I could see how they could be a pain for clustering and/or replication). Or maybe just the recent experience of upsizing a replicated Access DB pool w/ random ID's to SQL Server has left a bad taste in my mouth. :) - Brandon -- http://spooled.net http://booms.net FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
In a few months nobody is using CF 4.5 anyway. Really? And you can guarantee this? We have people on this list still using CF4, that's 3 generations old (since CFMX is out now) - people stick with software the know works... Not everybody can afford to/wants to upgrade to the latest software - we won't hit CFMX in productions for a couple of months, but it doesn't mean that our client who still has CF4.51 on their servers will immediately jump on CFMX... In fact they only upgraded from CF3.1 about 6 months ago - to CF4.51 (go figure) Philip Arnold Technical Director Certified ColdFusion Developer ASP Multimedia Limited Switchboard: +44 (0)20 8680 8099 Fax: +44 (0)20 8686 7911 www.aspmedia.co.uk www.aspevents.net An ISO9001 registered company. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ** __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
I personally always use uniqueidentifiers for primary keys, it's just a perference of mine. are they harder to work with? in my opinion, no, they are just as easy to work with as integers. do they add some extra overhead and extra access time to the application? if they do, i have never seen it and the day you can, I'll start calling you The Flash. UID, in my opinion, add little layer of extra security to your app. Anyone with a pea for a brain can edit the url or form fields that are passed and change the value of your variables. if you're using integers, you could easily start poking around in the app by change the variables. with UID it's a little more complex to guess. I'm no god when it comes to SQL server, so if you have been taught differently and are comfortable with the methods that you use, use them. don't just change the way you program because i do something different. there are probably some benefits / limitations on using UIDs as primary keys that you could find in groups.google.com. Anthony Petruzzi Webmaster 954-321-4703 [EMAIL PROTECTED] http://www.sheriff.org -Original Message- From: Tony Carcieri [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3: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 woahcall 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
RE: Hacking a shared SQL server
-Original Message- From: Brandon Harper [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:38 AM To: CF-Talk Subject: RE: Hacking a shared SQL server I was just thinking about this issue today myself since I'm currently working on something that involves the privacy issues of a lot of users. My initial thought was to do something such as just using Encrypt() and Decrypt() to put all variables encoded into one long form/url string. Though on a page with a lot of links, that would be way too CPU intensive, and its just a hack job around a good security plan (though I can see its usefulness as just one small part of a plan-- I tend to encrypt any somewhat sensitive or easily altered data in Client/Cookie/Session scopes for instance). I would concur with the idea of encrypting cookies if they contain sensitive data, however I'd think twice of storing ANY sensitive data in cookies, but rather store a username or email address and then make the user log in to get at that sensitive data. 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. I don't really agree with this since my contention is that if you secure your application it won't matter if someone is passing bogus data to it. I will admit that using GUIDs adds another layer of security, however minor it might be, but I think the added hassle created by it (at least the way I go about programming my apps) is not worth it. Like I said in another response to this topic, if you have certain business rules that require something more complex such as a GUID or hash, then by all means use them, but use them where they are appropriate. --Andy __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
Philip Arnold - ASP wrote: In a few months nobody is using CF 4.5 anyway. Really? And you can guarantee this? We have people on this list still using CF4, that's 3 generations old (since CFMX is out now) - people stick with software the know works... Not everybody can afford to/wants to upgrade to the latest software - we won't hit CFMX in productions for a couple of months, but it doesn't mean that our client who still has CF4.51 on their servers will immediately jump on CFMX... In fact they only upgraded from CF3.1 about 6 months ago - to CF4.51 (go figure) But are they running a shared host with sandbox security? Or do they only run code they consider trusted? Although there are probably thousands of systems around running CF 4.5.x, I would be surprised if there were more than a couple of dozen running shared hosting services, and less then 10 with a Sandbox Security setup that makes them comparable. Jochem __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
But are they running a shared host with sandbox security? Or do they only run code they consider trusted? Although there are probably thousands of systems around running CF 4.5.x, I would be surprised if there were more than a couple of dozen running shared hosting services, and less then 10 with a Sandbox Security setup that makes them comparable. They USED to run on a shared 3.1 server, but moved the sites to their own 4.51 server - the company that hosts the machine they were on don't want to upgrade, because the sites run perfectly well on 3.1 The funny thing is that all of the apps run on Access, and even their SQL Server didn't have login passwords, all datasources were open to everybody... I think the hosters have gone Chapter 11 now though... I wonder why g Philip Arnold Technical Director Certified ColdFusion Developer ASP Multimedia Limited Switchboard: +44 (0)20 8680 8099 Fax: +44 (0)20 8686 7911 www.aspmedia.co.uk www.aspevents.net An ISO9001 registered company. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ** __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:03 AM To: CF-Talk Subject: RE: Hacking a shared SQL server I personally always use uniqueidentifiers for primary keys, it's just a perference of mine. are they harder to work with? in my opinion, no, they are just as easy to work with as integers. do they add some extra overhead and extra access time to the application? if they do, i have never seen it and the day you can, I'll start calling you The Flash. UID, in my opinion, add little layer of extra security to your app. Anyone with a pea for a brain can edit the url or form fields that are passed and change the value of your variables. if you're using integers, you could easily start poking around in the app by change the variables. with UID it's a little more complex to guess. Using GUIDs as security through obscurity might buy you some more time than using sequential numbers, but in the end it is never a a substitute for error and variable checking in your apps. One reason I do not use them for my primary keys is for testing. What if I want to call up ProductID 956? How do I do it if the product has a GUID? What if I just want to plug that ProductID into the URL? Now I have to go and query my database based on some other product identifier -- possibly the product name -- and then cut and paste my GUID into the browser location field. It's an extra step that I'd rather do without. I am not saying NOT to use GUIDs as primary keys, but I'd have to have a damn good reason for it, most likely a business rule that would require it. --Andy __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 9:03 AM To: CF-Talk Subject: RE: Hacking a shared SQL server I personally always use uniqueidentifiers for primary keys, it's just a perference of mine. are they harder to work with? in my opinion, no, they are just as easy to work with as integers. do they add some extra overhead and extra access time to the application? if they do, i have never seen it and the day you can, I'll start calling you The Flash. UID, in my opinion, add little layer of extra security to your app. Anyone with a pea for a brain can edit the url or form fields that are passed and change the value of your variables. if you're using integers, you could easily start poking around in the app by change the variables. with UID it's a little more complex to guess. Using GUIDs as security through obscurity might buy you some more time than using sequential numbers, but in the end it is never a a substitute for error and variable checking in your apps. One reason I do not use them for my primary keys is for testing. What if I want to call up ProductID 956? How do I do it if the product has a GUID? What if I just want to plug that ProductID into the URL? Now I have to go and query my database based on some other product identifier -- possibly the product name -- and then cut and paste my GUID into the browser location field. It's an extra step that I'd rather do without. I am not saying NOT to use GUIDs as primary keys, but I'd have to have a damn good reason for it, most likely a business rule that would require it. --Andy __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
If you're so worried about security why are you trusting your hosting to some other company and sharing infrastructure with others? Shared hosting is simply not secure and there is no way to make it secure. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 10:11 AM 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! __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
- Original Message - From: [EMAIL PROTECTED] --snip-- And to prevent that would be to never us an obvious DSN. name it something like Hys72hs! --snip- Seems like a good idea - assuming you use a #request.DSN# or #application.DSN# variable, you only have to maintain the DSN name in one place, so the fact that it's gobbledeegook shouldn't be a huge problem... - Gyrus - [EMAIL PROTECTED] work: http://www.tengai.co.uk play: http://www.norlonto.net - PGP key available __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
I have a tool that will read the registry and pull the datasources on the machine the tool is on. The tool will check for the registry and if the registry tag is disabled it will give you a text box to manually type in a datasource. Then the tool will act like a simplified version of Enterprise Manager. If anyone wants the code I will zip it and make it available from my site. This tool works in IE5 and up ONLY. -- Clint Tredway -- Through Him, anything is possible. 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! __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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! __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
[EMAIL PROTECTED] wrote: 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. Set a password. and also, can someone tell me how many webHosts turn off the CFREGISTRY tag? Turn off: to little Secure in other ways: still to little Jochem __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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! __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
hey guys, i just thought about this, and it's making me feel uneasy about using shared SQL server. You should feel that way about using a shared anything. I agree 100% with Matt on this. Hey, wait, what's that two-headed goat doing here? ok, i did a test hack on a live server. You'll want to be careful about doing that; one man's test is another man's harmful intrusion. 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. Well, those issues can be partially addressed by using some of the security features in your database server. Individual user accounts should be created for individual CF applications, at least, and those users should be limited in what they're allowed to touch. Tony Petruzzi just listed the basic steps for this in SQL Server, so I won't bother pursuing it further. Of course, if the usernames and passwords for each SQL user are stored on the application server, that too will have to be secured appropriately, to keep legitimate users from being able to access the ones of other legitimate users. That can be very difficult in practice, to the point of being nearly impossible. Good luck with that, though. Again, at this point, refer to Matt's response. 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Tony is right. If permissions are set properly on SQL, no matter what you put in cf admin, it won't access sql. -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 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! __ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk
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 __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
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
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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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. First, I realize you're not trying to start a fight. Neither am I, of course. I think that, at root, what we've got here is a pronoun problem. You're using I and they in your above statement differently than I am. That is, you're assuming there's this one group called they, who legitimately have equal access to the same set of stored procedures. In a shared CF hosting environment, where not only the database server but the CF server is shared, you may have several theys [sic] - you may have several developers, each of whom has different legitimate rights to databases on your shared database server. For example, I've got my site on there and Matt has his, and we don't like each other. That Matt bastard has been getting on my nerves with his DevX articles, while I annoy him to no end with nit-picky corrections (of course, he wouldn't acknowledge that I'm right in the first place, the bastard!) So, I'll show him - I'll grab the username and password for his database connection, and I'll add some, uh, embarrassing links to his table listing articles he's written. Maybe, I'll query his table that lists business leads he's received through the web site, and send them all slanderous notes. Now, despite the fact that you, the database administrator, have created a set of stored procedures to allow each of us to access only the things we should, I'll be able to use his stored procedures to do so, once I've figured out his username and password (something that is beyond the control of the database administrator, by the way). For his site to do anything useful in the first place, you'll have to have written the stored procedures that allow his legitimate access. Of course, this is just an example - I'm sure I annoy Matt more than he annoys me, and he'd never share a server with me. The final thing to note here is that, while proper security in your database server is very important, it's also very important to secure other layers of your application and its environment. In the case of a shared CF server, this is very, very difficult to do. I hesitate to say it's impossible - there are some very smart people - but I'm not smart enough to do it to a degree that I'd consider reliable. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
RE: Hacking a shared SQL server
Ok, but you're changing the subject. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 12: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
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 woahcall 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
RE: Hacking a shared SQL server
damn good example david, damn good. I stand corrected. 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 3:13 PM 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. First, I realize you're not trying to start a fight. Neither am I, of course. I think that, at root, what we've got here is a pronoun problem. You're using I and they in your above statement differently than I am. That is, you're assuming there's this one group called they, who legitimately have equal access to the same set of stored procedures. In a shared CF hosting environment, where not only the database server but the CF server is shared, you may have several theys [sic] - you may have several developers, each of whom has different legitimate rights to databases on your shared database server. For example, I've got my site on there and Matt has his, and we don't like each other. That Matt bastard has been getting on my nerves with his DevX articles, while I annoy him to no end with nit-picky corrections (of course, he wouldn't acknowledge that I'm right in the first place, the bastard!) So, I'll show him - I'll grab the username and password for his database connection, and I'll add some, uh, embarrassing links to his table listing articles he's written. Maybe, I'll query his table that lists business leads he's received through the web site, and send them all slanderous notes. Now, despite the fact that you, the database administrator, have created a set of stored procedures to allow each of us to access only the things we should, I'll be able to use his stored procedures to do so, once I've figured out his username and password (something that is beyond the control of the database administrator, by the way). For his site to do anything useful in the first place, you'll have to have written the stored procedures that allow his legitimate access. Of course, this is just an example - I'm sure I annoy Matt more than he annoys me, and he'd never share a server with me. The final thing to note here is that, while proper security in your database server is very important, it's also very important to secure other layers of your application and its environment. In the case of a shared CF server, this is very, very difficult to do. I hesitate to say it's impossible - there are some very smart people - but I'm not smart enough to do it to a degree that I'd consider reliable. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 woahcall 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
RE: Hacking a shared SQL server
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
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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 woahcall 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
RE: Hacking a shared SQL server
Most languages don't stored connection information in a central repository - you have to provide credentials at code time. You can do that in CF, of course - there's nothing forcing you to store them in the datasource settings. 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. Well, here's where it becomes tricky. I'll go back to my prior example, with Matt and me sharing a server. Each has set permissions that keep the other out, of course - Matt doesn't trust me as far as he can throw me, and I've been putting on weight. However, we can both write code that runs on the server. If either of us can figure out how to escalate our privileges to root or Administrator or SYSTEM or whatever, then we'll be able to bypass that pesky filesystem ACL limitation and read the other's files. So, Matt is still annoyed about how I read his database info from the registry, and he decides to get even. Remembering that any CFML code that he writes will run with the privileges of the CF service itself - and that this service must, by necessity, have read access to his files and mine, he has many potential attack routes right there. On the other hand, I might then use a privilege escalation of my own, by creating a batch file and getting it inadvertently scheduled by the system schedule (which on Windows runs as SYSTEM, of course). Of course, our hosting provider must be getting mad by now. So, I'll stop here, but this should give you a good idea of the difficulties that a shared hosting provider must face. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Use GUID's? --- Billy Cravens -Original Message- From: Tony Carcieri [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2: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 woahcall 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
RE: Hacking a shared SQL server
I've seen a number of references to using GUIDs as the primary keys. This would avoid the problem of someone guessing a PK. However, the (small) overhead in creating the GUID, and the increased storage requirements (afterall, a GUID is a string) would probably be slightly slower than integers. That said, when it comes to security, you have to ask how important the data is and then implement security procedures of the appropriate level. Afterall, doing retinal scanners and voice recognition to protect something like resumes would be overkill. My thoughts Shawn Grover -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:53 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
True - I was just addressing common setups and scenarios. Most CF hosts and developers take advantage of storing the connection info in the CF Admin, to keep their cfquery's shorter. And if your file system gets hacked, then you're hitting that red alert zone. But the standard setup, where credentials are stored in CF Admin, is insecure without even trying. --- Billy Cravens -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:55 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Most languages don't stored connection information in a central repository - you have to provide credentials at code time. You can do that in CF, of course - there's nothing forcing you to store them in the datasource settings. 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. Well, here's where it becomes tricky. I'll go back to my prior example, with Matt and me sharing a server. Each has set permissions that keep the other out, of course - Matt doesn't trust me as far as he can throw me, and I've been putting on weight. However, we can both write code that runs on the server. If either of us can figure out how to escalate our privileges to root or Administrator or SYSTEM or whatever, then we'll be able to bypass that pesky filesystem ACL limitation and read the other's files. So, Matt is still annoyed about how I read his database info from the registry, and he decides to get even. Remembering that any CFML code that he writes will run with the privileges of the CF service itself - and that this service must, by necessity, have read access to his files and mine, he has many potential attack routes right there. On the other hand, I might then use a privilege escalation of my own, by creating a batch file and getting it inadvertently scheduled by the system schedule (which on Windows runs as SYSTEM, of course). Of course, our hosting provider must be getting mad by now. So, I'll stop here, but this should give you a good idea of the difficulties that a shared hosting provider must face. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
I had an Oracle DBA that worked for me at one point that made a pretty primary key generator using a pseudo random number generator. No idea how it worked though. I tend to use hashes of sequenced and random data myself. -Matt -Original Message- From: Ben Johnson [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 12:53 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
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 woahcall 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
RE: Hacking a shared SQL server
While a GUID is a string, conceptually you can do the same thing with a long long. -Matt -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:02 PM To: CF-Talk Subject: RE: Hacking a shared SQL server I've seen a number of references to using GUIDs as the primary keys. This would avoid the problem of someone guessing a PK. However, the (small) overhead in creating the GUID, and the increased storage requirements (afterall, a GUID is a string) would probably be slightly slower than integers. That said, when it comes to security, you have to ask how important the data is and then implement security procedures of the appropriate level. Afterall, doing retinal scanners and voice recognition to protect something like resumes would be overkill. My thoughts Shawn Grover -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:53 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Who needs to hack a file system on a shared host? Just use cfmail to email other people's files to you. -Matt -Original Message- From: Cravens, Billy [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:01 PM To: CF-Talk Subject: RE: Hacking a shared SQL server True - I was just addressing common setups and scenarios. Most CF hosts and developers take advantage of storing the connection info in the CF Admin, to keep their cfquery's shorter. And if your file system gets hacked, then you're hitting that red alert zone. But the standard setup, where credentials are stored in CF Admin, is insecure without even trying. --- Billy Cravens -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:55 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Most languages don't stored connection information in a central repository - you have to provide credentials at code time. You can do that in CF, of course - there's nothing forcing you to store them in the datasource settings. 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. Well, here's where it becomes tricky. I'll go back to my prior example, with Matt and me sharing a server. Each has set permissions that keep the other out, of course - Matt doesn't trust me as far as he can throw me, and I've been putting on weight. However, we can both write code that runs on the server. If either of us can figure out how to escalate our privileges to root or Administrator or SYSTEM or whatever, then we'll be able to bypass that pesky filesystem ACL limitation and read the other's files. So, Matt is still annoyed about how I read his database info from the registry, and he decides to get even. Remembering that any CFML code that he writes will run with the privileges of the CF service itself - and that this service must, by necessity, have read access to his files and mine, he has many potential attack routes right there. On the other hand, I might then use a privilege escalation of my own, by creating a batch file and getting it inadvertently scheduled by the system schedule (which on Windows runs as SYSTEM, of course). Of course, our hosting provider must be getting mad by now. So, I'll stop here, but this should give you a good idea of the difficulties that a shared hosting provider must face. 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
Dave Watts wrote: Well, here's where it becomes tricky. I'll go back to my prior example, with Matt and me sharing a server. Each has set permissions that keep the other out, of course - Matt doesn't trust me as far as he can throw me, and I've been putting on weight. However, we can both write code that runs on the server. If either of us can figure out how to escalate our privileges to root or Administrator or SYSTEM or whatever, then we'll be able to bypass that pesky filesystem ACL limitation and read the other's files. So, Matt is still annoyed about how I read his database info from the registry, and he decides to get even. Remembering that any CFML code that he writes will run with the privileges of the CF service itself Sandbox Security to the rescue. The code would run under the priviledges of the www-Matt user. and that this service must, by necessity, have read access to his files and mine, he has many potential attack routes right there. On the other hand, I might then use a privilege escalation of my own, by creating a batch file and getting it inadvertently scheduled by the system schedule (which on Windows runs as SYSTEM, of course). Sandbox Security to the rescue. Scheduling something requires administrator or system priviledges, which are unavailable to the www-Dave user. Of course, our hosting provider must be getting mad by now. Then you have the wrong hosting provider :) So, I'll stop here, but this should give you a good idea of the difficulties that a shared hosting provider must face. I haven't heard a scenario that scares me yet. But I haven't upgraded to CF MX either, and scenario's change a lot there. In fact, I haven't come up with any scenario under CF MX that does *not* scare me. Jochem __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Like any database question though, the best answer is to ask your DBA. Unless you are the DBA... then you're just S.O.L. g Ben Johnson Hostworks, Inc. __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
omatically generated Delivery Status Notification. If I need to keep someone from being able to guess a primary key I create a second field that contains a random number. That way the data will only show if the random number and the primary key are correct. BJ = = = Original message = = = I've seen a number of references to using GUIDs as the primary keys. This would avoid the problem of someone guessing a PK. However, the (small) overhead in creating the GUID, and the increased storage requirements (afterall, a GUID is a string) would probably be slightly slower than integers. That said, when it comes to security, you have to ask how important the data is and then implement security procedures of the appropriate level. Afterall, doing retinal scanners and voice recognition to protect something like resumes would be overkill. My thoughts Shawn Grover -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:53 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, ~Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
hehe... see - now that is kinda mean -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:08 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Who needs to hack a file system on a shared host? Just use cfmail to email other people's files to you. -Matt -Original Message- From: Cravens, Billy [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:01 PM To: CF-Talk Subject: RE: Hacking a shared SQL server True - I was just addressing common setups and scenarios. Most CF hosts and developers take advantage of storing the connection info in the CF Admin, to keep their cfquery's shorter. And if your file system gets hacked, then you're hitting that red alert zone. But the standard setup, where credentials are stored in CF Admin, is insecure without even trying. --- Billy Cravens -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:55 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Most languages don't stored connection information in a central repository - you have to provide credentials at code time. You can do that in CF, of course - there's nothing forcing you to store them in the datasource settings. 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. Well, here's where it becomes tricky. I'll go back to my prior example, with Matt and me sharing a server. Each has set permissions that keep the other out, of course - Matt doesn't trust me as far as he can throw me, and I've been putting on weight. However, we can both write code that runs on the server. If either of us can figure out how to escalate our privileges to root or Administrator or SYSTEM or whatever, then we'll be able to bypass that pesky filesystem ACL limitation and read the other's files. So, Matt is still annoyed about how I read his database info from the registry, and he decides to get even. Remembering that any CFML code that he writes will run with the privileges of the CF service itself - and that this service must, by necessity, have read access to his files and mine, he has many potential attack routes right there. On the other hand, I might then use a privilege escalation of my own, by creating a batch file and getting it inadvertently scheduled by the system schedule (which on Windows runs as SYSTEM, of course). Of course, our hosting provider must be getting mad by now. So, I'll stop here, but this should give you a good idea of the difficulties that a shared hosting provider must face. 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Who needs to hack a file system on a shared host? Just use cfmail to email other people's files to you. hehe... see - now that is kinda mean Why, because it might crash the server and leave the spool directory full of zero-byte files or something? 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
I'm glad you're so happy with sandbox security. It still doesn't catch everything in a shared hosting environment. Want proof? Setup me up with a normal account on your shared hosting server, sign a waiver allowing me to crack your machine, and wait. I'll send you every .cfm file on the server, every database instances' schema and data, and every account's username and password. I can even have an FBI agent supervise me while I do it as they love free training. Of course you're free to just keep thinking shared hosting is secure. I won't mind, security consulting after the crack pays me quite well. -Matt -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:01 PM To: CF-Talk Subject: Re: Hacking a shared SQL server Matt Liotta wrote: Who needs to hack a file system on a shared host? Just use cfmail to email other people's files to you. Sandbox Security: Error 5. Access is denied. Jochem __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. [EMAIL PROTECTED] 06/06/02 03:52PM 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
for tables with small records, this might be ok. But think about a transaction table - potentially hundreds of transactions a day. For the first bit, this might work well. But eventually your system will bog down while it tries to find an un-used ID. Also, to generate your random number, you have to predetermine the upper limit (numbers from 1 to 1,000,000 say, or more even). This will limit your system to X number of records (whatever your upper limit is). So, in larger applications random numbers are probably not the best solution. Shawn Grover -Original Message- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:23 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. [EMAIL PROTECTED] 06/06/02 03:52PM 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Well depending on how random your number is you could have a lot of collisions. It would really suck performance wise to keep trying new random numbers all the time. -Matt -Original Message- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:23 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. [EMAIL PROTECTED] 06/06/02 03:52PM 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
The only upper limit for any random number is how many bits long it is. Of course this limit is the same for a sequential primary key. -Matt -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:32 PM To: CF-Talk Subject: RE: Hacking a shared SQL server for tables with small records, this might be ok. But think about a transaction table - potentially hundreds of transactions a day. For the first bit, this might work well. But eventually your system will bog down while it tries to find an un-used ID. Also, to generate your random number, you have to predetermine the upper limit (numbers from 1 to 1,000,000 say, or more even). This will limit your system to X number of records (whatever your upper limit is). So, in larger applications random numbers are probably not the best solution. Shawn Grover -Original Message- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:23 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. [EMAIL PROTECTED] 06/06/02 03:52PM 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. That does work, however, it is also a performance hit. The performance hit dramatically increases as the size of the table increases. An int data type is 4-bytes. That means it can go up to ~4 millions rows. When you first start populating the table, it may pull a random number that is not in the database pretty quickly as the chance in getting a previously used number is 1 in 4 million. Once your table size increases to a million rows, your chance of hitting a previously used number becomes 1 in 4. One solution would be to use a bigint data type. It's an 8-byte integer that goes up to something like 9 quintillion (that's 9 with a lotta zeros). I don't believe this data type is available in SQL Server 7.0 and perhaps some other RDMBS' so there could be compatibility issues. Ben Johnson Hostworks, Inc. __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
Understood Matt, and agreed. But in most random number generation routines, you say what range you want the resulting number to fall into - upper and lower limits. (i.e. RandRange(1, 100) ). So, at this point you'd have to specify a number that matches the max size of your Primary Key datatype to get the absolute maximum size number. Also, I think generating random numbers within a range tend to favor numbers towards the center of the range. I know a lot of work has been put into Random number routines to avoid this, but it still happens. My thoughts, even if they are rather off topic... grins Shawn Grover -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:35 PM To: CF-Talk Subject: RE: Hacking a shared SQL server The only upper limit for any random number is how many bits long it is. Of course this limit is the same for a sequential primary key. -Matt -Original Message- From: Shawn Grover [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 2:32 PM To: CF-Talk Subject: RE: Hacking a shared SQL server for tables with small records, this might be ok. But think about a transaction table - potentially hundreds of transactions a day. For the first bit, this might work well. But eventually your system will bog down while it tries to find an un-used ID. Also, to generate your random number, you have to predetermine the upper limit (numbers from 1 to 1,000,000 say, or more even). This will limit your system to X number of records (whatever your upper limit is). So, in larger applications random numbers are probably not the best solution. Shawn Grover -Original Message- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:23 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. [EMAIL PROTECTED] 06/06/02 03:52PM 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, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
-Original Message- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 5:23 PM To: CF-Talk Subject: RE: Hacking a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. I think this is not a good idea -- talk about resource intensive. I've always done things assuming that all URL and FORM variables can and will be changed by the end user at some point, so if I have something like http://www.mysite.com/mypage.cfm?ProductID=463, I follow the best practices such as using cfqueryparam for any variables I am going to plug-in to my SQL, or by using stored procedures. The first example would be a typical end user surfing a site. They can remove the ProductID, add SQL to create a SQL injection attack, change the value of ProductID to a non-numeric value; it doesn't matter because my code will handle all of that. But what about an administration section where you trust the users a bit more (yeah, right...) What if you had the same URL except that ProductID 463 was being called up to edit? Say you stick the ProductID in a hidden form field and the end user cooks up their own form with a different ProductID but the same information. Now you have duplicate products with two different ProductIDs. One solution to having end users not mess with primary key values in this way is to either pass them through session or client variables or make sure that you set up a correct permission system so only the users that have backend rights only have access to the appropriate forms. Bad Apple Syndrome can and will happen -- therefore a good logging system is imperative if you are worried about loss of data integrity stemming from the potential apathy of miscreant employees inside your organization. I guess the bottom line is, if you don't want a value to be changed by the end user, don't pass it in a way they can access it. Anyone can get up and go to another computer and physically hijack the browser session, of course. So in that respect it's never 100% safe in an intranet environment. People leave their browsers open; it's a fact of life. I'm sure someone can give me a good example of why to not use sequential primary keys, however. So I am ready to learn why this might not be as secure as using a hash or GUID, given my methodology and security practices for handline this data, of course. Just because someone can look at ProductID 10 by changing the current one in the URL doesn't really bother me. If you don't want an end-user to look at ProductID 10, then it should be secured so it can't be gotten to by that user unless they have the appropriate permissions, meaning that you can't hope that the user didn't get a link to ProductID 10 pasted in an email or copied from another employee's open browser window, whether the ProductID was hashed, GUID'd, or not. --Andy __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Hacking a shared SQL server
Matt Liotta wrote: I'm glad you're so happy with sandbox security. It still doesn't catch everything in a shared hosting environment. Want proof? Setup me up with a normal account on your shared hosting server, sign a waiver allowing me to crack your machine, and wait. I'll send you every .cfm file on the server, every database instances' schema and data, and every account's username and password. I will need: - a copy of the waiver - credentials/testimonials that you are white hat - an assesment of the risk you disturb normal operation of the machine If you get me those, I'll try to convince some people to do this. I can even have an FBI agent supervise me while I do it as they love free training. Free training in hacking my server? Why would they want that? In a few months nobody is using CF 4.5 anyway. Of course you're free to just keep thinking shared hosting is secure. I know it is not. Just because none of the scenario's mentioned so far apply doesn't mean I can't think of others that will work. I am quite confident that our regular customers won't be able to take over the system, but because even Sandbox Security is partially security through obscurity I'm very interested in what an expert will do. I won't mind, security consulting after the crack pays me quite well. Not in this case. If we consider the risk to high we will just send an email to our customers that we will stop hosting ColdFusion. ColdFusion hosting is not a service we want to provide at any cost (in fact, some people even consider the cost of CF MX too high already). Jochem __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
I'm sure someone can give me a good example of why to not use sequential primary keys, however. So I am ready to learn why this might not be as secure as using a hash or GUID, given my methodology and security practices for handline this data, of course. Just because someone can look at ProductID 10 by changing the current one in the URL doesn't really bother me. If you don't want an end-user to look at ProductID 10, then it should be secured so it can't be gotten to by that user unless they have the appropriate permissions, meaning that you can't hope that the user didn't get a link to ProductID 10 pasted in an email or copied from another employee's open browser window, whether the ProductID was hashed, GUID'd, or not. Agreed. Although the cross-our-fingers-and-hope-they-don't-guess-the-right-ID method can be a deterrent, I don't believe it should ever be used for any kind of substantial security. That's one reason why I still use sequential IDs. Most of the sites I work on do not need any kind of replication or merging of data, which is where I believe GUIDs come in handy. Sure, it's good to build sites scalable where they can change from a hundred rows in a table to a million, but there's also something to be said for making sites practical. Sequential, numeric IDs are simple and easy to work with. GUIDs do not add *that* much difficulty, but they still add some -- especially for any lesser experienced developers that you work with. Ben Johnson Hostworks, Inc. __ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Hacking a shared SQL server
- a copy of the waiver No problem - credentials/testimonials that you are white hat Can't do that as I am not white hat. You think I work with the FBI by choice? - an assesment of the risk you disturb normal operation of the machine Also no problem Free training in hacking my server? Why would they want that? In a few months nobody is using CF 4.5 anyway. Old hacks never die, they just get repurposed. By observing how a machine can be comprised, the FBI is able to add knowledge to their investigative toolkit. Not in this case. If we consider the risk to high we will just send an email to our customers that we will stop hosting ColdFusion. ColdFusion hosting is not a service we want to provide at any cost (in fact, some people even consider the cost of CF MX too high already). I certainly wouldn't want to be in the application server hosting business unless each customer was on a dedicated OS image. Let me know about the white hat thing. If you can get around that problem, email me off-list to set this up. Also since I am doing this for free, I would publish my results. Gotta make money for my time some how. -Matt __ 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
