Re: Hacking?
> Is anyone familiar with this code: http://pastebin.com/2v3PMx4M I googled the author's name. It's "Too Simple File Manager" ($15), but this versions is outdated and has been modified to allow commandline execution and SQL transactions: http://www.cftagstore.com/?page=viewTag&tagId=290 ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:356723 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Hacking?
Thank You... that was useful. We have the server locked, but these files have been here for some time. Now we have to scan everything for some of the strings in the files. Robert Harrison Director of Interactive Services Austin & Williams Advertising I Branding I Digital I Direct 125 Kennedy Drive, Suite 100 I Hauppauge, NY 11788 T 631.231.6600 X 119 F 631.434.7022 http://www.austin-williams.com Blog: http://www.austin-williams.com/blog Twitter: http://www.twitter.com/austin_williams -Original Message- From: Pete Freitag [mailto:p...@foundeo.com] Sent: Friday, September 06, 2013 10:03 AM To: cf-talk Subject: Re: Hacking? Yes, it certainly can be used by hackers. It can be used to manipulate the file system, upload files, execute exe's, and run database queries against your datasources. This file is most commonly found via the adminapi Hack widely exploited in Dec/Jan 2012 (eg /CFIDE/h.cfm, etc), but I've also seen this particular file on hacked servers sprinkled through the file system (eg 20-30 instances, using random file names). Also I've found in many cases that a server had patched the adminapi issue and blocked /CFIDE/adminapi but never cleaned up files that attackers placed, so they keep getting hit. You will want to take a close look at the server, and consider moving to a fresh server after you have cleaned up. -- Pete Freitag - Adobe Community Professional http://foundeo.com/ - ColdFusion Consulting & Products http://hackmycf.com - Is your ColdFusion Server Secure? http://www.youtube.com/watch?v=ubESB87vl5U - FuseGuard your CFML in 1 ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:356715 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Hacking?
Yes, it certainly can be used by hackers. It can be used to manipulate the file system, upload files, execute exe's, and run database queries against your datasources. This file is most commonly found via the adminapi Hack widely exploited in Dec/Jan 2012 (eg /CFIDE/h.cfm, etc), but I've also seen this particular file on hacked servers sprinkled through the file system (eg 20-30 instances, using random file names). Also I've found in many cases that a server had patched the adminapi issue and blocked /CFIDE/adminapi but never cleaned up files that attackers placed, so they keep getting hit. You will want to take a close look at the server, and consider moving to a fresh server after you have cleaned up. -- Pete Freitag - Adobe Community Professional http://foundeo.com/ - ColdFusion Consulting & Products http://hackmycf.com - Is your ColdFusion Server Secure? http://www.youtube.com/watch?v=ubESB87vl5U - FuseGuard your CFML in 10 minutes On Fri, Sep 6, 2013 at 9:32 AM, Robert Harrison wrote: > > Is anyone familiar with this code: http://pastebin.com/2v3PMx4M > > We found this in one of our sites which has been getting hacked lately. We > also found a few other infected files which we've cleaned, but this on in > particular was somehow injected into one of our sites. Anyone know what > this does and if it could be used as a hacking aid? > > Thanks > > > > Robert Harrison > Director of Interactive Services > > Austin & Williams > Advertising I Branding I Digital I Direct > 125 Kennedy Drive, Suite 100 I Hauppauge, NY 11788 > T 631.231.6600 X 119 F 631.434.7022 > http://www.austin-williams.com > > Blog: http://www.austin-williams.com/blog > Twitter: http://www.twitter.com/austi > > ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:356714 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Hacking?
this is the cfshell that was getting installed by the well known cfadmin/adminapi hack. So you must still your cfadmin or adminapi publicly accessible on that server. On Fri, Sep 6, 2013 at 2:32 PM, Robert Harrison wrote: > > Is anyone familiar with this code: http://pastebin.com/2v3PMx4M > > We found this in one of our sites which has been getting hacked lately. We > also found a few other infected files which we've cleaned, but this on in > particular was somehow injected into one of our sites. Anyone know what > this does and if it could be used as a hacking aid? > > Thanks > > > > Robert Harrison > Director of Interactive Services > > Austin & Williams > Advertising I Branding I Digital I Direct > 125 Kennedy Drive, Suite 100 I Hauppauge, NY 11788 > T 631.231.6600 X 119 F 631.434.7022 > http://www.austin-williams.com > > Blog: http://www.austin-williams.com/blog > Twitter: http://www.twitter.com/austi > > ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:356713 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Hacking into CFGrid
Ext 1.1 docs are here ...
http://extjs.com/deploy/ext-1.1.1/docs/
>
>
> Don't forget, the underlying Ajax components are built upon Ext JS 1.1.
> There is full API documentation available for 1.1 within the Learning
> Center area of the site.
>
> Steve "Cutter" Blades
> Adobe Certified Professional
> Advanced Macromedia ColdFusion MX 7 Developer
>
> Co-Author of "Learning Ext JS"
> http://www.packtpub.com/learning-ext-js/book
> _
> http://blog.cutterscrossing.com
>
> Ian Skinner wrote:
> > Has anybody hacked into an HTML in order to format some
> > numbers. I presume one would need do something with JavaScript somehow
> > connected to the CFGrid.
> >
> > I've sucessfully used some sneaky CSS to at least get a right alignment
> > to my numbers.
> >
> > .x-grid-col-[col#] {text-align: right;}
> >
> > It would be really nice if I could also add something that will format
> > the numbers with thousand's separators.
> >
> > TIA
> > Ian
> >
> >
> >
>
>
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:318712
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Hacking into CFGrid
Check out this post on how to create a grid renderer for the CF8 Ajax Grid:
http://blog.cutterscrossing.com/index.cfm?mode=entry&entry=924FD535-3048-71C2-1732C7C676604ABE
Don't forget, the underlying Ajax components are built upon Ext JS 1.1.
There is full API documentation available for 1.1 within the Learning
Center area of the site.
Steve "Cutter" Blades
Adobe Certified Professional
Advanced Macromedia ColdFusion MX 7 Developer
Co-Author of "Learning Ext JS"
http://www.packtpub.com/learning-ext-js/book
_
http://blog.cutterscrossing.com
Ian Skinner wrote:
> Has anybody hacked into an HTML in order to format some
> numbers. I presume one would need do something with JavaScript somehow
> connected to the CFGrid.
>
> I've sucessfully used some sneaky CSS to at least get a right alignment
> to my numbers.
>
> .x-grid-col-[col#] {text-align: right;}
>
> It would be really nice if I could also add something that will format
> the numbers with thousand's separators.
>
> TIA
> Ian
>
>
>
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:318696
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Hacking Client Variables?
Depending on how your application works, someone could go CFID/CFTOKEN searching trying to find a still active session and try to hijack that session. I've seen it done by accident. Moving your client variables to a 36bit UUID helps with this and what I've done is created a timeoutvariable just in the case the user doesn't log out (and the client variable leaves him logged in) I note the date/time of his last visit and if its greater than "15" minutes of no activity (or whatever acceptable value for you) it clears the variables and requests re-authentication. -Original Message- From: Ben Schwemlein [mailto:[EMAIL PROTECTED] Sent: Sunday, March 09, 2003 8:45 PM To: CF-Talk Subject: Hacking Client Variables? Can anyone suggest a way to hack a query that has "WHERE userid = '#CLIENT.userid#'" in CF 5 and/or MX? Another developer has an application that has sensitive customer information that is encrypted at the database level, but not at the ColdFusion level. I think this is not secure, but I want some evidence before I make an objection. Any suggestions would help. Our client variables are contained in the Database, and the client IDs are sequential. If there is some way to externally hack and set the client variable, then a Hacker could get all customer info. Thanks, Ben ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Hacking Client Variables?
If your client variables are being stored on the database, then there is no way someone could modify the value, unless they had access to your database server (in which case you have bigger problems). The only interaction the user would have in this case are the CFID and CFTOKEN cookie or URL parameters, which simply act as a mapping for CF to know which client/session vars to use for their requests. -Justin Scott - Original Message - From: "Ben Schwemlein" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, March 09, 2003 11:44 PM Subject: Hacking Client Variables? > Can anyone suggest a way to hack a query that has WHERE userid = > #CLIENT.userid# in CF 5 and/or MX? Another developer has an application > that has sensitive customer information that is encrypted at the database > level, but not at the ColdFusion level. I think this is not secure, but I > want some evidence before I make an objection. > Any suggestions would help. > > Our client variables are contained in the Database, and the client IDs are > sequential. If there is some way to externally hack and set the client > variable, then a Hacker could get all customer info. > > Thanks, > > Ben > > > > > > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
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
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 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
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
> -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
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 ac
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
> 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
> - 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
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
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
> -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
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... 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
> 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
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
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
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
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 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
> > Who needs to hack a file system on a shared host? Just > > use 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
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 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 '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
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
> 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. 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
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
Who needs to hack a file system on a shared host? Just use 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 '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
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
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
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
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 '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'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
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
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
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
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
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
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. > > > > > > > >
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
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
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 a
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. > > > &g
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
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
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 neve
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
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
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
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!
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
> 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. 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
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
[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
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
>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
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
- 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
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 CF Web Sites and Applications
>Date: Mon, 13 Aug 2001 22:29:13 +0200 >From: Jochem van Dieten <[EMAIL PROTECTED]> >Subject: Re: Hacking CF Web Sites and Applications >Why a filter looking for words in a URL? To help prevent hack attempts. In some situations, changing the values in a certain locations can create huge security problems. >AFAIK the issue is that code (like DROP, INSERT, DELETE, UPDATE, ALTER >and possibly functions/vbscript etc.) is executed in the database. What >code can be executed? Wouldn't that be code that is not escaped? >So that >means that everything between proper quotes is safe by definition. What >is left is dates, numbers etc. Well, simply use cfqueryparam for them >and you are done. > >Or am I misunderstanding something here? That issue was the catalyst to this discussion, but the security issues we're talking about (at least I am anyway) covers a much larger area. >Jochem > >PS Some suggestions for Josh:- check formfields too >- URLDECODE everything so you can use regex pattern matching >(instead of ";%20DROP%20TABLE%20" match >"[[:space:]]*;[[:space:]]*drop[[:space:]]*table[[:space:]]*" so I can't >simply replace a space with a tab and bypass your filter >- check for all the abovementioned statements Thanks for the suggestion, Jochem, but my script already covers urls, forms and cookies as well as looking for "altered" spaces. I believe you're making suggestions based on the little example I gave, which is not how my script is laid out. It was an altered, simplified example to explain a point. (I make a habit of altering my code slightly when posting it, so I can understand the confusion.) however I do appreciate your comments. Josh - [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 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 CF Web Sites and Applications
> So in order to get this performance boost we wouldn't be able > to use CF if's in the statement? I have one query which I made > that has something like this > > If this > where something = #something# > end if > > So am I correct in assuming cfqueryparam would have no > benefit for me unless I made seperate queries? Fortunately, no, you're not correct. The prepared statement is generated at runtime, using the string you create with your CF conditional logic. However, you can't use the CF 4+ CACHEDWITHIN/CACHEDAFTER attributes with CFQUERYPARAM. 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 CF Web Sites and Applications
So in order to get this performance boost we wouldn't be able to use CF if's in the statement? I have one query which I made that has something liek this If this where something = #something# end if So am I correct in assuming cfqueryparam would have no benefit for me unless I made seperate queries? Robert Everland III Dixon Ticonderoga Web Developer Extraordinaire -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 11:16 PM To: CF-Talk Subject: RE: Hacking CF Web Sites and Applications > Interested in hearing more about the cfqueryparam tag... 4.5 version > addition I suspect? I think it was introduced in CF 4.0.1, but I'm not sure - it may have been introduced in CF 4.5.x. There isn't much to say about it - you can use it within a CFQUERY tag to wrap a variable that you're passing into your SQL string. This can improve both security and performance. When you use it, you're building what's usually called a "prepared statement", in which the variables are replaced by placeholders, allowing the SQL engine to parse the statement itself before inserting the variables. The CFQUERYPARAM creates what's called a "bind parameter", which is the variable passed along with the prepared statement. Oracle especially seems to get a performance boost from using prepared statements. 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 CF Web Sites and Applications
Paris Lundis wrote: > Awesome reference John.. thanks so much... Off to test it a bit tonight > with our system... Yeah even on the Access databases for fun :) It works without improving speed. But of course the original purpose of this thread was increased security and it will do just that. Jochem ~~ 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 CF Web Sites and Applications
Awesome reference John.. thanks so much... Off to test it a bit tonight with our system... Yeah even on the Access databases for fun :) -paris [finding the future in the past, passing the future in the present] [connecting people, places and things] -Original Message- From: "John Cummings" <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2001 23:21:26 -0400 Subject: RE: Hacking CF Web Sites and Applications > If you're interested in more detailed information, you might want to > check out the following KB article - which goes in to a pretty fair > bit > of detail - specifically related to Oracle > > http://www.allaire.com/handlers/index.cfm?ID=17324&Method=Full > > John > > -Original Message- > From: Paris Lundis [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 11:05 PM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > Interested in hearing more about the cfqueryparam tag... 4.5 version > addition I suspect? > > Syntax and use in Mastering ColdFusion 4.5 book leave a lot to be > desired... > > Anyone using it and what for...??? > > > -paris > [finding the future in the past, passing the future in the present] > [connecting people, places and things] > > > -Original Message- > From: Jochem van Dieten <[EMAIL PROTECTED]> > Date: Mon, 13 Aug 2001 22:29:13 +0200 > Subject: Re: Hacking CF Web Sites and Applications > > > Josh R wrote: > > > This may be simple minded, but you don't need to know every word > > they use. A > > > filter that elaborate would make a site practically useless. > > However, most > > > (actually all) hacks must contain a specific syntax to initiate > the > > security > > > hole. For example, the URL attacks on you followed a > > > "...90;%20DROP%20TABLE%20IMAGES..." syntax. My script just looks > > for a > > > hardly-used-always-the-same portion of that needed syntax such as > > > ";%20DROP%20TABLE%20" to trigger the lockout. > > > > > > I've had some pretty good responses to my little script. It > doesn't > > cover > > > every known hack, but then what does? It's better then just > > complaining > > > about the problem. > > > > > > BTW, I'm on the lookout for more "hack syntax" that I can > > incorporate into > > > the script. I've added all the ones I know of. If you know of > > specific > > > coding that is incorporated htrough a CFM page, please email me > OFF > > LIST so > > > I can see about increasing the power of my cf_antihack script. > > > > Why a filter looking for words in a URL? > > > > AFAIK the issue is that code (like DROP, INSERT, DELETE, UPDATE, > ALTER > > and possibly functions/vbscript etc.) is executed in the database. > > What > > code can be executed? Wouldn't that be code that is not escaped? So > > that > > means that everything between proper quotes is safe by definition. > > What > > is left is dates, numbers etc. Well, simply use cfqueryparam for > them > > and you are done. > > > > Or am I misunderstanding something here? > > > > Jochem > > > > PS Some suggestions for Josh:- check formfields too > > - URLDECODE everything so you can use regex pattern matching > (instead > > of ";%20DROP%20TABLE%20" match > > "[[:space:]]*;[[:space:]]*drop[[:space:]]*table[[:space:]]*" so I > > can't simply replace a space with a tab and bypass your filter > > - check for all the abovementioned statements > > > > > > > ~~ 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 CF Web Sites and Applications
If you're interested in more detailed information, you might want to check out the following KB article - which goes in to a pretty fair bit of detail - specifically related to Oracle http://www.allaire.com/handlers/index.cfm?ID=17324&Method=Full John -Original Message- From: Paris Lundis [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 11:05 PM To: CF-Talk Subject: Re: Hacking CF Web Sites and Applications Interested in hearing more about the cfqueryparam tag... 4.5 version addition I suspect? Syntax and use in Mastering ColdFusion 4.5 book leave a lot to be desired... Anyone using it and what for...??? -paris [finding the future in the past, passing the future in the present] [connecting people, places and things] -Original Message- From: Jochem van Dieten <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2001 22:29:13 +0200 Subject: Re: Hacking CF Web Sites and Applications > Josh R wrote: > > This may be simple minded, but you don't need to know every word > they use. A > > filter that elaborate would make a site practically useless. > However, most > > (actually all) hacks must contain a specific syntax to initiate the > security > > hole. For example, the URL attacks on you followed a > > "...90;%20DROP%20TABLE%20IMAGES..." syntax. My script just looks > for a > > hardly-used-always-the-same portion of that needed syntax such as > > ";%20DROP%20TABLE%20" to trigger the lockout. > > > > I've had some pretty good responses to my little script. It doesn't > cover > > every known hack, but then what does? It's better then just > complaining > > about the problem. > > > > BTW, I'm on the lookout for more "hack syntax" that I can > incorporate into > > the script. I've added all the ones I know of. If you know of > specific > > coding that is incorporated htrough a CFM page, please email me OFF > LIST so > > I can see about increasing the power of my cf_antihack script. > > Why a filter looking for words in a URL? > > AFAIK the issue is that code (like DROP, INSERT, DELETE, UPDATE, ALTER > and possibly functions/vbscript etc.) is executed in the database. > What > code can be executed? Wouldn't that be code that is not escaped? So > that > means that everything between proper quotes is safe by definition. > What > is left is dates, numbers etc. Well, simply use cfqueryparam for them > and you are done. > > Or am I misunderstanding something here? > > Jochem > > PS Some suggestions for Josh:- check formfields too > - URLDECODE everything so you can use regex pattern matching (instead > of ";%20DROP%20TABLE%20" match > "[[:space:]]*;[[:space:]]*drop[[:space:]]*table[[:space:]]*" so I > can't simply replace a space with a tab and bypass your filter > - check for all the abovementioned statements > > > ~~ 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 CF Web Sites and Applications
> Interested in hearing more about the cfqueryparam tag... 4.5 version > addition I suspect? I think it was introduced in CF 4.0.1, but I'm not sure - it may have been introduced in CF 4.5.x. There isn't much to say about it - you can use it within a CFQUERY tag to wrap a variable that you're passing into your SQL string. This can improve both security and performance. When you use it, you're building what's usually called a "prepared statement", in which the variables are replaced by placeholders, allowing the SQL engine to parse the statement itself before inserting the variables. The CFQUERYPARAM creates what's called a "bind parameter", which is the variable passed along with the prepared statement. Oracle especially seems to get a performance boost from using prepared statements. 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 CF Web Sites and Applications
Interested in hearing more about the cfqueryparam tag... 4.5 version addition I suspect? Syntax and use in Mastering ColdFusion 4.5 book leave a lot to be desired... Anyone using it and what for...??? -paris [finding the future in the past, passing the future in the present] [connecting people, places and things] -Original Message- From: Jochem van Dieten <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2001 22:29:13 +0200 Subject: Re: Hacking CF Web Sites and Applications > Josh R wrote: > > This may be simple minded, but you don't need to know every word > they use. A > > filter that elaborate would make a site practically useless. > However, most > > (actually all) hacks must contain a specific syntax to initiate the > security > > hole. For example, the URL attacks on you followed a > > "...90;%20DROP%20TABLE%20IMAGES..." syntax. My script just looks > for a > > hardly-used-always-the-same portion of that needed syntax such as > > ";%20DROP%20TABLE%20" to trigger the lockout. > > > > I've had some pretty good responses to my little script. It doesn't > cover > > every known hack, but then what does? It's better then just > complaining > > about the problem. > > > > BTW, I'm on the lookout for more "hack syntax" that I can > incorporate into > > the script. I've added all the ones I know of. If you know of > specific > > coding that is incorporated htrough a CFM page, please email me OFF > LIST so > > I can see about increasing the power of my cf_antihack script. > > Why a filter looking for words in a URL? > > AFAIK the issue is that code (like DROP, INSERT, DELETE, UPDATE, > ALTER > and possibly functions/vbscript etc.) is executed in the database. > What > code can be executed? Wouldn't that be code that is not escaped? So > that > means that everything between proper quotes is safe by definition. > What > is left is dates, numbers etc. Well, simply use cfqueryparam for them > and you are done. > > Or am I misunderstanding something here? > > Jochem > > PS Some suggestions for Josh:- check formfields too > - URLDECODE everything so you can use regex pattern matching > (instead of ";%20DROP%20TABLE%20" match > "[[:space:]]*;[[:space:]]*drop[[:space:]]*table[[:space:]]*" so I > can't > simply replace a space with a tab and bypass your filter > - check for all the abovementioned statements > > > ~~ 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 CF Web Sites and Applications
Josh R wrote: > This may be simple minded, but you don't need to know every word they use. A > filter that elaborate would make a site practically useless. However, most > (actually all) hacks must contain a specific syntax to initiate the security > hole. For example, the URL attacks on you followed a > "...90;%20DROP%20TABLE%20IMAGES..." syntax. My script just looks for a > hardly-used-always-the-same portion of that needed syntax such as > ";%20DROP%20TABLE%20" to trigger the lockout. > > I've had some pretty good responses to my little script. It doesn't cover > every known hack, but then what does? It's better then just complaining > about the problem. > > BTW, I'm on the lookout for more "hack syntax" that I can incorporate into > the script. I've added all the ones I know of. If you know of specific > coding that is incorporated htrough a CFM page, please email me OFF LIST so > I can see about increasing the power of my cf_antihack script. Why a filter looking for words in a URL? AFAIK the issue is that code (like DROP, INSERT, DELETE, UPDATE, ALTER and possibly functions/vbscript etc.) is executed in the database. What code can be executed? Wouldn't that be code that is not escaped? So that means that everything between proper quotes is safe by definition. What is left is dates, numbers etc. Well, simply use cfqueryparam for them and you are done. Or am I misunderstanding something here? Jochem PS Some suggestions for Josh:- check formfields too - URLDECODE everything so you can use regex pattern matching (instead of ";%20DROP%20TABLE%20" match "[[:space:]]*;[[:space:]]*drop[[:space:]]*table[[:space:]]*" so I can't simply replace a space with a tab and bypass your filter - check for all the abovementioned statements ~~ 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 CF Web Sites and Applications
This may be simple minded, but you don't need to know every word they use. A filter that elaborate would make a site practically useless. However, most (actually all) hacks must contain a specific syntax to initiate the security hole. For example, the URL attacks on you followed a "...90;%20DROP%20TABLE%20IMAGES..." syntax. My script just looks for a hardly-used-always-the-same portion of that needed syntax such as ";%20DROP%20TABLE%20" to trigger the lockout. I've had some pretty good responses to my little script. It doesn't cover every known hack, but then what does? It's better then just complaining about the problem. BTW, I'm on the lookout for more "hack syntax" that I can incorporate into the script. I've added all the ones I know of. If you know of specific coding that is incorporated htrough a CFM page, please email me OFF LIST so I can see about increasing the power of my cf_antihack script. Josh - [EMAIL PROTECTED] cf-codes - http://www.rubak.com/cf-codes.cfm >-- > >Date: Sun, 12 Aug 2001 16:38:36 -0600 >From: "Don Vawter" <[EMAIL PROTECTED]> >Subject: Re: Hacking CF Web Sites and Applications >Message-ID: <01ca01c1237f$8651c890$6501a8c0@VAIO> > >No I didnt write a filter. IMO such an attempt is unlikely to work because >one would have to guess in advance all the words a hacker could use and I >am >not that clever. > _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp 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 CF Web Sites and Applications
Adam Reynolds wrote: > We've tried this with Oracle as well, and it does not work. This would > leave a major hole in a lot of apps if this did work. Only in bad applications. And according to the docs on the Allaire website it does work for quitesome applications. Jochem ~~ 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 CF Web Sites and Applications
We've tried this with Oracle as well, and it does not work. This would leave a major hole in a lot of apps if this did work. -Original Message- From: Bosky, Dave [SMTP:[EMAIL PROTECTED]] Sent: 13 August 2001 14:44 To: CF-Talk Subject: RE: Hacking CF Web Sites and Applications That's what I was thinking. ~Dave -Original Message- From: Andrew Tyrone [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 9:34 AM To: CF-Talk Subject: RE: Hacking CF Web Sites and Applications I might be wrong, but I don't think you can issue multiple SQL commands to Access in this way. -Andy > -Original Message- > From: Bosky, Dave [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:25 AM > To: CF-Talk > Subject: RE: Hacking CF Web Sites and Applications > > > SELECT myitem, myphoto > FROM mystuff > WHERE Show=#URL.Show# > > > -Original Message- > From: Don Vawter [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:12 AM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > Let us see the query where you used the url.show parameter. Also > as an aid, > turn on debugging in cf and grab the actual generated query to > see what you > db actually saw > > - Original Message - > From: "Bosky, Dave" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, August 13, 2001 7:02 AM > Subject: RE: Hacking CF Web Sites and Applications > > > > Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' > > I attempted to drop my table and it failed. Why didn't it drop the > > table? Either I've done something to prevent it that I'm unaware of or > > I used invalid syntax. > > > > --- > > [Microsoft][ODBC Microsoft Access Driver] Characters found after end > > of > SQL > > statement. > > --- > > > > Thanks. > > Dave > > > > > > > > > > > > -Original Message- > > From: Don Vawter [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 12, 2001 11:01 AM > > To: CF-Talk > > Subject: Re: Hacking CF Web Sites and Applications > > > > > > I have a page on preventing url hacks which was derived from the > > school of hard knocks after it happened to me > > http://www.vawter.com/urlhack.cfm > > > > - Original Message - > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Sunday, August 12, 2001 8:37 AM > > Subject: Hacking CF Web Sites and Applications > > > > > > > Hi all, > > > > > > Any one got general advice on how to prevent hackers from getting > > > access > > to > > > CF sites via back doors and tampering with data > > > > > > We dont want the hackers to be able to change data via URL > > > strings. > > > > > > e.g Encrypting URL variables etc > > > > > > Anything else we should look at > > > > > > Any good articles out there? > > > > > > Thanks > > > > > > Daryl Fullerton, > > > Managing Partner, > > > BizNet Solutions, > > > Allaire Premier Partner (Ireland) > > > 133 - 137 Lisburn Road > > > Belfast > > > BT9 7AG > > > N.Ireland > > > > > > Direct +44 (0) 28 9022 7888 > > > Tel +44 (0) 028 9022 3224 > > > Fax +44 (0) 028 9022 3223 > > > > > > > ~~ 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 CF Web Sites and Applications
That's what I was thinking. ~Dave -Original Message- From: Andrew Tyrone [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 9:34 AM To: CF-Talk Subject: RE: Hacking CF Web Sites and Applications I might be wrong, but I don't think you can issue multiple SQL commands to Access in this way. -Andy > -Original Message- > From: Bosky, Dave [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:25 AM > To: CF-Talk > Subject: RE: Hacking CF Web Sites and Applications > > > SELECT myitem, myphoto > FROM mystuff > WHERE Show=#URL.Show# > > > -Original Message- > From: Don Vawter [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:12 AM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > Let us see the query where you used the url.show parameter. Also > as an aid, > turn on debugging in cf and grab the actual generated query to > see what you > db actually saw > > - Original Message - > From: "Bosky, Dave" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, August 13, 2001 7:02 AM > Subject: RE: Hacking CF Web Sites and Applications > > > > Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' > > I attempted to drop my table and it failed. Why didn't it drop the > > table? Either I've done something to prevent it that I'm unaware of or > > I used invalid syntax. > > > > --- > > [Microsoft][ODBC Microsoft Access Driver] Characters found after end > > of > SQL > > statement. > > --- > > > > Thanks. > > Dave > > > > > > > > > > > > -Original Message- > > From: Don Vawter [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 12, 2001 11:01 AM > > To: CF-Talk > > Subject: Re: Hacking CF Web Sites and Applications > > > > > > I have a page on preventing url hacks which was derived from the > > school of hard knocks after it happened to me > > http://www.vawter.com/urlhack.cfm > > > > - Original Message - > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Sunday, August 12, 2001 8:37 AM > > Subject: Hacking CF Web Sites and Applications > > > > > > > Hi all, > > > > > > Any one got general advice on how to prevent hackers from getting > > > access > > to > > > CF sites via back doors and tampering with data > > > > > > We dont want the hackers to be able to change data via URL > > > strings. > > > > > > e.g Encrypting URL variables etc > > > > > > Anything else we should look at > > > > > > Any good articles out there? > > > > > > Thanks > > > > > > Daryl Fullerton, > > > Managing Partner, > > > BizNet Solutions, > > > Allaire Premier Partner (Ireland) > > > 133 - 137 Lisburn Road > > > Belfast > > > BT9 7AG > > > N.Ireland > > > > > > Direct +44 (0) 28 9022 7888 > > > Tel +44 (0) 028 9022 3224 > > > Fax +44 (0) 028 9022 3223 > > > > > > > ~~ 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 CF Web Sites and Applications
I might be wrong, but I don't think you can issue multiple SQL commands to Access in this way. -Andy > -Original Message- > From: Bosky, Dave [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:25 AM > To: CF-Talk > Subject: RE: Hacking CF Web Sites and Applications > > > SELECT myitem, myphoto > FROM mystuff > WHERE Show=#URL.Show# > > > -Original Message- > From: Don Vawter [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 13, 2001 9:12 AM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > Let us see the query where you used the url.show parameter. Also > as an aid, > turn on debugging in cf and grab the actual generated query to > see what you > db actually saw > > - Original Message - > From: "Bosky, Dave" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, August 13, 2001 7:02 AM > Subject: RE: Hacking CF Web Sites and Applications > > > > Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' > > I attempted to drop my table and it failed. Why didn't it drop the > > table? Either I've done something to prevent it that I'm unaware of or > > I used invalid syntax. > > > > --- > > [Microsoft][ODBC Microsoft Access Driver] Characters found after end > > of > SQL > > statement. > > ------- > > > > Thanks. > > Dave > > > > > > > > > > > > -Original Message- > > From: Don Vawter [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 12, 2001 11:01 AM > > To: CF-Talk > > Subject: Re: Hacking CF Web Sites and Applications > > > > > > I have a page on preventing url hacks which was derived from the > > school of hard knocks after it happened to me > > http://www.vawter.com/urlhack.cfm > > > > - Original Message - > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Sunday, August 12, 2001 8:37 AM > > Subject: Hacking CF Web Sites and Applications > > > > > > > Hi all, > > > > > > Any one got general advice on how to prevent hackers from getting > > > access > > to > > > CF sites via back doors and tampering with data > > > > > > We dont want the hackers to be able to change data via URL strings. > > > > > > e.g Encrypting URL variables etc > > > > > > Anything else we should look at > > > > > > Any good articles out there? > > > > > > Thanks > > > > > > Daryl Fullerton, > > > Managing Partner, > > > BizNet Solutions, > > > Allaire Premier Partner (Ireland) > > > 133 - 137 Lisburn Road > > > Belfast > > > BT9 7AG > > > N.Ireland > > > > > > Direct +44 (0) 28 9022 7888 > > > Tel +44 (0) 028 9022 3224 > > > Fax +44 (0) 028 9022 3223 > > > > > > > ~~ 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 CF Web Sites and Applications
In your select statement if you wrapped you where whatever = 23 in single quotes, or in a val() statement either of those would keep that from happening. Which is a good thing. -Original Message- From: Bosky, Dave [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 9:02 AM To: CF-Talk Subject: RE: Hacking CF Web Sites and Applications Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' I attempted to drop my table and it failed. Why didn't it drop the table? Either I've done something to prevent it that I'm unaware of or I used invalid syntax. --- [Microsoft][ODBC Microsoft Access Driver] Characters found after end of SQL statement. --- Thanks. Dave -Original Message- From: Don Vawter [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 12, 2001 11:01 AM To: CF-Talk Subject: Re: Hacking CF Web Sites and Applications I have a page on preventing url hacks which was derived from the school of hard knocks after it happened to me http://www.vawter.com/urlhack.cfm - Original Message - From: "Daryl Fullerton" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 12, 2001 8:37 AM Subject: Hacking CF Web Sites and Applications > Hi all, > > Any one got general advice on how to prevent hackers from getting > access to > CF sites via back doors and tampering with data > > We dont want the hackers to be able to change data via URL strings. > > e.g Encrypting URL variables etc > > Anything else we should look at > > Any good articles out there? > > Thanks > > Daryl Fullerton, > Managing Partner, > BizNet Solutions, > Allaire Premier Partner (Ireland) > 133 - 137 Lisburn Road > Belfast > BT9 7AG > N.Ireland > > Direct +44 (0) 28 9022 7888 > Tel +44 (0) 028 9022 3224 > Fax +44 (0) 028 9022 3223 ~~ 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 CF Web Sites and Applications
SELECT myitem, myphoto FROM mystuff WHERE Show=#URL.Show# -Original Message- From: Don Vawter [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 9:12 AM To: CF-Talk Subject: Re: Hacking CF Web Sites and Applications Let us see the query where you used the url.show parameter. Also as an aid, turn on debugging in cf and grab the actual generated query to see what you db actually saw - Original Message - From: "Bosky, Dave" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, August 13, 2001 7:02 AM Subject: RE: Hacking CF Web Sites and Applications > Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' > I attempted to drop my table and it failed. Why didn't it drop the > table? Either I've done something to prevent it that I'm unaware of or > I used invalid syntax. > > --- > [Microsoft][ODBC Microsoft Access Driver] Characters found after end > of SQL > statement. > --- > > Thanks. > Dave > > > > > > -Original Message- > From: Don Vawter [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 12, 2001 11:01 AM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > I have a page on preventing url hacks which was derived from the > school of hard knocks after it happened to me > http://www.vawter.com/urlhack.cfm > > - Original Message - > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, August 12, 2001 8:37 AM > Subject: Hacking CF Web Sites and Applications > > > > Hi all, > > > > Any one got general advice on how to prevent hackers from getting > > access > to > > CF sites via back doors and tampering with data > > > > We dont want the hackers to be able to change data via URL strings. > > > > e.g Encrypting URL variables etc > > > > Anything else we should look at > > > > Any good articles out there? > > > > Thanks > > > > Daryl Fullerton, > > Managing Partner, > > BizNet Solutions, > > Allaire Premier Partner (Ireland) > > 133 - 137 Lisburn Road > > Belfast > > BT9 7AG > > N.Ireland > > > > Direct +44 (0) 28 9022 7888 > > Tel +44 (0) 028 9022 3224 > > Fax +44 (0) 028 9022 3223 > > > ~~ 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 CF Web Sites and Applications
Let us see the query where you used the url.show parameter. Also as an aid, turn on debugging in cf and grab the actual generated query to see what you db actually saw - Original Message - From: "Bosky, Dave" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, August 13, 2001 7:02 AM Subject: RE: Hacking CF Web Sites and Applications > Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' > I attempted to drop my table and it failed. Why didn't it drop the table? > Either I've done something to prevent it that I'm unaware of or I used > invalid > syntax. > > --- > [Microsoft][ODBC Microsoft Access Driver] Characters found after end of SQL > statement. > --- > > Thanks. > Dave > > > > > > -Original Message- > From: Don Vawter [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 12, 2001 11:01 AM > To: CF-Talk > Subject: Re: Hacking CF Web Sites and Applications > > > I have a page on preventing url hacks which was derived from the school of > hard knocks after it happened to me http://www.vawter.com/urlhack.cfm > > - Original Message - > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, August 12, 2001 8:37 AM > Subject: Hacking CF Web Sites and Applications > > > > Hi all, > > > > Any one got general advice on how to prevent hackers from getting > > access > to > > CF sites via back doors and tampering with data > > > > We dont want the hackers to be able to change data via URL strings. > > > > e.g Encrypting URL variables etc > > > > Anything else we should look at > > > > Any good articles out there? > > > > Thanks > > > > Daryl Fullerton, > > Managing Partner, > > BizNet Solutions, > > Allaire Premier Partner (Ireland) > > 133 - 137 Lisburn Road > > Belfast > > BT9 7AG > > N.Ireland > > > > Direct +44 (0) 28 9022 7888 > > Tel +44 (0) 028 9022 3224 > > Fax +44 (0) 028 9022 3223 > > > ~~ 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 CF Web Sites and Applications
Using the url 'xxx.cfm?show=23;%20DROP%20TABLE%20MyStuff' I attempted to drop my table and it failed. Why didn't it drop the table? Either I've done something to prevent it that I'm unaware of or I used invalid syntax. --- [Microsoft][ODBC Microsoft Access Driver] Characters found after end of SQL statement. --- Thanks. Dave -Original Message- From: Don Vawter [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 12, 2001 11:01 AM To: CF-Talk Subject: Re: Hacking CF Web Sites and Applications I have a page on preventing url hacks which was derived from the school of hard knocks after it happened to me http://www.vawter.com/urlhack.cfm - Original Message - From: "Daryl Fullerton" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 12, 2001 8:37 AM Subject: Hacking CF Web Sites and Applications > Hi all, > > Any one got general advice on how to prevent hackers from getting > access to > CF sites via back doors and tampering with data > > We dont want the hackers to be able to change data via URL strings. > > e.g Encrypting URL variables etc > > Anything else we should look at > > Any good articles out there? > > Thanks > > Daryl Fullerton, > Managing Partner, > BizNet Solutions, > Allaire Premier Partner (Ireland) > 133 - 137 Lisburn Road > Belfast > BT9 7AG > N.Ireland > > Direct +44 (0) 28 9022 7888 > Tel +44 (0) 028 9022 3224 > Fax +44 (0) 028 9022 3223 ~~ 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 CF Web Sites and Applications
Thanks Michael, Daryl Fullerton, Managing Partner, BizNet Solutions, Allaire Premier Partner (Ireland) 133 - 137 Lisburn Road Belfast BT9 7AG N.Ireland Direct +44 (0) 28 9022 7888 Tel +44 (0) 028 9022 3224 Fax +44 (0) 028 9022 3223 [EMAIL PROTECTED] Http://www.BizNet-Solutions.com [EMAIL PROTECTED] (Chairman) Http://www.cfug.ie The Irish Cold Fusion User Group - Original Message - From: "Michael Dinowitz" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, August 13, 2001 5:22 AM Subject: Re: Hacking CF Web Sites and Applications > Your welcome. :) > > > A book I found last month has some useful info on URLs and CFIncludes (a > > chapter devoted to CF): > > "HackProofing Your Web Applications" by Jeff Forrisal and Julie Traxler > > (Syngress Publications) > > > > Thanks, > > Mark > > > > -Original Message- > > From: Daryl Fullerton [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 12, 2001 10:38 AM > > To: CF-Talk > > Subject: Hacking CF Web Sites and Applications > > > > > > Hi all, > > > > Any one got general advice on how to prevent hackers from getting access > to > > CF sites via back doors and tampering with data > > > > We dont want the hackers to be able to change data via URL strings. > > > > e.g Encrypting URL variables etc > > > > Anything else we should look at > > > > Any good articles out there? > > > > Thanks > > > > Daryl Fullerton, > > Managing Partner, > > BizNet Solutions, > > Allaire Premier Partner (Ireland) > > 133 - 137 Lisburn Road > > Belfast > > BT9 7AG > > N.Ireland > > > > Direct +44 (0) 28 9022 7888 > > Tel +44 (0) 028 9022 3224 > > Fax +44 (0) 028 9022 3223 > > > > > > [EMAIL PROTECTED] > > Http://www.BizNet-Solutions.com > > > > [EMAIL PROTECTED] (Chairman) > > Http://www.cfug.ie The Irish Cold Fusion User Group > > > > - Original Message - > > From: "Dave Watts" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Saturday, August 11, 2001 7:32 PM > > Subject: RE: CF and Verity Information Server > > > > > > > > Anyone have any experience using a Verity server EXTERNAL to the CF > > > > Server? Running the Verity included with CF5 is hitting the server's > > > > performance too much so we set up a second server running Verity > > > > Information Server 3.7. > > > > > > > > But I haven't the foggiest idea where to begin telling CF5 to use that > > > > external server for search processing, etc. > > > > > > > > Can anyone point me to any documentation on this? > > > > > > I'm pretty sure you can set up the K2 server included with CF 5 on a > > > different machine, and connect to it from the CF 5 server. I haven't > > > actually tried this yet, though. The K2 stuff is covered somewhat in the > > CF > > > 5 docs, available in PDF on the Macromedia site. In the CF 5 > > Administrator, > > > you can specify the host and port to connect to. I suspect that indexing > > and > > > collection creation might be a bit more complex using this. > > > > > > In addition, Fig Leaf's own Dave Gallerizzo did a brief Verity > > presentation > > > available here: > > > > > > http://www.figleaf.com/figleafhome/cfug/2001/CFUGAug2001/VerityK2Server.zip > > > > > > 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 CF Web Sites and Applications
Your welcome. :) > A book I found last month has some useful info on URLs and CFIncludes (a > chapter devoted to CF): > "HackProofing Your Web Applications" by Jeff Forrisal and Julie Traxler > (Syngress Publications) > > Thanks, > Mark > > -Original Message- > From: Daryl Fullerton [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 12, 2001 10:38 AM > To: CF-Talk > Subject: Hacking CF Web Sites and Applications > > > Hi all, > > Any one got general advice on how to prevent hackers from getting access to > CF sites via back doors and tampering with data > > We dont want the hackers to be able to change data via URL strings. > > e.g Encrypting URL variables etc > > Anything else we should look at > > Any good articles out there? > > Thanks > > Daryl Fullerton, > Managing Partner, > BizNet Solutions, > Allaire Premier Partner (Ireland) > 133 - 137 Lisburn Road > Belfast > BT9 7AG > N.Ireland > > Direct +44 (0) 28 9022 7888 > Tel +44 (0) 028 9022 3224 > Fax +44 (0) 028 9022 3223 > > > [EMAIL PROTECTED] > Http://www.BizNet-Solutions.com > > [EMAIL PROTECTED] (Chairman) > Http://www.cfug.ie The Irish Cold Fusion User Group > > - Original Message - > From: "Dave Watts" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Saturday, August 11, 2001 7:32 PM > Subject: RE: CF and Verity Information Server > > > > > Anyone have any experience using a Verity server EXTERNAL to the CF > > > Server? Running the Verity included with CF5 is hitting the server's > > > performance too much so we set up a second server running Verity > > > Information Server 3.7. > > > > > > But I haven't the foggiest idea where to begin telling CF5 to use that > > > external server for search processing, etc. > > > > > > Can anyone point me to any documentation on this? > > > > I'm pretty sure you can set up the K2 server included with CF 5 on a > > different machine, and connect to it from the CF 5 server. I haven't > > actually tried this yet, though. The K2 stuff is covered somewhat in the > CF > > 5 docs, available in PDF on the Macromedia site. In the CF 5 > Administrator, > > you can specify the host and port to connect to. I suspect that indexing > and > > collection creation might be a bit more complex using this. > > > > In addition, Fig Leaf's own Dave Gallerizzo did a brief Verity > presentation > > available here: > > > http://www.figleaf.com/figleafhome/cfug/2001/CFUGAug2001/VerityK2Server.zip > > > > 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 CF Web Sites and Applications
A book I found last month has some useful info on URLs and CFIncludes (a chapter devoted to CF): "HackProofing Your Web Applications" by Jeff Forrisal and Julie Traxler (Syngress Publications) Thanks, Mark -Original Message- From: Daryl Fullerton [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 12, 2001 10:38 AM To: CF-Talk Subject: Hacking CF Web Sites and Applications Hi all, Any one got general advice on how to prevent hackers from getting access to CF sites via back doors and tampering with data We dont want the hackers to be able to change data via URL strings. e.g Encrypting URL variables etc Anything else we should look at Any good articles out there? Thanks Daryl Fullerton, Managing Partner, BizNet Solutions, Allaire Premier Partner (Ireland) 133 - 137 Lisburn Road Belfast BT9 7AG N.Ireland Direct +44 (0) 28 9022 7888 Tel +44 (0) 028 9022 3224 Fax +44 (0) 028 9022 3223 [EMAIL PROTECTED] Http://www.BizNet-Solutions.com [EMAIL PROTECTED] (Chairman) Http://www.cfug.ie The Irish Cold Fusion User Group - Original Message - From: "Dave Watts" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Saturday, August 11, 2001 7:32 PM Subject: RE: CF and Verity Information Server > > Anyone have any experience using a Verity server EXTERNAL to the CF > > Server? Running the Verity included with CF5 is hitting the server's > > performance too much so we set up a second server running Verity > > Information Server 3.7. > > > > But I haven't the foggiest idea where to begin telling CF5 to use that > > external server for search processing, etc. > > > > Can anyone point me to any documentation on this? > > I'm pretty sure you can set up the K2 server included with CF 5 on a > different machine, and connect to it from the CF 5 server. I haven't > actually tried this yet, though. The K2 stuff is covered somewhat in the CF > 5 docs, available in PDF on the Macromedia site. In the CF 5 Administrator, > you can specify the host and port to connect to. I suspect that indexing and > collection creation might be a bit more complex using this. > > In addition, Fig Leaf's own Dave Gallerizzo did a brief Verity presentation > available here: > http://www.figleaf.com/figleafhome/cfug/2001/CFUGAug2001/VerityK2Server.zip > > 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 CF Web Sites and Applications
http://www.rubak.com/cf-codes.cfm This script (which I thought was free last time I checked but is now $5) is a collection of "anti hack" scripts that looks for common SQL hacks (Drop etc) This is probobally the link you lost? > > Was it you who had wrote the URL filed filter to eliminate DROPs and > > such?? A conversation tat went around a few weeks ago and got lost in > > my massive inbox :) > > > > We have been experiencing tons of the IDA exploit attempts... Started > > rifling off some nasty notes to admins of where these (mostly cable > > modem) idiots have bandwidth... > > > > Black Ice is cool for monitoring.. love it... Just wish it could be a > > bit more automated on certain attack to draft emails and such... and > > the evidence logs are really organized... > > > > Never thought *I* would need or want to utilize a firewall type > > solution... Needless to say our servers are running much faster as a > > result... Must of had a lot of really crappy traffic stressing the > > servers... Spent about 4 hours last night patching the MS based > > servers.. > > > > In all I consider it worth it.. The URL hack though still concerns > > me :) > > > > -paris > > -Original Message- > > From: "Don Vawter" <[EMAIL PROTECTED]> > > Date: Sun, 12 Aug 2001 09:00:38 -0600 > > Subject: Re: Hacking CF Web Sites and Applications > > > > > I have a page on preventing url hacks which was derived from the > > > school of > > > hard knocks after it happened to me > > > http://www.vawter.com/urlhack.cfm > > > > > > - Original Message - > > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > > To: "CF-Talk" <[EMAIL PROTECTED]> > > > Sent: Sunday, August 12, 2001 8:37 AM > > > Subject: Hacking CF Web Sites and Applications > > > > > > > > > > Hi all, > > > > > > > > Any one got general advice on how to prevent hackers from getting > > > access > > > to > > > > CF sites via back doors and tampering with data > > > > > > > > We dont want the hackers to be able to change data via URL strings. > > > > > > > > e.g Encrypting URL variables etc > > > > > > > > Anything else we should look at > > > > > > > > Any good articles out there? > > > > > > > > Thanks > > > > > > > > Daryl Fullerton, > > > > Managing Partner, > > > > BizNet Solutions, > > > > Allaire Premier Partner (Ireland) > > > > 133 - 137 Lisburn Road > > > > Belfast > > > > BT9 7AG > > > > N.Ireland > > > > > > > > Direct +44 (0) 28 9022 7888 > > > > Tel +44 (0) 028 9022 3224 > > > > Fax +44 (0) 028 9022 3223 > > > > > > > > > > > > > > > > > > > > > ~~ 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 CF Web Sites and Applications
No I didnt write a filter. IMO such an attempt is unlikely to work because one would have to guess in advance all the words a hacker could use and I am not that clever. - Original Message - From: "Paris Lundis" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 12, 2001 3:04 PM Subject: Re: Hacking CF Web Sites and Applications > Don, > > Was it you who had wrote the URL filed filter to eliminate DROPs and > such?? A conversation tat went around a few weeks ago and got lost in > my massive inbox :) > > We have been experiencing tons of the IDA exploit attempts... Started > rifling off some nasty notes to admins of where these (mostly cable > modem) idiots have bandwidth... > > Black Ice is cool for monitoring.. love it... Just wish it could be a > bit more automated on certain attack to draft emails and such... and > the evidence logs are really organized... > > Never thought *I* would need or want to utilize a firewall type > solution... Needless to say our servers are running much faster as a > result... Must of had a lot of really crappy traffic stressing the > servers... Spent about 4 hours last night patching the MS based > servers.. > > In all I consider it worth it.. The URL hack though still concerns > me :) > > -paris > -Original Message----- > From: "Don Vawter" <[EMAIL PROTECTED]> > Date: Sun, 12 Aug 2001 09:00:38 -0600 > Subject: Re: Hacking CF Web Sites and Applications > > > I have a page on preventing url hacks which was derived from the > > school of > > hard knocks after it happened to me > > http://www.vawter.com/urlhack.cfm > > > > - Original Message - > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Sunday, August 12, 2001 8:37 AM > > Subject: Hacking CF Web Sites and Applications > > > > > > > Hi all, > > > > > > Any one got general advice on how to prevent hackers from getting > > access > > to > > > CF sites via back doors and tampering with data > > > > > > We dont want the hackers to be able to change data via URL strings. > > > > > > e.g Encrypting URL variables etc > > > > > > Anything else we should look at > > > > > > Any good articles out there? > > > > > > Thanks > > > > > > Daryl Fullerton, > > > Managing Partner, > > > BizNet Solutions, > > > Allaire Premier Partner (Ireland) > > > 133 - 137 Lisburn Road > > > Belfast > > > BT9 7AG > > > N.Ireland > > > > > > Direct +44 (0) 28 9022 7888 > > > Tel +44 (0) 028 9022 3224 > > > Fax +44 (0) 028 9022 3223 > > > > > > > > > > > > > ~~ 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 CF Web Sites and Applications
Sorry to scare you. Just a demo. Doesn't do anything - Original Message - From: "Bill Davidson" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 12, 2001 3:22 PM Subject: Re: Hacking CF Web Sites and Applications > Hey Don. I was just checking out your page on the drop table URL hack. You > give a URL to test the hack attempt, but don't forewarn that if clicked on, > you're going to inform my ISP that I was trying to hack into your site. Or > is that warning just a demo? Please clarify. > > -Bill > brainbox > - Original Message - > From: "Don Vawter" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, August 12, 2001 11:00 AM > Subject: Re: Hacking CF Web Sites and Applications > > > > I have a page on preventing url hacks which was derived from the school of > > hard knocks after it happened to me > > http://www.vawter.com/urlhack.cfm > > > > - Original Message - > > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Sunday, August 12, 2001 8:37 AM > > Subject: Hacking CF Web Sites and Applications > > > > > > > Hi all, > > > > > > Any one got general advice on how to prevent hackers from getting access > > to > > > CF sites via back doors and tampering with data > > > > > > We dont want the hackers to be able to change data via URL strings. > > > > > > e.g Encrypting URL variables etc > > > > > > Anything else we should look at > > > > > > Any good articles out there? > > > > > > Thanks > > > > > > Daryl Fullerton, > > > Managing Partner, > > > BizNet Solutions, > > > Allaire Premier Partner (Ireland) > > > 133 - 137 Lisburn Road > > > Belfast > > > BT9 7AG > > > N.Ireland > > > > > > Direct +44 (0) 28 9022 7888 > > > Tel +44 (0) 028 9022 3224 > > > Fax +44 (0) 028 9022 3223 > > > > > > > > > > > > > ~~ 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 CF Web Sites and Applications
Hey Don. I was just checking out your page on the drop table URL hack. You give a URL to test the hack attempt, but don't forewarn that if clicked on, you're going to inform my ISP that I was trying to hack into your site. Or is that warning just a demo? Please clarify. -Bill brainbox - Original Message - From: "Don Vawter" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Sunday, August 12, 2001 11:00 AM Subject: Re: Hacking CF Web Sites and Applications > I have a page on preventing url hacks which was derived from the school of > hard knocks after it happened to me > http://www.vawter.com/urlhack.cfm > > - Original Message - > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, August 12, 2001 8:37 AM > Subject: Hacking CF Web Sites and Applications > > > > Hi all, > > > > Any one got general advice on how to prevent hackers from getting access > to > > CF sites via back doors and tampering with data > > > > We dont want the hackers to be able to change data via URL strings. > > > > e.g Encrypting URL variables etc > > > > Anything else we should look at > > > > Any good articles out there? > > > > Thanks > > > > Daryl Fullerton, > > Managing Partner, > > BizNet Solutions, > > Allaire Premier Partner (Ireland) > > 133 - 137 Lisburn Road > > Belfast > > BT9 7AG > > N.Ireland > > > > Direct +44 (0) 28 9022 7888 > > Tel +44 (0) 028 9022 3224 > > Fax +44 (0) 028 9022 3223 > > > > > > ~~ 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 CF Web Sites and Applications
Daryl Fullerton wrote: > Hi all, > > Any one got general advice on how to prevent hackers from getting access to > CF sites via back doors and tampering with data Non-scoped variables are my favourites if I have to prove somebodies security is bad ;) > We dont want the hackers to be able to change data via URL strings. Use cfqueryparam for every variable in queries. > e.g Encrypting URL variables etc If it needs encrypting you shouldn't pass it through a URL anyway. > Any good articles out there? Did you read http://www.allaire.com/security/ Jochem ~~ 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 CF Web Sites and Applications
Don, Was it you who had wrote the URL filed filter to eliminate DROPs and such?? A conversation tat went around a few weeks ago and got lost in my massive inbox :) We have been experiencing tons of the IDA exploit attempts... Started rifling off some nasty notes to admins of where these (mostly cable modem) idiots have bandwidth... Black Ice is cool for monitoring.. love it... Just wish it could be a bit more automated on certain attack to draft emails and such... and the evidence logs are really organized... Never thought *I* would need or want to utilize a firewall type solution... Needless to say our servers are running much faster as a result... Must of had a lot of really crappy traffic stressing the servers... Spent about 4 hours last night patching the MS based servers.. In all I consider it worth it.. The URL hack though still concerns me :) -paris -Original Message- From: "Don Vawter" <[EMAIL PROTECTED]> Date: Sun, 12 Aug 2001 09:00:38 -0600 Subject: Re: Hacking CF Web Sites and Applications > I have a page on preventing url hacks which was derived from the > school of > hard knocks after it happened to me > http://www.vawter.com/urlhack.cfm > > - Original Message - > From: "Daryl Fullerton" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Sunday, August 12, 2001 8:37 AM > Subject: Hacking CF Web Sites and Applications > > > > Hi all, > > > > Any one got general advice on how to prevent hackers from getting > access > to > > CF sites via back doors and tampering with data > > > > We dont want the hackers to be able to change data via URL strings. > > > > e.g Encrypting URL variables etc > > > > Anything else we should look at > > > > Any good articles out there? > > > > Thanks > > > > Daryl Fullerton, > > Managing Partner, > > BizNet Solutions, > > Allaire Premier Partner (Ireland) > > 133 - 137 Lisburn Road > > Belfast > > BT9 7AG > > N.Ireland > > > > Direct +44 (0) 28 9022 7888 > > Tel +44 (0) 028 9022 3224 > > Fax +44 (0) 028 9022 3223 > > > > > > ~~ 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
