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
Hacking?
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:356712 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
Hacking into CFGrid
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:318683
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> perhaps you are right Dave. And Matt. > > I'm going to run over to the "Is Flash really that good" > thread to tell them that using flash solves this issue. No, unfortunately it doesn't. Flash content is just like any other client-side content in that respect. If you want to test this theory, just put up a Flash game on your site, have that game store high scores on your server, and see how quickly people put in impossible scores. For the life of me, I can't imagine why anyone would bother doing that - there's no logical incentive to do so - but it didn't take very long. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 Host with the leader in ColdFusion hosting. Voted #1 ColdFusion host by CF Developers. Offering shared and dedicated hosting options. www.cfxhosting.com/default.cfm?redirect=10481 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
In addition, which I think is a reiteration from something said previously, store Ids and prices, but make sure you use the Ids and recalculate the totals during checkout based on the Ids, not the prices that have been being passed around and potentially altered. - Original Message - From: "Matt Robertson" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 3:06 PM Subject: RE: CFMX Form Submission Hacking. > You're right. That will not protect you, but the problem isn't > Michael's suggestion; its your application design. > > Hidden form vars are just flat out a terrible place to put sensitive > info; a gilded invitation that says 'steal from me' on it. > > Don't rely on form vars to transport any sort of sensitive info. In > fact try not to rely on them for anything (That way when you have to use > one you *know* you had to do it that way). > > > Matt Robertson [EMAIL PROTECTED] > MSB Designs, Inc. http://mysecretbase.com > > > -Original Message- > From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 11:47 AM > To: CF-Talk > Subject: RE: CFMX Form Submission Hacking. > > > Still not sure how what you're saying works. Let me give you a scenario. > > User clicks checkout on the e-commerce app. from his shopping cart. > --> request gets sent to form page; session.notahacker = 1 <-- > The page comes up with a request for his CC info in a form. > The same form has a hidden field with the total purchase amount ($35) > User Clicks Save, to save the html page to his desktop. > User Edits the HTML page to change the amount from $35 to $3 > User Opens the page in a browser from his local machine. > User clicks submit from this page to my web server > --> request gets sent to submit page; session.notahacker is still 1 <-- > > What was solved? > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 1:38 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Form Page - set the session variable equal to 1 > Processing Page - check to see if the session variable equals 1, and if > so, > process the form.. THEN > set the session variable to 0 and carry on. That should work for you. > > Mike > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 2:24 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I'm not sure how that would work Mike... If I set the session > variable, > and the user comes back (within the session timeout timeframe) wouldn't > the > session variable persist? It's not like the session is tied to the page > itself. > > > > -Igor > > > > -Original Message- > > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 12:51 PM > > To: CF-Talk > > Subject: Re: CFMX Form Submission Hacking. > > > > > > Why not just set some kind of variable on the form page itself, such > as > > session.isOnMyServer > > and then on the processing page, check for the existence of that > variable... > > > > Would that not work for you? > > > > Mike > > > > > > - Original Message - > > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > > To: "CF-Talk" <[EMAIL PROTECTED]> > > Sent: Monday, June 23, 2003 1:40 PM > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > I realize this... It will not completely prevent hacking... > > > but I would like to make sure that if a person is on my form page, > they > > are not able to save the page, edit some of the hidden form variables, > and > > then submit the page to my server. I am aware that the referrer can be > > simulated, but that is a deeper degree of the issue I am trying to > solve. > > > > > > -Igor > > > > > > -Original Message- > > > From: Dave Watts [mailto:[EMAIL PROTECTED] > > > Sent: Monday, June 23, 2003 11:41 AM > > > To: CF-Talk > > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > > > > Does anyone have a quick snippet of code that does a regex > > > > match against the referrer to check if a form was submitted > > > > from an internal page (with attention to ports if possible)
RE: CFMX Form Submission Hacking.
I agree with this. I run a artwork voting system on a very popular site and before I wasn't checking to see if the values of the votes (I would add up the scores and divide by the # of votes to get an average) were between 1-10 which was on the HTML form. Much to my surprise I found several scores at 1000 and several scores with values BELOW 1 trying to bring down competing pieces of art. Obviously someone had re-written the form and this is a site catering to 13-25 year olds. And there was no profit motivation either. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 1:31 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. > It's secure enough to the point where only somebody who can > rewrite the raw HTTP header to look like the one on my > servers, is able to get a hack through. This is hard enough > to do, and enough of a rare case, that if they did that, I'm > sure the admins would eventually (if not immediately) notice > the discrepancy (as it is calculated on the admin side), and > void the transaction. I'm trying to avoid this happening on a > large scale. I think you're overestimating the difficulty of rewriting HTTP headers. I think you're also underestimating the population of computer criminals. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
perhaps you are right Dave. And Matt. I'm going to run over to the "Is Flash really that good" thread to tell them that using flash solves this issue. -Igor -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 3:31 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. > It's secure enough to the point where only somebody who can > rewrite the raw HTTP header to look like the one on my > servers, is able to get a hack through. This is hard enough > to do, and enough of a rare case, that if they did that, I'm > sure the admins would eventually (if not immediately) notice > the discrepancy (as it is calculated on the admin side), and > void the transaction. I'm trying to avoid this happening on a > large scale. I think you're overestimating the difficulty of rewriting HTTP headers. I think you're also underestimating the population of computer criminals. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> It's secure enough to the point where only somebody who can > rewrite the raw HTTP header to look like the one on my > servers, is able to get a hack through. This is hard enough > to do, and enough of a rare case, that if they did that, I'm > sure the admins would eventually (if not immediately) notice > the discrepancy (as it is calculated on the admin side), and > void the transaction. I'm trying to avoid this happening on a > large scale. I think you're overestimating the difficulty of rewriting HTTP headers. I think you're also underestimating the population of computer criminals. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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: CFMX Form Submission Hacking.
> > > I have opted to circumvent "unnecessary processing" by > > > passing these elements through form fields, which improve my > > > application design and performance. My only issue is making > > > sure that the submission in authentic, which is not that hard > > > to do, only I was hoping that someone here was clever enough > > > to have done it before me. > > > > Why not stick the prices in the Session scope, then, if you > > simply don't want them to change during their transaction? > > I don't use the session scope because it is a clustered > application. I don't like overloading the client scope with > unnecessary information either. I guess we differ on our definition of unnecessary information. The fact remains that your application will be vulnerable to simple price-changing attacks, if you allow that data to be accepted as-is from the form. If that doesn't bother you, why not just look at CGI.HTTP_REFERER in your action page and be done with it? As for making sure the submission is authentic, it's harder to do than you imply. HTTP is a pretty simple protocol, which isn't designed to manage state information. Using the telnet client on nearly any machine, one can send an HTTP request that is indistinguishable from what your browser sends. Using common, freely available tools, one can see what HTTP traffic looks like, in order to build the right request. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 Host with the leader in ColdFusion hosting. Voted #1 ColdFusion host by CF Developers. Offering shared and dedicated hosting options. www.cfxhosting.com/default.cfm?redirect=10481 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
>I don't like overloading the client scope with unnecessary >information either. Where security is concerned, this is not unnecessary. It must seem like everybody is piling on criticism and not listening to what you're asking in the first place, but what you've chosen to do is almost worst-case from a security perspective, and it can't be fixed. I know you've made decisions based on load etc., but you have to think this over again or you will be burned hard; sooner rather than later if this has such hi traffic that it needs clustering. --- Matt Robertson, [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com --- ~| 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: CFMX Form Submission Hacking.
It's secure enough to the point where only somebody who can rewrite the raw HTTP header to look like the one on my servers, is able to get a hack through. This is hard enough to do, and enough of a rare case, that if they did that, I'm sure the admins would eventually (if not immediately) notice the discrepancy (as it is calculated on the admin side), and void the transaction. I'm trying to avoid this happening on a large scale. -Igor -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 2:52 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. I do what another poster mentioned: I pass nothing but the session ID and recalculate the cart based on the info in the db. I'm of course unfamiliar with the specifics of your app, but the only thing I think has been done before with regard to passing prices via form vars is hack them. >From an earlier post it sounds like you're reconciled to this info being only >minimally secure, at best. I'm afraid thats about all you can expect with this >approach. I'd still say there's *got* to be a better way to do this. --- Matt Robertson, [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com --- -- Original Message -- From: "Igor Ilyinsky" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Mon, 23 Jun 2003 14:30:12 -0500 >Actually Matt, that is not a solution for this application in particular. If it were >simple, where prices never changed, and other variables were constants, then that >would be a good solution. Also, if there were not such an intensive overhead for >re-calculating everything unnecessarily. > >The loophole in your suggestion is that the user is not getting an absolutely >"accurate" cost for the items they are purchasing if a change of price occurs during >their transaction. In effect, they could enter their CC info for an item that was $33 >when they clicked it, but is now $35 after your admin realized the demand went up. In >some ways I'm sure this is neither ethical or legal. > >A true solution would be to create an intermediate table that would save the purchase >information between the time they agreed to buy, and the time the purchase went >through. > >I have opted to circumvent "unnecessary processing" by passing these elements through >form fields, which improve my application design and performance. My only issue is >making sure that the submission in authentic, which is not that hard to do, only I >was hoping that someone here was clever enough to have done it before me. > >Apparently not, >Igor > >-Original Message- >From: Matt Robertson [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 2:06 PM >To: CF-Talk >Subject: RE: CFMX Form Submission Hacking. > > >You're right. That will not protect you, but the problem isn't >Michael's suggestion; its your application design. > >Hidden form vars are just flat out a terrible place to put sensitive >info; a gilded invitation that says 'steal from me' on it. > >Don't rely on form vars to transport any sort of sensitive info. In >fact try not to rely on them for anything (That way when you have to use >one you *know* you had to do it that way). > > > Matt Robertson [EMAIL PROTECTED] > MSB Designs, Inc. http://mysecretbase.com > > >-Original Message- >From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 11:47 AM >To: CF-Talk >Subject: RE: CFMX Form Submission Hacking. > > >Still not sure how what you're saying works. Let me give you a scenario. > >User clicks checkout on the e-commerce app. from his shopping cart. >--> request gets sent to form page; session.notahacker = 1 <-- >The page comes up with a request for his CC info in a form. >The same form has a hidden field with the total purchase amount ($35) >User Clicks Save, to save the html page to his desktop. >User Edits the HTML page to change the amount from $35 to $3 >User Opens the page in a browser from his local machine. >User clicks submit from this page to my web server >--> request gets sent to submit page; session.notahacker is still 1 <-- > >What was solved? >-Igor > >-Original Message- >From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 1:38 PM >To: CF-Talk >Subject: Re: CFMX Form Submission Hacking. > > >Form Page - set the session variable equal to 1 >Processing Page - check to see if th
RE: CFMX Form Submission Hacking.
I don't use the session scope because it is a clustered application. I don't like overloading the client scope with unnecessary information either. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 2:47 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. > I have opted to circumvent "unnecessary processing" by > passing these elements through form fields, which improve my > application design and performance. My only issue is making > sure that the submission in authentic, which is not that hard > to do, only I was hoping that someone here was clever enough > to have done it before me. Why not stick the prices in the Session scope, then, if you simply don't want them to change during their transaction? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> Couldn't you also put in some referrer security that looks > for the server's IP or hostname so people can't post it > from other sites/servers? Your web server can't guarantee the reliability of that information - all it really knows is that it received a request from a specific IP address. Beyond that, it just takes for granted whatever the browser tells it. Or, more accurately, whatever's in the stream of text it received. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
I do what another poster mentioned: I pass nothing but the session ID and recalculate the cart based on the info in the db. I'm of course unfamiliar with the specifics of your app, but the only thing I think has been done before with regard to passing prices via form vars is hack them. >From an earlier post it sounds like you're reconciled to this info being only >minimally secure, at best. I'm afraid thats about all you can expect with this >approach. I'd still say there's *got* to be a better way to do this. --- Matt Robertson, [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com --- -- Original Message -- From: "Igor Ilyinsky" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Mon, 23 Jun 2003 14:30:12 -0500 >Actually Matt, that is not a solution for this application in particular. If it were >simple, where prices never changed, and other variables were constants, then that >would be a good solution. Also, if there were not such an intensive overhead for >re-calculating everything unnecessarily. > >The loophole in your suggestion is that the user is not getting an absolutely >"accurate" cost for the items they are purchasing if a change of price occurs during >their transaction. In effect, they could enter their CC info for an item that was $33 >when they clicked it, but is now $35 after your admin realized the demand went up. In >some ways I'm sure this is neither ethical or legal. > >A true solution would be to create an intermediate table that would save the purchase >information between the time they agreed to buy, and the time the purchase went >through. > >I have opted to circumvent "unnecessary processing" by passing these elements through >form fields, which improve my application design and performance. My only issue is >making sure that the submission in authentic, which is not that hard to do, only I >was hoping that someone here was clever enough to have done it before me. > >Apparently not, >Igor > >-Original Message- >From: Matt Robertson [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 2:06 PM >To: CF-Talk >Subject: RE: CFMX Form Submission Hacking. > > >You're right. That will not protect you, but the problem isn't >Michael's suggestion; its your application design. > >Hidden form vars are just flat out a terrible place to put sensitive >info; a gilded invitation that says 'steal from me' on it. > >Don't rely on form vars to transport any sort of sensitive info. In >fact try not to rely on them for anything (That way when you have to use >one you *know* you had to do it that way). > > > Matt Robertson [EMAIL PROTECTED] > MSB Designs, Inc. http://mysecretbase.com > > >-Original Message- >From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 11:47 AM >To: CF-Talk >Subject: RE: CFMX Form Submission Hacking. > > >Still not sure how what you're saying works. Let me give you a scenario. > >User clicks checkout on the e-commerce app. from his shopping cart. >--> request gets sent to form page; session.notahacker = 1 <-- >The page comes up with a request for his CC info in a form. >The same form has a hidden field with the total purchase amount ($35) >User Clicks Save, to save the html page to his desktop. >User Edits the HTML page to change the amount from $35 to $3 >User Opens the page in a browser from his local machine. >User clicks submit from this page to my web server >--> request gets sent to submit page; session.notahacker is still 1 <-- > >What was solved? >-Igor > >-Original Message- >From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] >Sent: Monday, June 23, 2003 1:38 PM >To: CF-Talk >Subject: Re: CFMX Form Submission Hacking. > > >Form Page - set the session variable equal to 1 >Processing Page - check to see if the session variable equals 1, and if >so, >process the form.. THEN >set the session variable to 0 and carry on. That should work for you. > >Mike > >- Original Message - >From: "Igor Ilyinsky" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Monday, June 23, 2003 2:24 PM >Subject: RE: CFMX Form Submission Hacking. > > >> I'm not sure how that would work Mike... If I set the session >variable, >and the user comes back (within the session timeout timeframe) wouldn't >the >session variable
RE: CFMX Form Submission Hacking.
Couldn't you also put in some referrer security that looks for the server's IP or hostname so people can't post it from other sites/servers? Personally I do the "recalculate" method... I'm willing to risk a change in price for the 2 minutes it takes someone to fill out a form. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 12:47 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. > I have opted to circumvent "unnecessary processing" by > passing these elements through form fields, which improve my > application design and performance. My only issue is making > sure that the submission in authentic, which is not that hard > to do, only I was hoping that someone here was clever enough > to have done it before me. Why not stick the prices in the Session scope, then, if you simply don't want them to change during their transaction? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> Still not sure how what you're saying works. Let me give you > a scenario. > > User clicks checkout on the e-commerce app. from his shopping cart. > --> request gets sent to form page; session.notahacker = 1 <-- > The page comes up with a request for his CC info in a form. > The same form has a hidden field with the total purchase amount ($35) > User Clicks Save, to save the html page to his desktop. > User Edits the HTML page to change the amount from $35 to $3 > User Opens the page in a browser from his local machine. > User clicks submit from this page to my web server > --> request gets sent to submit page; session.notahacker is > still 1 <-- > > What was solved? The user solved his need for cheaper stuff? Please, please, for the love of ecommerce, don't pass the prices in your form. Or, rather, don't use those prices in your calculations. Use the prices in the database, or somewhere else, as long as they're server-side. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> In addition - can't you use some domain variables to check > that the refererrer is coming from your domain online. If > a user submits from his or her desktop it certainly won't > match your domain. Or path info stuff... you know where > your form is - you can verify the path maybe That's what Mr. Ilyinsky wanted to do in the first place. However, again, any information like this is provided by the browser, and is subject to (pretty easy) tampering. > OR actually - it just came to me.. Basically the concern is > if a page was modified. You can use the HTTP_IF_MODIFIED_SINCE > referer to see if it was modified after a certain date. Sure > anytime you make a change to that form you have a slight > window someone can sneak by and you have to modify that > "check" date but it would prevent what you are referring to. I'm pretty sure that the browser won't send this CGI variable to the server, in the event that you open an HTML page on your filesystem. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
> I have opted to circumvent "unnecessary processing" by > passing these elements through form fields, which improve my > application design and performance. My only issue is making > sure that the submission in authentic, which is not that hard > to do, only I was hoping that someone here was clever enough > to have done it before me. Why not stick the prices in the Session scope, then, if you simply don't want them to change during their transaction? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
Actually Matt, that is not a solution for this application in particular. If it were simple, where prices never changed, and other variables were constants, then that would be a good solution. Also, if there were not such an intensive overhead for re-calculating everything unnecessarily. The loophole in your suggestion is that the user is not getting an absolutely "accurate" cost for the items they are purchasing if a change of price occurs during their transaction. In effect, they could enter their CC info for an item that was $33 when they clicked it, but is now $35 after your admin realized the demand went up. In some ways I'm sure this is neither ethical or legal. A true solution would be to create an intermediate table that would save the purchase information between the time they agreed to buy, and the time the purchase went through. I have opted to circumvent "unnecessary processing" by passing these elements through form fields, which improve my application design and performance. My only issue is making sure that the submission in authentic, which is not that hard to do, only I was hoping that someone here was clever enough to have done it before me. Apparently not, Igor -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 2:06 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. You're right. That will not protect you, but the problem isn't Michael's suggestion; its your application design. Hidden form vars are just flat out a terrible place to put sensitive info; a gilded invitation that says 'steal from me' on it. Don't rely on form vars to transport any sort of sensitive info. In fact try not to rely on them for anything (That way when you have to use one you *know* you had to do it that way). Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com -Original Message- From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 11:47 AM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. Still not sure how what you're saying works. Let me give you a scenario. User clicks checkout on the e-commerce app. from his shopping cart. --> request gets sent to form page; session.notahacker = 1 <-- The page comes up with a request for his CC info in a form. The same form has a hidden field with the total purchase amount ($35) User Clicks Save, to save the html page to his desktop. User Edits the HTML page to change the amount from $35 to $3 User Opens the page in a browser from his local machine. User clicks submit from this page to my web server --> request gets sent to submit page; session.notahacker is still 1 <-- What was solved? -Igor -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 1:38 PM To: CF-Talk Subject: Re: CFMX Form Submission Hacking. Form Page - set the session variable equal to 1 Processing Page - check to see if the session variable equals 1, and if so, process the form.. THEN set the session variable to 0 and carry on. That should work for you. Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 2:24 PM Subject: RE: CFMX Form Submission Hacking. > I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. > > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:51 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Why not just set some kind of variable on the form page itself, such as > session.isOnMyServer > and then on the processing page, check for the existence of that variable... > > Would that not work for you? > > Mike > > > ----- Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 1:40 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I realize this... It will not completely prevent hacking... > > but I would like to make sure that if a person is on my form page, they > are not able to save the page, edit some of the hidden form variables, and > then submit the page to my server. I am aware that the referrer can be > simulated, but that is a deeper degree of the issue I am trying to solve. > > > > -Igor > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROT
RE: CFMX Form Submission Hacking.
You're right. That will not protect you, but the problem isn't Michael's suggestion; its your application design. Hidden form vars are just flat out a terrible place to put sensitive info; a gilded invitation that says 'steal from me' on it. Don't rely on form vars to transport any sort of sensitive info. In fact try not to rely on them for anything (That way when you have to use one you *know* you had to do it that way). Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc. http://mysecretbase.com -Original Message- From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 11:47 AM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. Still not sure how what you're saying works. Let me give you a scenario. User clicks checkout on the e-commerce app. from his shopping cart. --> request gets sent to form page; session.notahacker = 1 <-- The page comes up with a request for his CC info in a form. The same form has a hidden field with the total purchase amount ($35) User Clicks Save, to save the html page to his desktop. User Edits the HTML page to change the amount from $35 to $3 User Opens the page in a browser from his local machine. User clicks submit from this page to my web server --> request gets sent to submit page; session.notahacker is still 1 <-- What was solved? -Igor -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 1:38 PM To: CF-Talk Subject: Re: CFMX Form Submission Hacking. Form Page - set the session variable equal to 1 Processing Page - check to see if the session variable equals 1, and if so, process the form.. THEN set the session variable to 0 and carry on. That should work for you. Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 2:24 PM Subject: RE: CFMX Form Submission Hacking. > I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. > > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:51 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Why not just set some kind of variable on the form page itself, such as > session.isOnMyServer > and then on the processing page, check for the existence of that variable... > > Would that not work for you? > > Mike > > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 1:40 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I realize this... It will not completely prevent hacking... > > but I would like to make sure that if a person is on my form page, they > are not able to save the page, edit some of the hidden form variables, and > then submit the page to my server. I am aware that the referrer can be > simulated, but that is a deeper degree of the issue I am trying to solve. > > > > -Igor > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 11:41 AM > > To: CF-Talk > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > Does anyone have a quick snippet of code that does a regex > > > match against the referrer to check if a form was submitted > > > from an internal page (with attention to ports if possible). > > > Too lazy to write it myself, so hoping someone does this to > > > prevent hacking of form submissions. > > > > That wouldn't prevent "hacking of form submissions", as the referer is > > provided by the browser, not the server. Also, I'm not sure what you mean > by > > "attention to ports". > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > voice: (202) 797-5496 > > fax: (202) 797-5444 > > > > > > > > ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
personally, I have queries set on my form processing page that simply calculates price from my Database and NOT from users cart pricing. Only thing I personally pull from users shopping cart / session is the item codes they are ordering. In this scenario they can set the price as many times as they want.. but when the checkout I look at their items, re-grab the pricing and give them a final invoice. Perhaps that's more what you are after? In addition - can't you use some domain variables to check that the refererrer is coming from your domain online. If a user submits from his or her desktop it certainly won't match your domain. Or path info stuff... you know where your form is - you can verify the path maybe OR actually - it just came to me.. Basically the concern is if a page was modified. You can use the HTTP_IF_MODIFIED_SINCE referer to see if it was modified after a certain date. Sure anytime you make a change to that form you have a slight window someone can sneak by and you have to modify that "check" date but it would prevent what you are referring to. hth jay miller Igor Ilyinsky wrote: > Still not sure how what you're saying works. Let me give you a scenario. > > User clicks checkout on the e-commerce app. from his shopping cart. > --> request gets sent to form page; session.notahacker = 1 <-- > The page comes up with a request for his CC info in a form. > The same form has a hidden field with the total purchase amount ($35) > User Clicks Save, to save the html page to his desktop. > User Edits the HTML page to change the amount from $35 to $3 > User Opens the page in a browser from his local machine. > User clicks submit from this page to my web server > --> request gets sent to submit page; session.notahacker is still 1 <-- > > What was solved? > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 1:38 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Form Page - set the session variable equal to 1 > Processing Page - check to see if the session variable equals 1, and if so, > process the form.. THEN > set the session variable to 0 and carry on. That should work for you. > > Mike > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 2:24 PM > Subject: RE: CFMX Form Submission Hacking. > > > >>I'm not sure how that would work Mike... If I set the session variable, > > and the user comes back (within the session timeout timeframe) wouldn't the > session variable persist? It's not like the session is tied to the page > itself. > >>-Igor >> >>-Original Message- >>From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] >>Sent: Monday, June 23, 2003 12:51 PM >>To: CF-Talk >>Subject: Re: CFMX Form Submission Hacking. >> >> >>Why not just set some kind of variable on the form page itself, such as >>session.isOnMyServer >>and then on the processing page, check for the existence of that > > variable... > >>Would that not work for you? >> >>Mike >> >> >>- Original Message - >>From: "Igor Ilyinsky" <[EMAIL PROTECTED]> >>To: "CF-Talk" <[EMAIL PROTECTED]> >>Sent: Monday, June 23, 2003 1:40 PM >>Subject: RE: CFMX Form Submission Hacking. >> >> >> >>>I realize this... It will not completely prevent hacking... >>>but I would like to make sure that if a person is on my form page, they >> >>are not able to save the page, edit some of the hidden form variables, and >>then submit the page to my server. I am aware that the referrer can be >>simulated, but that is a deeper degree of the issue I am trying to solve. >> >>>-Igor >>> >>>-Original Message- >>>From: Dave Watts [mailto:[EMAIL PROTECTED] >>>Sent: Monday, June 23, 2003 11:41 AM >>>To: CF-Talk >>>Subject: RE: CFMX Form Submission Hacking. >>> >>> >>> >>>>Does anyone have a quick snippet of code that does a regex >>>>match against the referrer to check if a form was submitted >>>>from an internal page (with attention to ports if possible). >>>>Too lazy to write it myself, so hoping someone does this to >>>>prevent hacking of form submissions. >>> >>>That wouldn't prevent "hacking of form submissions", as the referer is >>>provided by the browser, not the server. Also, I'm not s
RE: CFMX Form Submission Hacking.
Wouldn't this be a good place to use request scope variables instead of session? Just asking, never done anything like this before. Steve -Original Message- From: Igor Ilyinsky [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 2:47 PM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. Still not sure how what you're saying works. Let me give you a scenario. User clicks checkout on the e-commerce app. from his shopping cart. --> request gets sent to form page; session.notahacker = 1 <-- The page comes up with a request for his CC info in a form. The same form has a hidden field with the total purchase amount ($35) User Clicks Save, to save the html page to his desktop. User Edits the HTML page to change the amount from $35 to $3 User Opens the page in a browser from his local machine. User clicks submit from this page to my web server --> request gets sent to submit page; session.notahacker is still 1 <-- What was solved? -Igor -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 1:38 PM To: CF-Talk Subject: Re: CFMX Form Submission Hacking. Form Page - set the session variable equal to 1 Processing Page - check to see if the session variable equals 1, and if so, process the form.. THEN set the session variable to 0 and carry on. That should work for you. Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 2:24 PM Subject: RE: CFMX Form Submission Hacking. > I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. > > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:51 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Why not just set some kind of variable on the form page itself, such as > session.isOnMyServer > and then on the processing page, check for the existence of that variable... > > Would that not work for you? > > Mike > > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 1:40 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I realize this... It will not completely prevent hacking... > > but I would like to make sure that if a person is on my form page, they > are not able to save the page, edit some of the hidden form variables, and > then submit the page to my server. I am aware that the referrer can be > simulated, but that is a deeper degree of the issue I am trying to solve. > > > > -Igor > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 11:41 AM > > To: CF-Talk > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > Does anyone have a quick snippet of code that does a regex > > > match against the referrer to check if a form was submitted > > > from an internal page (with attention to ports if possible). > > > Too lazy to write it myself, so hoping someone does this to > > > prevent hacking of form submissions. > > > > That wouldn't prevent "hacking of form submissions", as the referer is > > provided by the browser, not the server. Also, I'm not sure what you mean > by > > "attention to ports". > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > voice: (202) 797-5496 > > fax: (202) 797-5444 > > > > > > > > ~| 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: CFMX Form Submission Hacking.
Still not sure how what you're saying works. Let me give you a scenario. User clicks checkout on the e-commerce app. from his shopping cart. --> request gets sent to form page; session.notahacker = 1 <-- The page comes up with a request for his CC info in a form. The same form has a hidden field with the total purchase amount ($35) User Clicks Save, to save the html page to his desktop. User Edits the HTML page to change the amount from $35 to $3 User Opens the page in a browser from his local machine. User clicks submit from this page to my web server --> request gets sent to submit page; session.notahacker is still 1 <-- What was solved? -Igor -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 1:38 PM To: CF-Talk Subject: Re: CFMX Form Submission Hacking. Form Page - set the session variable equal to 1 Processing Page - check to see if the session variable equals 1, and if so, process the form.. THEN set the session variable to 0 and carry on. That should work for you. Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 2:24 PM Subject: RE: CFMX Form Submission Hacking. > I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. > > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:51 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Why not just set some kind of variable on the form page itself, such as > session.isOnMyServer > and then on the processing page, check for the existence of that variable... > > Would that not work for you? > > Mike > > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 1:40 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I realize this... It will not completely prevent hacking... > > but I would like to make sure that if a person is on my form page, they > are not able to save the page, edit some of the hidden form variables, and > then submit the page to my server. I am aware that the referrer can be > simulated, but that is a deeper degree of the issue I am trying to solve. > > > > -Igor > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 11:41 AM > > To: CF-Talk > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > Does anyone have a quick snippet of code that does a regex > > > match against the referrer to check if a form was submitted > > > from an internal page (with attention to ports if possible). > > > Too lazy to write it myself, so hoping someone does this to > > > prevent hacking of form submissions. > > > > That wouldn't prevent "hacking of form submissions", as the referer is > > provided by the browser, not the server. Also, I'm not sure what you mean > by > > "attention to ports". > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > voice: (202) 797-5496 > > fax: (202) 797-5444 > > > > > > > > ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
Form Page - set the session variable equal to 1 Processing Page - check to see if the session variable equals 1, and if so, process the form.. THEN set the session variable to 0 and carry on. That should work for you. Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 2:24 PM Subject: RE: CFMX Form Submission Hacking. > I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. > > -Igor > > -Original Message- > From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 12:51 PM > To: CF-Talk > Subject: Re: CFMX Form Submission Hacking. > > > Why not just set some kind of variable on the form page itself, such as > session.isOnMyServer > and then on the processing page, check for the existence of that variable... > > Would that not work for you? > > Mike > > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 1:40 PM > Subject: RE: CFMX Form Submission Hacking. > > > > I realize this... It will not completely prevent hacking... > > but I would like to make sure that if a person is on my form page, they > are not able to save the page, edit some of the hidden form variables, and > then submit the page to my server. I am aware that the referrer can be > simulated, but that is a deeper degree of the issue I am trying to solve. > > > > -Igor > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 23, 2003 11:41 AM > > To: CF-Talk > > Subject: RE: CFMX Form Submission Hacking. > > > > > > > Does anyone have a quick snippet of code that does a regex > > > match against the referrer to check if a form was submitted > > > from an internal page (with attention to ports if possible). > > > Too lazy to write it myself, so hoping someone does this to > > > prevent hacking of form submissions. > > > > That wouldn't prevent "hacking of form submissions", as the referer is > > provided by the browser, not the server. Also, I'm not sure what you mean > by > > "attention to ports". > > > > Dave Watts, CTO, Fig Leaf Software > > http://www.figleaf.com/ > > voice: (202) 797-5496 > > fax: (202) 797-5444 > > > > > > > > ~| 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
I'm not sure how that would work Mike... If I set the session variable, and the user comes back (within the session timeout timeframe) wouldn't the session variable persist? It's not like the session is tied to the page itself. -Igor -Original Message- From: Michael T. Tangorre [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 12:51 PM To: CF-Talk Subject: Re: CFMX Form Submission Hacking. Why not just set some kind of variable on the form page itself, such as session.isOnMyServer and then on the processing page, check for the existence of that variable... Would that not work for you? Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 1:40 PM Subject: RE: CFMX Form Submission Hacking. > I realize this... It will not completely prevent hacking... > but I would like to make sure that if a person is on my form page, they are not able to save the page, edit some of the hidden form variables, and then submit the page to my server. I am aware that the referrer can be simulated, but that is a deeper degree of the issue I am trying to solve. > > -Igor > > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 11:41 AM > To: CF-Talk > Subject: RE: CFMX Form Submission Hacking. > > > > Does anyone have a quick snippet of code that does a regex > > match against the referrer to check if a form was submitted > > from an internal page (with attention to ports if possible). > > Too lazy to write it myself, so hoping someone does this to > > prevent hacking of form submissions. > > That wouldn't prevent "hacking of form submissions", as the referer is > provided by the browser, not the server. Also, I'm not sure what you mean by > "attention to ports". > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > > > ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
Why not just set some kind of variable on the form page itself, such as session.isOnMyServer and then on the processing page, check for the existence of that variable... Would that not work for you? Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 1:40 PM Subject: RE: CFMX Form Submission Hacking. > I realize this... It will not completely prevent hacking... > but I would like to make sure that if a person is on my form page, they are not able to save the page, edit some of the hidden form variables, and then submit the page to my server. I am aware that the referrer can be simulated, but that is a deeper degree of the issue I am trying to solve. > > -Igor > > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Monday, June 23, 2003 11:41 AM > To: CF-Talk > Subject: RE: CFMX Form Submission Hacking. > > > > Does anyone have a quick snippet of code that does a regex > > match against the referrer to check if a form was submitted > > from an internal page (with attention to ports if possible). > > Too lazy to write it myself, so hoping someone does this to > > prevent hacking of form submissions. > > That wouldn't prevent "hacking of form submissions", as the referer is > provided by the browser, not the server. Also, I'm not sure what you mean by > "attention to ports". > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > > > ~| 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
I realize this... It will not completely prevent hacking... but I would like to make sure that if a person is on my form page, they are not able to save the page, edit some of the hidden form variables, and then submit the page to my server. I am aware that the referrer can be simulated, but that is a deeper degree of the issue I am trying to solve. -Igor -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 11:41 AM To: CF-Talk Subject: RE: CFMX Form Submission Hacking. > Does anyone have a quick snippet of code that does a regex > match against the referrer to check if a form was submitted > from an internal page (with attention to ports if possible). > Too lazy to write it myself, so hoping someone does this to > prevent hacking of form submissions. That wouldn't prevent "hacking of form submissions", as the referer is provided by the browser, not the server. Also, I'm not sure what you mean by "attention to ports". Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
I have had many problems with cgi referrer however.. depending on antivirus and firewalls - that is not a dependable variable to use. But you can probably take that same thought and embed or hide some variables on your forms and check for those. Depends on how secure you need it - and if it's stopping spiders and bots or humans. hth jay miller Michael T. Tangorre wrote: > I would check the cgi.http_referer variable > > For instance, form is on page http://somesite.com/myform.cfm > > On the form processing page, say something like: > > if cgi.http_referer EQ "http://somesite.com/myform.cfm"; > process > else > die > > hth, > > > Mike > > - Original Message - > From: "Igor Ilyinsky" <[EMAIL PROTECTED]> > To: "CF-Talk" <[EMAIL PROTECTED]> > Sent: Monday, June 23, 2003 12:24 PM > Subject: CFMX Form Submission Hacking. > > > >>Does anyone have a quick snippet of code that does a regex match against > > the referrer to check if a form was submitted from an internal page (with > attention to ports if possible). Too lazy to write it myself, so hoping > someone does this to prevent hacking of form submissions. > >>TIA >>-Igor >> > > ~| 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 Host with the leader in ColdFusion hosting. Voted #1 ColdFusion host by CF Developers. Offering shared and dedicated hosting options. www.cfxhosting.com/default.cfm?redirect=10481 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFMX Form Submission Hacking.
>I would check the cgi.http_referer variable >For instance, form is on page http://somesite.com/myform.cfm >On the form processing page, say something like: >if cgi.http_referer EQ "http://somesite.com/myform.cfm"; >process >else >die Be careful with dealing with cgi.http_referer some firewall products will change how the name/value pairs appear. - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 12:24 PM Subject: CFMX Form Submission Hacking. > Does anyone have a quick snippet of code that does a regex match against the referrer to check if a form was submitted from an internal page (with attention to ports if possible). Too lazy to write it myself, so hoping someone does this to prevent hacking of form submissions. > > TIA > -Igor > ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFMX Form Submission Hacking.
I would check the cgi.http_referer variable For instance, form is on page http://somesite.com/myform.cfm On the form processing page, say something like: if cgi.http_referer EQ "http://somesite.com/myform.cfm"; process else die hth, Mike - Original Message - From: "Igor Ilyinsky" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 12:24 PM Subject: CFMX Form Submission Hacking. > Does anyone have a quick snippet of code that does a regex match against the referrer to check if a form was submitted from an internal page (with attention to ports if possible). Too lazy to write it myself, so hoping someone does this to prevent hacking of form submissions. > > TIA > -Igor > ~| 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: CFMX Form Submission Hacking.
> Does anyone have a quick snippet of code that does a regex > match against the referrer to check if a form was submitted > from an internal page (with attention to ports if possible). > Too lazy to write it myself, so hoping someone does this to > prevent hacking of form submissions. That wouldn't prevent "hacking of form submissions", as the referer is provided by the browser, not the server. Also, I'm not sure what you mean by "attention to ports". Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
CFMX Form Submission Hacking.
Does anyone have a quick snippet of code that does a regex match against the referrer to check if a form was submitted from an internal page (with attention to ports if possible). Too lazy to write it myself, so hoping someone does this to prevent hacking of form submissions. TIA -Igor ~| 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 Get the mailserver that powers this list at http://www.coolfusion.com 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
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 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 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
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: the Hacking Game (was Problems with CF Mail)
This was one from CF-Community about a month and 1/2 ago... It's a website with "hacking challenges" to complete. Quite addictive once you get into it. I made it to level 6 and was stumped... www.try2hack.nl -- don't let it eat all your time as it will... Please don't perpetuate this thread as it's now quite off topic. Jeff Garza Lead Developer/Webmaster Spectrum Astro, Inc. 480.892.8200 [EMAIL PROTECTED] http://www.spectrumastro.com -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 4:44 PM To: CF-Talk Subject: RE: problems with CF mail > > How are things? I gave up on the hacking game. > > Ooopss... I really need to check the TO: address Yes, and now you'll have to tell us all about the hacking game. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Why Share? Dedicated Win 2000 Server · PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation · $99/Month · Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionc 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: Test Hacking a web site.
Yes but this was a simple contrived example at how a social engineering example would work. In reality it would be a little more complex but social engineering is a way of "hacking" that combines social interaction with technology to form a 'best of breed' sort of system infiltration. It is all about what you know. Try cracking someone's 4096 bit PHP key, or just put a little recorder on their system bypassing the encryption all together? (Recent FBI case) (Okay this is not strictly social engineering but its a good example of how it works) You can have the tightest most awesome firewall and the most secured systems in the world in the world. But if you can trick someone with privileged access the most strict security measures are completely useless. Jeremy Allen elliptIQ Inc. -Original Message- From: Angel Stewart [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 16, 2001 10:21 AM To: CF-Talk Subject: RE: Test Hacking a web site. 0_0 You are bad bad person. *makes copious notes* Oh..but what if the person at target company knows Phil? Whoever you're going to be talking to would likely be in Technical at Target Company to know to FTP files into specific directories on the webserver, and thus chances are that s/he and Phil had interacted before Ahhh HA! -Gel -Original Message- From: Dan Kemp [mailto:[EMAIL PROTECTED]] But you missed out one of the best one: social engineering, go to target companies CF web site and find out who build/designed it (most sites have this, if not phone). Then go to that companies web site, look at the case studies and note down the other people they've done work for. Phone call 1. to the developers to get the name of the person in charge of developing that project. "Hi I'm Jim from *made up company* We're looking for some database backend web work in ColdFusion, and errr... we've been looking at other web sites to kinda see what things we like and saw *target company name*, and *couple more companies* it kinda close to what we want, but I've a couple of questions, could I very quickly ask you, did you work on them, you did? (or "who did?" can I speak to them)"... ask couple of half intelligent questions. Phone call 2. to the target company. "Hi it's Phil here from *design company name*, we worked on your site. Dave (person who was in charge), tells me that we need to fix the image size problem with your site before it starts to become apparent. Trouble is I'm on holiday so I can't connect and upload the image checking file I need, I'm stuck in a hotel and can only get to my hotmail account. If I email you the file can you put it into the imgs folder for me? Yeah, if I email to you, can I phone back in about half an hour to check it's in the right place? Cheers." Send encrypted imageCheck.cfm to target person. Let's see the firewall stop that one! Dan. ~~ 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
