RE: Client Database question
Fusebox and SQL Procedures defnitely provides a good solutions to Security. Joe -Original Message- From: Bud [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 24, 2002 8:06 PM To: CF-Talk Subject: Client Database question I've been testing this on my development box and it seems to work. But before I do it "live", does anyone see a problem with restricting SQL operations to Stored Procedures (which obviously there aren't any) or INSERT to stop people from querying a client storage database? I've always tried to avoid writing things like cfset client.user = "me" and cfset client.password = "mypassword" on the remote chance that if someone knows the datasource name and does a SELECT * FROM CDATA, that they could look for things like user and password combinations and guess from the app name (which I often name with the domain name to avoid duplicate app names) what site it is. Don't know why, but I always just sort of figured that restricting SQL operations would restrict them for CF also. Funny how it takes 3 years for the light to go on sometimes. :) -- Bud Schneehagen - Tropical Web Creations _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ColdFusion Solutions / eCommerce Development [EMAIL PROTECTED] http://www.twcreations.com/ 954.721.3452 __ 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: Client Database question
> Fusebox and SQL Procedures defnitely provides a good > solutions to Security. How exactly does Fusebox affect security? I don't see why it would affect it in either a positive or negative way. 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: Client Database question
Single point of entry, lock down few places rather than many...I guess more the traits of incorporating a controller rather than FB itself... Stace -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:10 AM To: CF-Talk Subject: RE: Client Database question > Fusebox and SQL Procedures defnitely provides a good > solutions to Security. How exactly does Fusebox affect security? I don't see why it would affect it in either a positive or negative way. 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: Client Database question
If though FuseBox applications have a single point out entry, all the scripts are still sitting in web accessible directories that anybody can just hit directly if they want to. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] > -Original Message- > From: Stacy Young [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 9:16 PM > To: CF-Talk > Subject: RE: Client Database question > > Single point of entry, lock down few places rather than many...I guess > more > the traits of incorporating a controller rather than FB itself... > > Stace > > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 12:10 AM > To: CF-Talk > Subject: RE: Client Database question > > > Fusebox and SQL Procedures defnitely provides a good > > solutions to Security. > > How exactly does Fusebox affect security? I don't see why it would affect > it > in either a positive or negative way. > > 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: Client Database question
> Single point of entry, lock down few places rather than > many...I guess more the traits of incorporating a > controller rather than FB itself... Unless the controller is actually doing something to heighten security that wouldn't be done by individual scripts, or being used in such a way to increase security, I still don't see any difference. 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: Client Database question
On 7/25/02, Stacy Young penned: >Single point of entry, lock down few places rather than many...I guess more >the traits of incorporating a controller rather than FB itself... LOL This has certainly strayed off of my original question which has nothing do do with Stored procedures or Fusebox. I'll re-post the question, which is concerning client database access: Does anyone see a problem with restricting SQL operations to Stored Procedures (which obviously there aren't any) or INSERT to stop people from querying a client storage database? I've always tried to avoid writing things like cfset client.user = "me" and cfset client.password = "mypassword" on the remote chance that if someone knows the datasource name and does a SELECT * FROM CDATA, that they could look for things like user and password combinations and guess from the app name (which I often name with the domain name to avoid duplicate app names) what site it is. Don't know why, but I always just sort of figured that restricting SQL operations would restrict them for CF also. Funny how it takes 3 years for the light to go on sometimes. :) -- Bud Schneehagen - Tropical Web Creations _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ColdFusion Solutions / eCommerce Development [EMAIL PROTECTED] http://www.twcreations.com/ 954.721.3452 __ 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: Client Database question
If you *keep* them in a web accessible directory then yes, they're accessible. -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:17 AM To: CF-Talk Subject: RE: Client Database question If though FuseBox applications have a single point out entry, all the scripts are still sitting in web accessible directories that anybody can just hit directly if they want to. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] > -Original Message- > From: Stacy Young [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 9:16 PM > To: CF-Talk > Subject: RE: Client Database question > > Single point of entry, lock down few places rather than many...I guess > more > the traits of incorporating a controller rather than FB itself... > > Stace > > -Original Message- > From: Dave Watts [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 12:10 AM > To: CF-Talk > Subject: RE: Client Database question > > > Fusebox and SQL Procedures defnitely provides a good > > solutions to Security. > > How exactly does Fusebox affect security? I don't see why it would affect > it > in either a positive or negative way. > > 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: Client Database question
Which is what every FuseBox application I have ever seen does. I'm sure there are exceptions, but I am also sure the vast majority have never thought about it. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] > -Original Message- > From: Stacy Young [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 9:26 PM > To: CF-Talk > Subject: RE: Client Database question > > If you *keep* them in a web accessible directory then yes, they're > accessible. > > > -Original Message- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 12:17 AM > To: CF-Talk > Subject: RE: Client Database question > > If though FuseBox applications have a single point out entry, all the > scripts are still sitting in web accessible directories that anybody can > just hit directly if they want to. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.montarasoftware.com/ > V: 415-577-8070 > F: 415-341-8906 > P: [EMAIL PROTECTED] > > > -Original Message- > > From: Stacy Young [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, July 24, 2002 9:16 PM > > To: CF-Talk > > Subject: RE: Client Database question > > > > Single point of entry, lock down few places rather than many...I guess > > more > > the traits of incorporating a controller rather than FB itself... > > > > Stace > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 25, 2002 12:10 AM > > To: CF-Talk > > Subject: RE: Client Database question > > > > > Fusebox and SQL Procedures defnitely provides a good > > > solutions to Security. > > > > How exactly does Fusebox affect security? I don't see why it would > affect > > it > > in either a positive or negative way. > > > > 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: Client Database question
Bud wrote: > LOL > > This has certainly strayed off of my original question which has > nothing do do with Stored procedures or Fusebox. I'll re-post the > question, which is concerning client database access: Nice Try. __ 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: Client Database question
Ladies and gentlemen there you have it! ;-) I'm out...too tired, Cheers Stace -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:29 AM To: CF-Talk Subject: RE: Client Database question Which is what every FuseBox application I have ever seen does. I'm sure there are exceptions, but I am also sure the vast majority have never thought about it. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] > -Original Message- > From: Stacy Young [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 9:26 PM > To: CF-Talk > Subject: RE: Client Database question > > If you *keep* them in a web accessible directory then yes, they're > accessible. > > > -Original Message- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 12:17 AM > To: CF-Talk > Subject: RE: Client Database question > > If though FuseBox applications have a single point out entry, all the > scripts are still sitting in web accessible directories that anybody can > just hit directly if they want to. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.montarasoftware.com/ > V: 415-577-8070 > F: 415-341-8906 > P: [EMAIL PROTECTED] > > > -Original Message- > > From: Stacy Young [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, July 24, 2002 9:16 PM > > To: CF-Talk > > Subject: RE: Client Database question > > > > Single point of entry, lock down few places rather than many...I guess > > more > > the traits of incorporating a controller rather than FB itself... > > > > Stace > > > > -Original Message- > > From: Dave Watts [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, July 25, 2002 12:10 AM > > To: CF-Talk > > Subject: RE: Client Database question > > > > > Fusebox and SQL Procedures defnitely provides a good > > > solutions to Security. > > > > How exactly does Fusebox affect security? I don't see why it would > affect > > it > > in either a positive or negative way. > > > > 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: Client Database question
Sorry Bud but I'm lost dude...restrict INSERT at the CFADMIN level on the client datasource? Stace -Original Message- From: Bud [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:24 AM To: CF-Talk Subject: RE: Client Database question On 7/25/02, Stacy Young penned: >Single point of entry, lock down few places rather than many...I guess more >the traits of incorporating a controller rather than FB itself... LOL This has certainly strayed off of my original question which has nothing do do with Stored procedures or Fusebox. I'll re-post the question, which is concerning client database access: Does anyone see a problem with restricting SQL operations to Stored Procedures (which obviously there aren't any) or INSERT to stop people from querying a client storage database? I've always tried to avoid writing things like cfset client.user = "me" and cfset client.password = "mypassword" on the remote chance that if someone knows the datasource name and does a SELECT * FROM CDATA, that they could look for things like user and password combinations and guess from the app name (which I often name with the domain name to avoid duplicate app names) what site it is. Don't know why, but I always just sort of figured that restricting SQL operations would restrict them for CF also. Funny how it takes 3 years for the light to go on sometimes. :) -- Bud Schneehagen - Tropical Web Creations _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ColdFusion Solutions / eCommerce Development [EMAIL PROTECTED] http://www.twcreations.com/ 954.721.3452 __ 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: Client Database question
> If you *keep* them in a web accessible directory then yes, > they're accessible. Even if you place them in an inaccessible directory (a good practice for any file not meant to be invoked directly via the URL, such as Application.cfm, OnRequestEnd.cfm, custom tags, includes, etc), they will still be invoked through the controller. Therefore, again, if the controller doesn't actually impose any additional limitations, there's no additional security from the perspective of someone trying to run the code that you have on your server (perhaps with inappropriate input values). The only security gained by placing the includes and so forth in an inaccessible directory, really, is protection against source code browsing exploits - and a simple application of permissions can be used to prevent this anyway. And to reinforce Matt's observation, I've never seen a Fusebox application that has placed includes in an inaccessible directory - and I've seen quite a few Fusebox applications. In any case, Fusebox doesn't mandate file locations for security reasons - there's nothing being done there that you couldn't do another way - so again, my original question about how Fusebox increases or decreases security stands. 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: Client Database question
I am not a "Fusebox Guru" but from what i have learned from Fusebox.. I have been able to control the visibility of CF templates from User Hacking. eg.. if i just had index.cfm as single entry to the application... security can be easily implemented to force app usage... The way you do this.. Figure it out...haha "Arent you the instructor at fig leaf?" Joe Certified Advanced ColdFusion Developer [EMAIL PROTECTED] -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 12:26 AM To: CF-Talk Subject: RE: Client Database question > Single point of entry, lock down few places rather than > many...I guess more the traits of incorporating a > controller rather than FB itself... Unless the controller is actually doing something to heighten security that wouldn't be done by individual scripts, or being used in such a way to increase security, I still don't see any difference. 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: Client Database question
> The only security gained by placing the includes and so forth in an > inaccessible directory, really, is protection against source > code browsing exploits - and a simple application of permissions > can be used to prevent this anyway. Well, I don't agree totally I include all of my fuses from a directory that is not accessible to the web server. For example, if my web root is c:\inetpub\wwwroot, I'll keep my fuses in c:\inetpub\fuses. Then my c:\inetpub\wwwroot only has the index.cfm, an empty application.cfm and an empty onrequestend.cfm. This forces all access to the fuses to go through the index.cfm fusebox. I separate the fuses mainly to prevent users from guessing fuse locations and invoking them directly, which I think provides a measure of added security. In a non-Fusebox app, users can attempt to execute arbitrary templates by just calling them directly. Using my fusebox method, I can at least force them to go through the index.cfm where I have a single location to enforce restrictions and perform validation. This is minor, I guess, but modularity and ease of coding should also decrease the likelihood that you will miss a security flaw in your code... For what it's worth, Chris Lofback Sr. Web Developer TRX Integration 28051 US 19 N., Ste. C Clearwater, FL 33761 www.trxi.com __ 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: Client Database question
I was trying to point out that I find it easier to secure my applications when incorporating a framework like FB. All my operations are available at a glance...workflow easy to follow...and unit testing secured portions easier. It's really just an opinion...I'm not trying to campaign one way of doing things over another... Cheers -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 1:02 AM To: CF-Talk Subject: RE: Client Database question > If you *keep* them in a web accessible directory then yes, > they're accessible. Even if you place them in an inaccessible directory (a good practice for any file not meant to be invoked directly via the URL, such as Application.cfm, OnRequestEnd.cfm, custom tags, includes, etc), they will still be invoked through the controller. Therefore, again, if the controller doesn't actually impose any additional limitations, there's no additional security from the perspective of someone trying to run the code that you have on your server (perhaps with inappropriate input values). The only security gained by placing the includes and so forth in an inaccessible directory, really, is protection against source code browsing exploits - and a simple application of permissions can be used to prevent this anyway. And to reinforce Matt's observation, I've never seen a Fusebox application that has placed includes in an inaccessible directory - and I've seen quite a few Fusebox applications. In any case, Fusebox doesn't mandate file locations for security reasons - there's nothing being done there that you couldn't do another way - so again, my original question about how Fusebox increases or decreases security stands. 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: Client Database question
On 7/25/02, Stacy Young penned: >Sorry Bud but I'm lost dude...restrict INSERT at the CFADMIN level on the >client datasource? Hi Stacy. Hey! A response to the actual thread. :) Yes. If you know the datasource name of a client storage database, it can be queried and updated just like any other datasource. If you restrict SQL operations to INSERT or Stored Procedures, you won't be able to do this. The only reason I would select one of those restrictions is there isn't an option to deny "ALL" SQL operations. The scenario I'm worried about is this: 1: I build an application that uses a login. 2: I set client.user = "someuser" and client.password = "mypassword" and set the application name to "mydomain_userinfo". 3: Someone knows the datasource name. They query the datasource: SELECT app,data FROM CDATA 4: They output the query looking for possible username, password combinations. If I use the sample above and use "user" and "password" as the client variable names, this would be easy. 5: They now know the password for "someuser" is "mypassword". They look at the app field and easily guess from the name that the site is "mydomain.com". 6: They go to www.mydomain.com and login is as "someuser". Basically, this is why I've never set usernames and passwords as client variables. However, not allowing SELECTs would stop anyone from stealing them in this manner. I just always figured that restricting SQL operations would also restrict CF from SELECTing, and UPDATEing. But some testing shows it doesn't affect CF in writing or accessing client variables. My main question was, is there anything that I should be aware of that may be a problem if I did this. -- Bud Schneehagen - Tropical Web Creations _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ColdFusion Solutions / eCommerce Development [EMAIL PROTECTED] http://www.twcreations.com/ 954.721.3452 __ 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: Client Database question
Ah ok now I get it! ;-) As for whether you'd have any problems, not sure give it a whirl! Another suggestion might be to use a dedicated userid/pass for that datasource. Also I wouldn't necessarily keep users passwords in these tables...For most occasions I've found that the userid only would suffice...after a person is logged in just check for the presence of the userid in the client scope. The easiest fix at the moment though would probably be a dedicated user/pass. Hope that helps! -Original Message- From: Bud [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 9:51 AM To: CF-Talk Subject: RE: Client Database question On 7/25/02, Stacy Young penned: >Sorry Bud but I'm lost dude...restrict INSERT at the CFADMIN level on the >client datasource? Hi Stacy. Hey! A response to the actual thread. :) Yes. If you know the datasource name of a client storage database, it can be queried and updated just like any other datasource. If you restrict SQL operations to INSERT or Stored Procedures, you won't be able to do this. The only reason I would select one of those restrictions is there isn't an option to deny "ALL" SQL operations. The scenario I'm worried about is this: 1: I build an application that uses a login. 2: I set client.user = "someuser" and client.password = "mypassword" and set the application name to "mydomain_userinfo". 3: Someone knows the datasource name. They query the datasource: SELECT app,data FROM CDATA 4: They output the query looking for possible username, password combinations. If I use the sample above and use "user" and "password" as the client variable names, this would be easy. 5: They now know the password for "someuser" is "mypassword". They look at the app field and easily guess from the name that the site is "mydomain.com". 6: They go to www.mydomain.com and login is as "someuser". Basically, this is why I've never set usernames and passwords as client variables. However, not allowing SELECTs would stop anyone from stealing them in this manner. I just always figured that restricting SQL operations would also restrict CF from SELECTing, and UPDATEing. But some testing shows it doesn't affect CF in writing or accessing client variables. My main question was, is there anything that I should be aware of that may be a problem if I did this. -- Bud Schneehagen - Tropical Web Creations _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ColdFusion Solutions / eCommerce Development [EMAIL PROTECTED] http://www.twcreations.com/ 954.721.3452 __ 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: Client Database question
> Basically, this is why I've never set usernames and passwords as > client variables. However, not allowing SELECTs would stop anyone > from stealing them in this manner. I just always figured that > restricting SQL operations would also restrict CF from SELECTing, and > UPDATEing. But some testing shows it doesn't affect CF in writing or > accessing client variables. I wold still avoid setting either username or password as client variables personally... and tend to hash() passwords as they're going into the db also. For that matter, if I wanted to be particularly strict about security, I would hash the usernames also, :) since I never display the usernames. ( i.e. like AOL/AIM's login with your screenname that's readily available to everyone. ) Isaac Dealey www.turnkey.to 954-776-0046 __ 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: Client Database question
One way hash on passwords definitely the way to go... -Original Message- From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 10:05 AM To: CF-Talk Subject: RE: Client Database question > Basically, this is why I've never set usernames and passwords as > client variables. However, not allowing SELECTs would stop anyone > from stealing them in this manner. I just always figured that > restricting SQL operations would also restrict CF from SELECTing, and > UPDATEing. But some testing shows it doesn't affect CF in writing or > accessing client variables. I wold still avoid setting either username or password as client variables personally... and tend to hash() passwords as they're going into the db also. For that matter, if I wanted to be particularly strict about security, I would hash the usernames also, :) since I never display the usernames. ( i.e. like AOL/AIM's login with your screenname that's readily available to everyone. ) Isaac Dealey www.turnkey.to 954-776-0046 __ 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: Client Database question
On 7/25/02, Stacy Young penned:
>Ah ok now I get it! ;-)
>
>As for whether you'd have any problems, not sure give it a whirl! Another
>suggestion might be to use a dedicated userid/pass for that datasource. Also
>I wouldn't necessarily keep users passwords in these tables...For most
>occasions I've found that the userid only would suffice...after a person is
>logged in just check for the presence of the userid in the client scope.
I just manually created a client.user variable and logged myself in
to a test application by going to the application and checking the
cfid and cftoken cookies that were set. I had to use INSERT, but it
worked easily. So, allowing only Stored Procedures (of which there
aren't any) should prevent this.
INSERT INTO CGLOBAL
(cfid,data,lvisit)
VALUES
('988:7118230','#data#',#CreateODBCDateTime(now())#)
INSERT INTO CDATA
(cfid,app,data)
VALUES
('988:7118230','oogagy','USER=budman##')
>
>The easiest fix at the moment though would probably be a dedicated
>user/pass.
How would you do that with a client storage datasource? I'd also have
to create a dedicated client database for each site. I just use a
single database as the default storage.
--
Bud Schneehagen - Tropical Web Creations
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
ColdFusion Solutions / eCommerce Development
[EMAIL PROTECTED]
http://www.twcreations.com/
954.721.3452
__
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: Client Database question
I agree totally... i think Application Flow / Roles / Access levels should be driven by UNIQUE (USERID NUMBER) rather than USERNAME/LOGON ID/ PASSWORDS etc Joe - Original Message - From: "S. Isaac Dealey" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, July 25, 2002 10:05 AM Subject: RE: Client Database question > > Basically, this is why I've never set usernames and passwords as > > client variables. However, not allowing SELECTs would stop anyone > > from stealing them in this manner. I just always figured that > > restricting SQL operations would also restrict CF from SELECTing, and > > UPDATEing. But some testing shows it doesn't affect CF in writing or > > accessing client variables. > > I wold still avoid setting either username or password as client variables > personally... and tend to hash() passwords as they're going into the db > also. For that matter, if I wanted to be particularly strict about security, > I would hash the usernames also, :) since I never display the usernames. ( > i.e. like AOL/AIM's login with your screenname that's readily available to > everyone. ) > > > Isaac Dealey > > www.turnkey.to > 954-776-0046 > __ 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
