Re: CFMAIL Attachments
Ben Densmore said: I'm trying to use the cfmailparam tag in cfmail to send a file attachment. When the file comes through it shows up with a .tmp extension instead of a .doc extension if it's a word doc. I even tried specifing the type as application/msword and it still comes through as a .tmp file. Do I need to upload the file to my server first for the real file type to come through? Yes. Jochem [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Redirect cferror
Hi all, We're in the process of combining our dept focussed intranet (iet-only) and institution focussed intranet (iet-ou) into a single intranet (iet-intranet) and I'm trying to figure out the best way to redirect users who go to iet-only or iet-ou to the new site (as most of the pages will be in exactly the same structure). So far I've got a custom 404 message for the iet-only and iet-ou sites (which point to adirectory that contains only the redirect page and Application.cfm) and redirects to the new iet-intranet. This seems to work fine for everything except .cfm files which give the CF-type template not found error. I've tried using a cferror tag on the Application.cfm to trap this, but it still seems to fail. We need the redirect to work for any type of file, .doc, .pdf, .pps etc - not just cfm files. How can I trap a missing template (rather that missing include) using cferror? I don't want to use the CF-admin sitewide handler because there are other sites on the instance of CF which we do not want to use the same missing template file. Or any other suggestions/advice on how to achieve this would be appreciated. I;ve also tried to look for a cgi script to intercept the requests and change the domain name as they arrive at the web server - but I;ve not found a suitable script (yet!). Ta, Alex (btw we're using IIS5 W2K) [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
CFPOP error checking
I've found that from time to time the delete function of CFPOP (in CF5) fails and won't delete an email on my server (this could well be a problem on my email server.)How do I do error checking on CFPOP to make sure it has deleted the message?Can I use a CFTRY/CFCATCH system? The other option would be to only get the unread messages.Is there a way to have CFPOP only get unread messages? Thanks for any help, T [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Redirect cferror
you could have a look at ISAPI_REWrite, http://www.isapirewrite.com/ HTH -Original Message- From: A.Little [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 To: CF-Talk Subject: Redirect cferror Hi all, We're in the process of combining our dept focussed intranet (iet-only) and institution focussed intranet (iet-ou) into a single intranet (iet-intranet) and I'm trying to figure out the best way to redirect users who go to iet-only or iet-ou to the new site (as most of the pages will be in exactly the same structure). So far I've got a custom 404 message for the iet-only and iet-ou sites (which point to adirectory that contains only the redirect page and Application.cfm) and redirects to the new iet-intranet. This seems to work fine for everything except .cfm files which give the CF-type template not found error. I've tried using a cferror tag on the Application.cfm to trap this, but it still seems to fail. We need the redirect to work for any type of file, .doc, .pdf, .pps etc - not just cfm files. How can I trap a missing template (rather that missing include) using cferror? I don't want to use the CF-admin sitewide handler because there are other sites on the instance of CF which we do not want to use the same missing template file. Or any other suggestions/advice on how to achieve this would be appreciated. I;ve also tried to look for a cgi script to intercept the requests and change the domain name as they arrive at the web server - but I;ve not found a suitable script (yet!). Ta, Alex (btw we're using IIS5 W2K) _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Redirect cferror
Alex, I'm no webserver expert, but can't you just remove the .cfm and .dbm filters from the application settings of the old site in IIS. I think cf will no longer treat the request then and you will be redirected in the same way as for the other files Pascal -Original Message- From: A.Little [mailto:[EMAIL PROTECTED] Sent: dinsdag 23 maart 2004 12:39 To: CF-Talk Subject: Redirect cferror Hi all, We're in the process of combining our dept focussed intranet (iet-only) and institution focussed intranet (iet-ou) into a single intranet (iet-intranet) and I'm trying to figure out the best way to redirect users who go to iet-only or iet-ou to the new site (as most of the pages will be in exactly the same structure). So far I've got a custom 404 message for the iet-only and iet-ou sites (which point to adirectory that contains only the redirect page and Application.cfm) and redirects to the new iet-intranet. This seems to work fine for everything except .cfm files which give the CF-type template not found error. I've tried using a cferror tag on the Application.cfm to trap this, but it still seems to fail. We need the redirect to work for any type of file, .doc, .pdf, .pps etc - not just cfm files. How can I trap a missing template (rather that missing include) using cferror? I don't want to use the CF-admin sitewide handler because there are other sites on the instance of CF which we do not want to use the same missing template file. Or any other suggestions/advice on how to achieve this would be appreciated. I;ve also tried to look for a cgi script to intercept the requests and change the domain name as they arrive at the web server - but I;ve not found a suitable script (yet!). Ta, Alex (btw we're using IIS5 W2K) [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Redirect cferror
Thanks Pascal - I did look at doing this but the custom 404 page I've got is a cfm template so if I removed the .cfm filters then the redirect wouldn't work... Alex -Original Message- From: Pascal Peters [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 11:55 To: CF-Talk Subject: RE: Redirect cferror Alex, I'm no webserver expert, but can't you just remove the .cfm and .dbm filters from the application settings of the old site in IIS. I think cf will no longer treat the request then and you will be redirected in the same way as for the other files Pascal -Original Message- From: A.Little [mailto:[EMAIL PROTECTED] Sent: dinsdag 23 maart 2004 12:39 To: CF-Talk Subject: Redirect cferror Hi all, We're in the process of combining our dept focussed intranet (iet-only) and institution focussed intranet (iet-ou) into a single intranet (iet-intranet) and I'm trying to figure out the best way to redirect users who go to iet-only or iet-ou to the new site (as most of the pages will be in exactly the same structure). So far I've got a custom 404 message for the iet-only and iet-ou sites (which point to adirectory that contains only the redirect page and Application.cfm) and redirects to the new iet-intranet. This seems to work fine for everything except .cfm files which give the CF-type template not found error. I've tried using a cferror tag on the Application.cfm to trap this, but it still seems to fail. We need the redirect to work for any type of file, .doc, .pdf, .pps etc - not just cfm files. How can I trap a missing template (rather that missing include) using cferror? I don't want to use the CF-admin sitewide handler because there are other sites on the instance of CF which we do not want to use the same missing template file. Or any other suggestions/advice on how to achieve this would be appreciated. I;ve also tried to look for a cgi script to intercept the requests and change the domain name as they arrive at the web server - but I;ve not found a suitable script (yet!). Ta, Alex (btw we're using IIS5 W2K) [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Redirect cferror
in iis make sure the for .cfm extensions it checks for the existance of the file, that way it will then trigger the custom 404 HTH -Original Message- From: A.Little [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:04 To: CF-Talk Subject: RE: Redirect cferror Thanks Pascal - I did look at doing this but the custom 404 page I've got is a cfm template so if I removed the .cfm filters then the redirect wouldn't work... Alex -Original Message- From: Pascal Peters [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 11:55 To: CF-Talk Subject: RE: Redirect cferror Alex, I'm no webserver expert, but can't you just remove the .cfm and .dbm filters from the application settings of the old site in IIS. I think cf will no longer treat the request then and you will be redirected in the same way as for the other files Pascal -Original Message- From: A.Little [mailto:[EMAIL PROTECTED] Sent: dinsdag 23 maart 2004 12:39 To: CF-Talk Subject: Redirect cferror Hi all, We're in the process of combining our dept focussed intranet (iet-only) and institution focussed intranet (iet-ou) into a single intranet (iet-intranet) and I'm trying to figure out the best way to redirect users who go to iet-only or iet-ou to the new site (as most of the pages will be in exactly the same structure). So far I've got a custom 404 message for the iet-only and iet-ou sites (which point to adirectory that contains only the redirect page and Application.cfm) and redirects to the new iet-intranet. This seems to work fine for everything except .cfm files which give the CF-type template not found error. I've tried using a cferror tag on the Application.cfm to trap this, but it still seems to fail. We need the redirect to work for any type of file, .doc, .pdf, .pps etc - not just cfm files. How can I trap a missing template (rather that missing include) using cferror? I don't want to use the CF-admin sitewide handler because there are other sites on the instance of CF which we do not want to use the same missing template file. Or any other suggestions/advice on how to achieve this would be appreciated. I;ve also tried to look for a cgi script to intercept the requests and change the domain name as they arrive at the web server - but I;ve not found a suitable script (yet!). Ta, Alex (btw we're using IIS5 W2K) _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
SOLVED: Redirect cferror
Cheers Mike - that's what I needed ;-) Alex -Original Message- From: Mike Townend [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 12:08 To: CF-Talk Subject: RE: Redirect cferror in iis make sure the for .cfm extensions it checks for the existance of the file, that way it will then trigger the custom 404 HTH [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: CFPOP error checking
There is no facility within the POP protocol to determine the unread messages in a mailbox. You have to physically keep a list of the message-ids or better still if your server supports them the UIDs that are stored against the mail and compare them against the message-ID or UIDs in the headers of the mails on the server. Any that you dont recognise are unread. As for your error with CFPOP not deleting mail yes you should be able to use a cftry..cfcatch arrangement however, make sure you are attempting to delete by UID as once you disconnect from your mail server the message IDs will be re-sorted after any mails that have been successfully marked for deletion are deleted. If you were to attempt to delete mails using the same list again in the try catch block and you were deleteing by messagenumber you would inevitably end up with errors deleting incorrect mails and possibly also attemtipng to delete mails that no longer exist at the back of the queue essentially going out of bounds. Paul [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Is this possible in HTML?
Can i have an equivalent of cfinclude in a HTML file? Thanks, Milan [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Securing CF Apps.
What kind of defenses are people putting in to prevent cookie poisoning, session hijacking, parameter tampering, etc...? Does everyone keep this stuff in mind while coding? To be honest, my past code has been lax when it comes to making sure all the holes are plugged, and even now, some automated testing tools we have are finding vulnerabilities! The checks I have been putting in place and the encrypting of parameters and such are definitely adding time to development, but at the same time, the quality of the application is much much better what does everyone else do to prevent malicious users? Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Is this possible in HTML?
Do a google search on 'Server Side Includes'.You should get a wealth of information on it. Ray http://www.crystalvision.org At 08:25 AM 3/23/2004, MILAN MUSHRAN wrote: Can i have an equivalent of cfinclude in a HTML file? Thanks, Milan [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Is this possible in HTML?
Do a google search on 'Server Side Includes'.You should get a wealth of information on it. Or from a client-side perspective, there are many possibilities with object, script (in conjunction with document.write) and iframe. Nick [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Is this possible in HTML?
If it's straight HTML and you have no ability to employ Server Side Includes, you can use a linked _javascript_ file.I wrote a little utility that makes it easy to turn straight HTML into JS:
cfparam name=a default=
cfswitch _expression_=#a#
cfcase value=process
cfsavecontent variable=converted_js
cfloop index=i list=#convert_string# delimiters=#chr(13)##chr(10)#cfif len(trim(i)) GT 0document.write('#jsstringformat(trim(i))#');
/cfif/cfloop
/cfsavecontent
xmp
#converted_js#
/xmp
cfheader name=content-disposition value=filename=converted.js
cfcontent type=text/_javascript_#converted_js#cfabort
/cfcase
cfdefaultcase
h4Enter the HTML that you want converted to _javascript_./h4
form action="" method=post
input type=hidden name=a value=process
textarea rows=25 cols=100 name=convert_string style=width: 100%; height: 75%/textarea
div align=centerinput type=submit value=Convert nbsp; input type=reset value= Reset /div
/form
/cfdefaultcase
/cfswitch
Pete
- Original Message -
From: MILAN MUSHRAN
To: CF-Talk
Sent: Tuesday, March 23, 2004 8:25 AM
Subject: Is this possible in HTML?
Can i have an equivalent of cfinclude in a HTML file?
Thanks,
Milan
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
Re: Securing CF Apps.
I think the most important thing to do is lock down the server before before worrying about code. Thats usually where most attacks will focus. A few simple things you can do: Break out the CFIDE from your server's webroot and create another site for it. Then lock down that site with permissions from the web server to the file system. Don't store username and password in the CFIDE. Pass it through with your code on each call. You can even go as far as integrate your database server's users/roles directly into your application. Crap I gotta go to a meeting. There is alot more you can do, hope this spawns some more ideas. -Adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 01:28 PM To: 'CF-Talk' Subject: Securing CF Apps. What kind of defenses are people putting in to prevent cookie poisoning, session hijacking, parameter tampering, etc...? Does everyone keep this stuff in mind while coding? To be honest, my past code has been lax when it comes to making sure all the holes are plugged, and even now, some automated testing tools we have are finding vulnerabilities! The checks I have been putting in place and the encrypting of parameters and such are definitely adding time to development, but at the same time, the quality of the application is much much better what does everyone else do to prevent malicious users? Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I think the most important thing to do is lock down the server before worrying about code. That's usually where most attacks will focus. A few simple things you can do: I would agree that it is important, however protecting the code and its ability to be manipulated is just as important. After a coworker showed me a popular bank website that passed a lot of information in the URL, I got playing around with it while logged in and was able to change the look and feel, get the app to error out and expose information to me such as table names and column names via the SQL error page, etc... This is not some lesser known bank, this is a popular bank which shocked me. Break out the CFIDE from your server's web root and create another site for it. Then lock down that site with permissions from the web server to the file system. That's a given for us here. Don't store username and password in the CFIDE. Pass it through with your code on each call. You can even go as far as integrate your database server's users/roles directly into your application. What do you mean here? I am really interested in people's approach assuming the servers are already locked down properly (wouldn't that be nice!). The fact remains that we all pass parameters in the URL, forms, cookies, session vars, etc and this is what I was really trying to focus on. Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Methodology and Docs
Paul, check this out if you have some time: http://www.fusebox.org/index.cfm?fuseaction=methodology.steps Steve Nelson -Original Message- From: Paul Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:11 AM To: CF-Talk Subject: Methodology and Docs I'm starting to build a CF web application with a team of developers and we're wondering what methodology to use. I've read that an Iterative method is more suitable than the Waterfall methodology for CFMX apps. Is this the case? What are people using these days? Also, what sort of documentation should I be producing and can anyone point me to some examples? Thanks! [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Methodology and Docs
Paul, Before I go into the types of documents I use with my team, Let me go over each of the development paradigms (as well as some of their strengths and weaknesses. Waterfall: In this paradigm, one creates *all* of the requirements needed for a project, provides the requirements to a programer, and the product ius developed and tested based upon the requirements. Pros: Designed by DOD for use with contractors. This approach freezes the requirements allowing the developers to program according to a specification. Cons: Inflexable to changes. Some studies have even suggested (NASA and NSF for example) that this paradigm leads to poor software since the users are not involved for most of the project. Additionaly clients do not know what they want until they see a mock up of the presentation. This approach requires a very short programming cycle. General Thumb: As a contractor this paradigm is easy to manage since the requirements are set up front. Iterative: This paradigm breaks up a project into more managemeable chunks. Requirements are checked to see if they match the current process model after each phase for quality control. Pros: For bigger projects and an educated consumer, this development paradigm forces the end user to be engaged early and often. By bitting off smaller chunks, the project becomes successful since the milestones are easier to reach. Cons: Requires a client that can communicate with the user group. Does not lend itself well to a contracting out approach unless the contractor guides all development. Also, like the waterfall paradigm, this approach does not build in useability from the onset. Adddtionally, this approach has a longer timeframe to complete the project, and requires strong project managers on both the IT and the program office. Evolutionary Prototype: In this paradigm requirements and design are moulded into one. By collaberating with the client using wireframes and HTML mockups, the client can fully help in the building of the application -- and figure out the necessary steps. This approach lends itself well in conjunction with the iterative paradigm. FLiP, discussed in other post is a classic example of this paradigm. Pros: Lend itself well to rapid application and web development.Forces useability as well as client buyin from the begining. In my experaance, the best approach since I can communicate the items a client must accomplish in the project timeframe. Cons: Clients sometimes like to hand a document and tell the contractor to figure out the problem. Requires a very strong disipline, project management, and methodology to implement. IT representives must be kind, caring and firm at the same time, since the program office can sometimes drag the requirements phase when figuring out their prototype. Requires disipline durring testing and deployment. There is another paradigm, Sprial used when creating commercial software wherte the requirements are gathered durring the development process. Now to the documents: Depending on how deep you want to go with this items it could be a few or many. If you're using CMM that number could easily be 100 once the policy documents are counted! Here's the minimum you'll need. *Preproject* Proposal/Statement of Work Project Planning/ Timeline Resources chart Status Report *Project* Requirements/ Software Development Blueprint/ Prototype specification Object Model/ Data Model Functional Testing plan Load Testing Technical Documentation Training Plan/Demo *Post Project* Accounting Report You can get away with less (and other on the list will say that you don't need all of the documentation), however, these templates will guide your team through the process of creating good software. As your team becomes bigger and more specilized, this will help your team focus one the task at hand. Jeremy Brodie Edgewater Technology web: http://www.edgewater.com phone:(703) 815-2500 email: [EMAIL PROTECTED] I'm starting to build a CF web application with a team of developers and we're wondering what methodology to use. I've read that an Iterative method is more suitable than the Waterfall methodology for CFMX apps. Is this the case? What are people using these days? Also, what sort of documentation should I be producing and can anyone point me to some examples? Thanks! [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Linkpoint API Host not responding problem.
Here is an example from the documentation.I'm not sure exactly where you would put this in our code, quite possibly you would put it in multiple locations of your code. blockquote * You can nest cftry blocks. For example, the following structure is valid: cftry code that may cause an exception cfcatch ... cftry First level of exeption handling code cfcatch ... Second level of exception handling code /cfcatch /cftry /cfcatch /cftry If an exception occurs in the first level of exception-handling code, the inner cfcatch block can catch and handle it. (An exception in a cfcatch block cannot be handled by cfcatch blocks at the same level as that block.) /blockquote This shows the concept of putting nested try-catch blocks inside the the catch block of other try-catch blocks. (That is not an awkward sentence!)Anyway, you can use something like this to try a piece of code as many times as you like, then still have an out of none of the trays work. What I would probably do is put the code I'm trying in some kind of included source (cfinclude, custom tag, UDF or CFC) then I could call the code in multiple locations of the nested try-catch blocks without having to re-code it every time. HTH -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA C code. C code run. Run code run. Please! - Cynthia Dunning [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Well, one thing you can do to help a lot is to have a simple site-wide error handler that doesn't expose any information on the screen but displays friendly error messages.That would take care of the displaying of tables and such.The other thing is that the stuff you pass through the url shouldn't be stuff like account numbers and suck. You can store all of that sort of thing in a session of some sort (either session variables, application variables, or some sort of structure)Then all you need to pass around is the unique session variable or CFIDCFTOKEN. John -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 9:19 AM To: CF-Talk Subject: RE: Securing CF Apps. I think the most important thing to do is lock down the server before worrying about code. That's usually where most attacks will focus. A few simple things you can do: I would agree that it is important, however protecting the code and its ability to be manipulated is just as important. After a coworker showed me a popular bank website that passed a lot of information in the URL, I got playing around with it while logged in and was able to change the look and feel, get the app to error out and expose information to me such as table names and column names via the SQL error page, etc... This is not some lesser known bank, this is a popular bank which shocked me. Break out the CFIDE from your server's web root and create another site for it. Then lock down that site with permissions from the web server to the file system. That's a given for us here. Don't store username and password in the CFIDE. Pass it through with your code on each call. You can even go as far as integrate your database server's users/roles directly into your application. What do you mean here? I am really interested in people's approach assuming the servers are already locked down properly (wouldn't that be nice!). The fact remains that we all pass parameters in the URL, forms, cookies, session vars, etc and this is what I was really trying to focus on. Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Lo Michael, A document I found very useful entitled A Guide to Building Secure Web Applications can be found here: http://sourceforge.net/project/showfiles.php?group_id=64424package_id=62287 Oliver. Tangorre, Michael wrote: What kind of defenses are people putting in to prevent cookie poisoning, session hijacking, parameter tampering, etc...? Does everyone keep this stuff in mind while coding? To be honest, my past code has been lax when it comes to making sure all the holes are plugged, and even now, some automated testing tools we have are finding vulnerabilities! The checks I have been putting in place and the encrypting of parameters and such are definitely adding time to development, but at the same time, the quality of the application is much much better what does everyone else do to prevent malicious users? Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I'm not sure what bank you are talking about, but I was able to do the same thing on First Union's (now Wachovia) site. However, they could have eliminated that with cferror. IMO a user should never ever see the cold fusion error. 1) It's an aesthetic nightmare 2) the user doesnt need to know what caused the error 3) security. As for the database thing: Say you are using Oracle. Rather than build your own user tables for each database, you can use Oracles built in user system. There are a number of benefits, such as creating profiles for password standards and account expiration and lockouts. IMO the best part is the security. You create an oracle user for each user of your application, then you assign them oracle roles for you application. So now oracle handles your applications users and roles. Then you can lock down each role with permissions. Say you have a view_only role. That role will only be assigned permission to SELECT on tables. I can get much more grandular that too, but I think you can get the idea. So now that your db is handling users and roles you pass this username/password with every db call. So if your sever is ever comprimised, neither the code or CFIDE will expose your dbs security. Additionally, everything should be in stored procedures. This will save you alot of time when setting up roles, and make them easier to manage. You can give the roles permission to access packages, rather than individual tables. Finally go into the CFIDE and on your datasource disable everything but stored procedure calls. You shouldn't have any SQL in your CF code. Again if that code is comprimised, or a error blows up and display lines, no one will have a clue to your db schema design. -adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 02:19 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. I think the most important thing to do is lock down the server before worrying about code. That's usually where most attacks will focus. A few simple things you can do: I would agree that it is important, however protecting the code and its ability to be manipulated is just as important. After a coworker showed me a popular bank website that passed a lot of information in the URL, I got playing around with it while logged in and was able to change the look and feel, get the app to error out and expose information to me such as table names and column names via the SQL error page, etc... This is not some lesser known bank, this is a popular bank which shocked me. Break out the CFIDE from your server's web root and create another site for it. Then lock down that site with permissions from the web server to the file system. That's a given for us here. Don't store username and password in the CFIDE. Pass it through with your code on each call. You can even go as far as integrate your database server's users/roles directly into your application. What do you mean here? I am really interested in people's approach assuming the servers are already locked down properly (wouldn't that be nice!). The fact remains that we all pass parameters in the URL, forms, cookies, session vars, etc and this is what I was really trying to focus on. Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
The OWASP site is very informative in deed (which is there that document stems from). The OWASP site is the first site I read in depth to learn about the issues we are all talking about... A document I found very useful entitled A Guide to Building Secure Web Applications can be found here: http://sourceforge.net/project/showfiles.php?group_id=64424pa ckage_id=62287 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: CFMAIL Attachments
On Tuesday 23 Mar 2004 04:03 am, Ben Densmore wrote: I'm trying to use the cfmailparam tag in cfmail to send a file attachment. When the file comes through it shows up with a .tmp extension Get ya size nines on and pad your bottom :-) The attachment filename is taken from the 'file' parameter to the cfmailparam, so just make sure you use the right extension there ! -- Tom Chiverton Advanced ColdFusion Programmer Tel: +44(0)1749 834997 email: [EMAIL PROTECTED] BlueFinger Limited Underwood Business Park Wookey Hole Road, WELLS. BA5 1AF Tel: +44 (0)1749 834900 Fax: +44 (0)1749 834901 web: www.bluefinger.com Company Reg No: 4209395 Registered Office: 2 Temple Back East, Temple Quay, BRISTOL. BS1 6EG. *** This E-mail contains confidential information for the addressee only. If you are not the intended recipient, please notify us immediately. You should not use, disclose, distribute or copy this communication if received in error. No binding contract will result from this e-mail until such time as a written document is signed on behalf of the company. BlueFinger Limited cannot accept responsibility for the completeness or accuracy of this message as it has been transmitted over public networks.*** [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
First Union's (now Wachovia) site. However, they could have eliminated that with cferror. Chevy Chase is JSP and has since corrected the error, but damn, what a blatant oversight. Say you are using Oracle. Rather than build your own user tables for each database, you can use Oracles built in user system. There are a number of benefits, such as creating profiles for password standards and account expiration and lockouts. IMO the best part is the security. You create an oracle user for each user of your application, then you assign them oracle roles for you application. So now oracle handles your applications users and roles. Then you can lock down each role with permissions. Say you have a view_only role. That role will only be assigned permission to SELECT on tables. I can get much more grandular that too, but I think you can get the idea. I'm with you and understand the concept in theory but maintainig hundreds, possibly thousands of accounts would be tedious! I have been using a roles/permissions based security architecture with great success so far, and the administrative app to control it for any application is plug and play with FB4... Just drop in the 3 circuits (MVC) and I now have a fully tested and functional security framework Needing to be populated of course. Additionally, everything should be in stored procedures. Totally agree with you here. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like -- marlon And Bobby you are right, I am being selfish, but the last time I checked, we don't have a whole lot of songs that feature the cowbell! [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users. -adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:12 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. First Union's (now Wachovia) site. However, they could have eliminated that with cferror. Chevy Chase is JSP and has since corrected the error, but damn, what a blatant oversight. Say you are using Oracle. Rather than build your own user tables for each database, you can use Oracles built in user system. There are a number of benefits, such as creating profiles for password standards and account expiration and lockouts. IMO the best part is the security. You create an oracle user for each user of your application, then you assign them oracle roles for you application. So now oracle handles your applications users and roles. Then you can lock down each role with permissions. Say you have a view_only role. That role will only be assigned permission to SELECT on tables. I can get much more grandular that too, but I think you can get the idea. I'm with you and understand the concept in theory but maintainig hundreds, possibly thousands of accounts would be tedious! I have been using a roles/permissions based security architecture with great success so far, and the administrative app to control it for any application is plug and play with FB4... Just drop in the 3 circuits (MVC) and I now have a fully tested and functional security framework Needing to be populated of course. Additionally, everything should be in stored procedures. Totally agree with you here. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
right click to comment selection in Homesite+
Is it possible to add custom commands to the right click menu in Homesite+? I'd like to be able to comment selected blocks of code by right clicking.I don't think this is possible, but thought I would ask.It is one of the things I like about jEdit. Failing that I suppose I'll have to define some kind of keyboard shortcut. Thanks, Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Okay, all this talk of encrypting url variables got me paranoid.I looked on cflib and checked out Tim Heald's UrlEncrypt/Decrypt functions.My question is why is cfusion_encrypt used instead of the standard encrypt function? -- marlon And Bobby you are right, I am being selfish, but the last time I checked, we don't have a whole lot of songs that feature the cowbell! -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 9:27 AM To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Is this possible in HTML?
For xml data, another option is XML data islands -- google for that.
(I have never used it, though)
-
Hugo AhleniusE-Mail: [EMAIL PROTECTED]
Project Officer Phone:+46 8 230460
UNEP GRID-ArendalFax:+46 8 230441
Stockholm OfficeMobile:+46 733 467111
WWW: http://www.grida.no
-
| -Original Message-
| From: Pete Ruckelshaus [mailto:[EMAIL PROTECTED]
| Sent: Tuesday, March 23, 2004 14:41
| To: CF-Talk
| Subject: Re: Is this possible in HTML?
|
| If it's straight HTML and you have no ability to employ
| Server Side Includes, you can use a linked _javascript_ file.
| I wrote a little utility that makes it easy to turn straight
| HTML into JS:
|
| cfparam name=a default=
| cfswitch _expression_=#a#
|cfcase value=process
| cfsavecontent variable=converted_js
| cfloop index=i list=#convert_string#
| delimiters=#chr(13)##chr(10)#cfif len(trim(i)) GT
| 0document.write('#jsstringformat(trim(i))#');
| /cfif/cfloop
| /cfsavecontent
| xmp
| #converted_js#
| /xmp
| cfheader name=content-disposition
| value=filename=converted.js cfcontent
| type=text/_javascript_#converted_js#cfabort
|/cfcase
|cfdefaultcase
|h4Enter the HTML that you want converted to _javascript_./h4
|
|form action="" method=post
| input type=hidden name=a value=process
| textarea rows=25 cols=100 name=convert_string
| style=width: 100%; height: 75%/textarea
| div align=centerinput type=submit value=Convert
| nbsp; input type=reset value= Reset /div
|/form
|/cfdefaultcase
| /cfswitch
|
|
|
| Pete
|- Original Message -
|From: MILAN MUSHRAN
|To: CF-Talk
|Sent: Tuesday, March 23, 2004 8:25 AM
|Subject: Is this possible in HTML?
|
|
|Can i have an equivalent of cfinclude in a HTML file?
|
|Thanks,
|Milan
|
|
|
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
RE: Securing CF Apps.
Okay, all this talk of encrypting url variables got me paranoid.I looked on cflib and checked out Tim Heald's UrlEncrypt/Decrypt functions.My question is why is cfusion_encrypt used instead of the standard encrypt function? Good question [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: right click to comment selection in Homesite+
man, I wish! No i don't think you can. At least I know you can't in HS 5.2, I don't think they've changed the VTOM to include that yet. That's one of my 28 suggestions for HS6: http://steve.secretagents.com/index.cfm?fuseaction=fuseblog.ShowCommentsArt icleID=20031206080320 Steve Nelson -Original Message- From: Plunkett, Matt [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:38 AM To: CF-Talk Subject: right click to comment selection in Homesite+ Is it possible to add custom commands to the right click menu in Homesite+? I'd like to be able to comment selected blocks of code by right clicking. I don't think this is possible, but thought I would ask.It is one of the things I like about jEdit. Failing that I suppose I'll have to define some kind of keyboard shortcut. Thanks, Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users. What if you switch from Oracle to SQL Server, aren't you now in for some reworking of your application? Seems like if you minimized the dependency of platform to the application, portability would be easier and more flexible; unless you were positive that the platform was not going to change or you were open to altering the app... mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re[2]: Securing CF Apps.
Hello Michael, because it creates url safe strings Tuesday, March 23, 2004, 10:46:13 AM, you wrote: Okay, all this talk of encrypting url variables got me paranoid.I looked on cflib and checked out Tim Heald's UrlEncrypt/Decrypt functions.My question is why is cfusion_encrypt used instead of the standard encrypt function? TM Good question TM [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
CF Hosting Questions
I am trying to figure out what route I should go with hosting for the future.Here are some of my needs/wishes and I'm curious what suggestions everyone could give: - Current hosting about 15 sites on a Linux set of clustered servers using MySQL and CFMX but extemely limited data transfer and email accounts, disk space, etc. Looking at growing substantially with some new sites and we're looking at moving towards a semi- or full-dedicated solution.I am familiar with basic tasks for management and upkeep of a server, but I can't dedicate time to host it locally and maintain it or anything, however, I'd like to be able to access it and do simple administration (add new sites, email account, virtual directories, etc) but in the event of a harddrive crash or something, I want someone else to be monitoring and take care of it. I'd like to get MS SQL, CFMX, unlimited POP (or IMAP) accounts for multiple domains, unlimited aliases for multiple domains.I'm using ImageMagick to do image resizing for multiple sites, so I'm thinking that I'll need a good amount of memory and at least 1 good processor in the machine.Hard drive space needs to be around 30-40GB+ and data transfer around 50-100+ would be great. Any suggestions for companies that offer this type of service or even thoughts on whether I should go with semi- or full-dedicated and also if I should just do colocation or something.Any help would be greatly appreciated! John [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Does anybody use the CFQUERYPARAM tag for securing sql which is highlighted at Securing Database Access Using the cfqueryparam Tag http://www.macromedia.com/devnet/mx/coldfusion/articles/cfqueryparam.htm l -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 15:27 To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
It is OK to code for a single DB for almost every application. It simply doesn't pay to ignore all DB enhancements and create fully DB independent SQL. There is a good article about that by Ben Forta. TK -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:52 AM To: CF-Talk Subject: RE: Securing CF Apps. It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users. What if you switch from Oracle to SQL Server, aren't you now in for some reworking of your application? Seems like if you minimized the dependency of platform to the application, portability would be easier and more flexible; unless you were positive that the platform was not going to change or you were open to altering the app... mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I am sure everybody who goes as far as encrypting their form variables remembers about cfqueryparam. Otherwise it is like barricading the window and leaving the barn door open :) TK -Original Message- From: Ian Vaughan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag for securing sql which is highlighted at Securing Database Access Using the cfqueryparam Tag http://www.macromedia.com/devnet/mx/coldfusion/articles/cfqueryparam.htm l -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 15:27 To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
How would you encrypt the url params ?Do you have any examples / tutorials on this ? It would be a good idea if one of the senior/experienced members of the list provided a checklist of application securityfor reference. i.e. 1.) Use CFQUERYPARAM 2.) Encrypt your Urls 3.)... etc... -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 16:00 To: CF-Talk Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: right click to comment selection in Homesite+
On Tue, 2004-03-23 at 07:38, Plunkett, Matt wrote: Is it possible to add custom commands to the right click menu in Homesite+? I'd like to be able to comment selected blocks of code by right clicking.I don't think this is possible, but thought I would ask.It is one of the things I like about jEdit. Failing that I suppose I'll have to define some kind of keyboard shortcut. To be a jerk :) you can do that with cfeclipse there is a right click option to comment out your selection and the default keyboard short cut is ctrl+shift+m - which btw was the keyboard short cut in cfstudio so you might try that in HS it might be the same. http://cfeclipse.rohanclan.com/ Cheers, -- Rob [EMAIL PROTECTED] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
I dunno. I'll ask Tim when he gets here. -adam -Original Message- From: Marlon Moyer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:40 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Okay, all this talk of encrypting url variables got me paranoid.I looked on cflib and checked out Tim Heald's UrlEncrypt/Decrypt functions.My question is why is cfusion_encrypt used instead of the standard encrypt function? -- marlon And Bobby you are right, I am being selfish, but the last time I checked, we don't have a whole lot of songs that feature the cowbell! -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 9:27 AM To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I didn't used to use it...but now am changing all queries to use it, as I find them in my code... very cool, just anotha new level of confidence...and power (if ya catch the lyric there, you're good) -Original Message- From: Ian Vaughan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag for securing sql which is highlighted at Securing Database Access Using the cfqueryparam Tag http://www.macromedia.com/devnet/mx/coldfusion/articles/cfqueryparam.htm l -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 15:27 To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
yes no. if you caught Ben's article in cfdj a month or two ago, he talks about how you shouldnt be too concerned with portability between databases. Afterall you'll be rewriting all your stored procedures anyway, so reliance on the user's table isn't the breaking point of portability. sides, how often does a shop really switch between SQL and Oracle? -adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:51 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users. What if you switch from Oracle to SQL Server, aren't you now in for some reworking of your application? Seems like if you minimized the dependency of platform to the application, portability would be easier and more flexible; unless you were positive that the platform was not going to change or you were open to altering the app... mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: right click to comment selection in Homesite+
Ah well.The other thing I miss from jEdit is the Favorites menu in the file lister.It's nice to be able to instantly jump to my Oracle folder to edit tnsnames.ora and so on.If only jEdit would run faster on my machine... -Original Message- From: Steve Nelson Sent: Tuesday, March 23, 2004 10:48 AM To: CF-Talk Subject: RE: right click to comment selection in Homesite+ man, I wish! No i don't think you can. At least I know you can't in HS 5.2, I don't think they've changed the VTOM to include that yet. That's one of my 28 suggestions for HS6: http://steve.secretagents.com/index.cfm?fuseaction=fuseblog.ShowCommentsArt icleID=20031206080320 Steve Nelson [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code -adam -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:59 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: CF Hosting Questions
Full managed dedicated server$125.00 monthly, Webmin control panel Shared Server with Webmin control panel $49.95 monthly Apache 2.0, CFMX 6.1, MySQL support, 10-40 GIGs storage. == Stop spam on your domain, Anti-spam solutions http://www.clickdoug.com/mailfilter.cfm For hosting solutions http://www.clickdoug.com == If you woke up breathing, congratulations! You have been given another chance! - Original Message - From: Burns, John D To: CF-Talk Sent: Tuesday, March 23, 2004 9:49 AM Subject: CF Hosting Questions I am trying to figure out what route I should go with hosting for the future.Here are some of my needs/wishes and I'm curious what suggestions everyone could give: - Current hosting about 15 sites on a Linux set of clustered servers using MySQL and CFMX but extemely limited data transfer and email accounts, disk space, etc. Looking at growing substantially with some new sites and we're looking at moving towards a semi- or full-dedicated solution.I am familiar with basic tasks for management and upkeep of a server, but I can't dedicate time to host it locally and maintain it or anything, however, I'd like to be able to access it and do simple administration (add new sites, email account, virtual directories, etc) but in the event of a harddrive crash or something, I want someone else to be monitoring and take care of it. I'd like to get MS SQL, CFMX, unlimited POP (or IMAP) accounts for multiple domains, unlimited aliases for multiple domains.I'm using ImageMagick to do image resizing for multiple sites, so I'm thinking that I'll need a good amount of memory and at least 1 good processor in the machine.Hard drive space needs to be around 30-40GB+ and data transfer around 50-100+ would be great. Any suggestions for companies that offer this type of service or even thoughts on whether I should go with semi- or full-dedicated and also if I should just do colocation or something.Any help would be greatly appreciated! John [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: right click to comment selection in Homesite+
-Original Message- From: Rob Sent: Tuesday, March 23, 2004 11:10 AM To: CF-Talk Subject: Re: right click to comment selection in Homesite+ To be a jerk :) you can do that with cfeclipse there is a right click option to comment out your selection and the default keyboard short cut is ctrl+shift+m - which btw was the keyboardshort cut in cfstudio so you might try that in HS it might be the same. http://cfeclipse.rohanclan.com/ http://cfeclipse.rohanclan.com/ I've been meaning to try this.Hopefully I will get to it later today.I tried Eclipse a year or so ago, but I was intimidated by how vast it seemed and how much you had to do to get set up. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
if you caught Ben's article in cfdj a month or two ago, he talks about how you shouldnt be too concerned with portability between databases. Afterall you'll be rewriting all your stored procedures anyway, so reliance on the user's table isn't the breaking point of portability. You may be rewriting your stored procedures but you may also find yourself reworking your schema as well, not too mention the code that will be affected. I can see having different user/passes for select, insert, update, and delete ROLES but I prefer to keep my application roles and permissions in tables. I guess to each his own method.. No one is right or wrong, just a preference thing. sides, how often does a shop really switch between SQL and Oracle? Not often but it happens. Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
adam you wrote: Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code how do you do sql stuff in your cfm pages if not? -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:22 AM To: CF-Talk Subject: Re: Securing CF Apps. Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code -adam -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:59 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Point being, if you want a secure app, don't let users see your fuseaction names. If I have proper checks and balances in, what harm is caused by showing the fuseaction name? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Use stored procedures. _ From: Tony Weeg [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:28 AM To: CF-Talk Subject: RE: Securing CF Apps. adam you wrote: Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code how do you do sql stuff in your cfm pages if not? -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:22 AM To: CF-Talk Subject: Re: Securing CF Apps. Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code -adam -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:59 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
how do you do sql stuff in your cfm pages if not? Stored Procedures [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Tangorre, Michael wrote: how do you do sql stuff in your cfm pages if not? Stored Procedures But you still have your stored procedure in the code, so.. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
the user/roles are in tables, they are just system tables. look, i dont want to get into the debate about coding for portability when it comes to dbs. you should def check out bens article on that one, as it was well written and he pretty much showed that there is so little in common between databases that its pretty much impossible, and an incredible waste of time. -adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:28 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. if you caught Ben's article in cfdj a month or two ago, he talks about how you shouldnt be too concerned with portability between databases. Afterall you'll be rewriting all your stored procedures anyway, so reliance on the user's table isn't the breaking point of portability. You may be rewriting your stored procedures but you may also find yourself reworking your schema as well, not too mention the code that will be affected. I can see having different user/passes for select, insert, update, and delete ROLES but I prefer to keep my application roles and permissions in tables. I guess to each his own method.. No one is right or wrong, just a preference thing. sides, how often does a shop really switch between SQL and Oracle? Not often but it happens. Mike [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
compiled stored procedures... brotha! my datasources are locked down in CFIDE to only allow stored procedure calls. -adam -Original Message- From: Tony Weeg [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:28 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. adam you wrote: Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code how do you do sql stuff in your cfm pages if not? -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:22 AM To: CF-Talk Subject: Re: Securing CF Apps. Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code -adam -Original Message- From: Matt Robertson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:59 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
look, i dont want to get into the debate about coding for portability when it comes to dbs. you should def check out bens article on that one, as it was well written and he pretty much showed that there is so little in common between databases that its pretty much impossible, and an incredible waste of time. I'll take a look at the article later. To each his own... [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I agree that Ben's article explains this very nicely.Not sure if this link works or not: http://www.sys-con.com/coldfusion/article.cfm?id=705 Kevin. _ From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:36 AM To: CF-Talk Subject: Re: Securing CF Apps. the user/roles are in tables, they are just system tables. look, i dont want to get into the debate about coding for portability when it comes to dbs. you should def check out bens article on that one, as it was well written and he pretty much showed that there is so little in common between databases that its pretty much impossible, and an incredible waste of time. -adam -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:28 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. if you caught Ben's article in cfdj a month or two ago, he talks about how you shouldnt be too concerned with portability between databases. Afterall you'll be rewriting all your stored procedures anyway, so reliance on the user's table isn't the breaking point of portability. You may be rewriting your stored procedures but you may also find yourself reworking your schema as well, not too mention the code that will be affected. I can see having different user/passes for select, insert, update, and delete ROLES but I prefer to keep my application roles and permissions in tables. I guess to each his own method.. No one is right or wrong, just a preference thing. sides, how often does a shop really switch between SQL and Oracle? Not often but it happens. Mike _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
anotha new level of confidence...and power Pantera - Vulgar Display Of Power:) If you want a secure app, don't let users see your fuseaction names. If you want a secure app, don't let anyone use it...;) As for using the security of your DB instead of application-based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! A few pointers I use when thinking about the security of CF web apps: 1. Make sure CF server is suitably locked down - e.g.: - all services that aren't needed off (eg POP3 on a webserver) - file ownership set correctly - CF service running as a non-privileged user; 2. All incoming (URL/FORM/COOKIE/CLIENT stored in cookie) variables filtered and checked for validity; 3. Use different datasources for different query types - have one DS for SELECT-type queries (where the DB user only has SELECT privs) and one for INSERTs etc (DB user has fuller privs); 4. ALWAYS use CFQUERYPARAM - in my experience the lack of cachedwithin= can either be overcome by using shared scopes or is not fully used - for example if you're on a shared server with tens or hundreds of separate web apps all using cachedwithin then it's unlikely that your results will stayed cached for long! 5. Sure, if your DBMS has the facility, use stored procedures, but don't go over the top - the more complex your app, the more difficult future maintenance will be and the more likely someone will make a mistake that will lead to a possible exploitation point. 6. Store passwords using a one-way hash value unless absolutely necessary - there's no real problem generating a new password if the user's forgotten their old one rather. That's just a few things off the top of my head - I'm sure people can come up with a whole lot more! Tim. -- --- CF_CodingContest mode=judging newentries=false Maze Solver - http://tech.badpen.com/cfcontest/ --- RAWNET LTD - Internet, New Media and ebusiness Gurus. WE'VE MOVED - for our new address, please visit our website at http://www.rawnet.com/ or call us any time on 0800 294 24 24. --- This message may contain information which is legally privileged and/or confidential.If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. --- -Original Message- From: Tony Weeg [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 16:15 To: CF-Talk Subject: RE: Securing CF Apps. I didn't used to use it...but now am changing all queries to use it, as I find them in my code... very cool, just anotha new level of confidence...and power (if ya catch the lyric there, you're good) -Original Message- From: Ian Vaughan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag for securing sql which is highlighted at Securing Database Access Using the cfqueryparam Tag http://www.macromedia.com/devnet/mx/coldfusion/articles/cfquer yparam.htm l -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 15:27 To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
This is incorrect.Using cfquery in conjunction with cfqueryparam correctly is perfectly fine. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:22 am Subject: Re:Securing CF Apps. Yes, but you shouldnt put SQL code in your CFM pages! cfquery != secure code -adam -Original Message- From: Matt Robertson [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 03:59 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag I think a LOT of us here do.If you need to take a first step, make using cfqueryparam it (and I suppose next encrypt your url parms?) Matt Robertson [EMAIL PROTECTED] MSB Designs, Inc.http://mysecretbase.com [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
my datasources are locked down in CFIDE to only allow stored procedure calls. That doesn't sound very locked down. Why didn't you do that at the database user level? Doing it with CF is not even close to as secure as doing it with the database. Oh and the other part about cfquery being insecure is just plain foolish. Certainly cfquery can be a security problem, but then again so can cfstoredproc. It all depends on how you use them. -Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
I just read the article and at the very bottom, here's what I read: Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutputa name=#dir#/a/cfoutput 109 : a href="" class=headbJava/a 110 :cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Yeah I agree encrypting all variables is a bit much, but encrypting some of them might be enough to make the casual hacker move on to a different server without encrypted variables.If that person really wanted to decrypt those variables, they could.The most important thing to do is to make sure data is validated before you do anything with it. Kevin _ From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 AM To: CF-Talk Subject: Re: Securing CF Apps. There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
Unfortunately, this is not one of Ben's better articles, and I think that people are drawing the wrong conclusions from the article. He's not saying to never bother with DB portability, but instead he's saying that to look at your requirements, and to determine whether or not portability is required before automatically assuming it is. Quote from the article: Of course, there is one exception to this. If you were to write an application that needed to be used with multiple DBMSs (commercial software, or applications distributed to other users) then portability is an obvious immediate concern. - Original Message - From: Kazmierczak, Kevin [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:39 am Subject: RE: Securing CF Apps. I agree that Ben's article explains this very nicely.Not sure if thislink works or not: http://www.sys-con.com/coldfusion/article.cfm?id=705 Kevin. _ From: Adrocknaphobia [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:36 AM To: CF-Talk Subject: Re: Securing CF Apps. the user/roles are in tables, they are just system tables. look, i dont want to get into the debate about coding for portability when it comes to dbs. you should def check out bens article on that one, as it was well written and he pretty much showed that there is so littlein common between databases that its pretty much impossible, and an incredible waste of time. -adam -Original Message- From: Tangorre, Michael [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:28 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. if you caught Ben's article in cfdj a month or two ago, he talks about how you shouldnt be too concerned with portability between databases. Afterall you'll be rewriting all your stored procedures anyway, so reliance on the user's table isn't the breaking point of portability. You may be rewriting your stored procedures but you may also find yourself reworking your schema as well, not too mention the code that will be affected. I can see having different user/passes for select, insert, update, and delete ROLES but I prefer to keep my application roles and permissions in tables. I guess to each his own method.. No one is right or wrong,just a preference thing. sides, how often does a shop really switch between SQL and Oracle? Not often but it happens. Mike _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Nice! Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutputa name=#dir#/a/cfoutput 109 : a href="" class=headbJava/a 110 :cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Tangorre, Michael wrote: It's really not tedious at all. All permissions are assigned to roles. Which there are only a few per application. So thats really all you have to manage aside from assigning roles to the users. What if you switch from Oracle to SQL Server, aren't you now in for some reworking of your application? Yes, but you have to rework your data access layer anyway if you are using stored procedures or advanced SQL. Seems like if you minimized the dependency of platform to the application, portability would be easier and more flexible; unless you were positive that the platform was not going to change or you were open to altering the app... But minimizing isn't the same as doing away with it. Don't get me wrong, I am all for writing SQL as portable as possible and harassing vendors to implement the standard, but not at all cost. Writing portable SQL to me means not using || as an OR operator, not using double quotes as a string delimiter and not omitting a FROM line. It doesn't mean not using functionality where it makes sense. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Anyone know of a description of each of the CFQUERYPARAM CFSQLTypes? I Googled them but couldn't fine an in-depth description of each one and what it's suitble use. Mostly I just found the list - most are self explanatory but some are not. CF_SQL_CHAR CF_SQL_BIGINT CF_SQL_BIT CF_SQL_CHAR CF_SQL_BLOB CF_SQL_CLOB CF_SQL_DATE CF_SQL_DECIMAL CF_SQL_DOUBLE CF_SQL_FLOAT CF_SQL_IDSTAMP CF_SQL_INTEGER CF_SQL_LONGVARCHAR CF_SQL_MONEY CF_SQL_MONEY4 CF_SQL_NUMERIC CF_SQL_REAL CF_SQL_REFCURSOR CF_SQL_SMALLINT CF_SQL_TIME CF_SQL_TIMESTAMP CF_SQL_TINYINT CF_SQL_VARCHAR -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Nice! Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutputa name=#dir#/a/cfoutput 109 : a href="" class=headbJava/a 110 :cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
good stuff tim! -Original Message- From: Tim Blair [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:37 AM To: CF-Talk Subject: RE: Securing CF Apps. anotha new level of confidence...and power Pantera - Vulgar Display Of Power:) If you want a secure app, don't let users see your fuseaction names. If you want a secure app, don't let anyone use it...;) As for using the security of your DB instead of application-based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! A few pointers I use when thinking about the security of CF web apps: 1. Make sure CF server is suitably locked down - e.g.: - all services that aren't needed off (eg POP3 on a webserver) - file ownership set correctly - CF service running as a non-privileged user; 2. All incoming (URL/FORM/COOKIE/CLIENT stored in cookie) variables filtered and checked for validity; 3. Use different datasources for different query types - have one DS for SELECT-type queries (where the DB user only has SELECT privs) and one for INSERTs etc (DB user has fuller privs); 4. ALWAYS use CFQUERYPARAM - in my experience the lack of cachedwithin= can either be overcome by using shared scopes or is not fully used - for example if you're on a shared server with tens or hundreds of separate web apps all using cachedwithin then it's unlikely that your results will stayed cached for long! 5. Sure, if your DBMS has the facility, use stored procedures, but don't go over the top - the more complex your app, the more difficult future maintenance will be and the more likely someone will make a mistake that will lead to a possible exploitation point. 6. Store passwords using a one-way hash value unless absolutely necessary - there's no real problem generating a new password if the user's forgotten their old one rather. That's just a few things off the top of my head - I'm sure people can come up with a whole lot more! Tim. -- --- CF_CodingContest mode=judging newentries=false Maze Solver - http://tech.badpen.com/cfcontest/ --- RAWNET LTD - Internet, New Media and ebusiness Gurus. WE'VE MOVED - for our new address, please visit our website at http://www.rawnet.com/ or call us any time on 0800 294 24 24. --- This message may contain information which is legally privileged and/or confidential.If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. --- -Original Message- From: Tony Weeg [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 16:15 To: CF-Talk Subject: RE: Securing CF Apps. I didn't used to use it...but now am changing all queries to use it, as I find them in my code... very cool, just anotha new level of confidence...and power (if ya catch the lyric there, you're good) -Original Message- From: Ian Vaughan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 10:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Does anybody use the CFQUERYPARAM tag for securing sql which is highlighted at Securing Database Access Using the cfqueryparam Tag http://www.macromedia.com/devnet/mx/coldfusion/articles/cfquer yparam.htm l -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: 23 March 2004 15:27 To: CF-Talk Subject: RE: Securing CF Apps. I do not encrypt all values in my forms (I do for URLs though). The reason I encrypt some form field values and not others is that they are not all important if altered by a malicious user... For instance. If I have a text box, I do not need to encrypt a date... My checks to ensure that the text supplied in that field is a date will take care of that. I encrypt important values that are used within queries: SELECT * FROM table WHERE someId = Decrypt(form.idfield,key) This hides the type of values I am using to build the query with and it also limits the data that is exposed to the end user. Mike Yes. All URL and FORM variables should be encypted. Especially if you are using a fusebox methodology. I've tried this, but my users were really upset with prompts such as this: Please Enter the Hash value of the date you would like [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Image Tag
Hello all, I lost me link to a site that had a few types of Image manipulation tags. The tags or whatever could crop, resize, sharpen and a ton of other things. I can't seem to Google it either. I was hoping you guys would know. I think the creator is on this list too. The site was dark redish with several examples. Its drive me crazy... I seem to remember it being called farcy, firefly, freakout I dunno it was something like that. Thanks, Neal Bailey Internet Marketing Manager E-mail:mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
http://www.blinex.com/~sam/CF_SQL_TYPES.cfm -Matt On Mar 23, 2004, at 11:58 AM, Robert Redpath wrote: Anyone know of a description of each of the CFQUERYPARAM CFSQLTypes? I Googled them but couldn't fine an in-depth description of each one and what it's suitble use. Mostly I just found the list - most are self explanatory but some are not. CF_SQL_CHAR CF_SQL_BIGINT CF_SQL_BIT CF_SQL_CHAR CF_SQL_BLOB CF_SQL_CLOB CF_SQL_DATE CF_SQL_DECIMAL CF_SQL_DOUBLE CF_SQL_FLOAT CF_SQL_IDSTAMP CF_SQL_INTEGER CF_SQL_LONGVARCHAR CF_SQL_MONEY CF_SQL_MONEY4 CF_SQL_NUMERIC CF_SQL_REAL CF_SQL_REFCURSOR CF_SQL_SMALLINT CF_SQL_TIME CF_SQL_TIMESTAMP CF_SQL_TINYINT CF_SQL_VARCHAR -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Nice! Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutputa name=#dir#/a/cfoutput 109 : a href="" class=headbJava/a 110 : cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Robert Redpath wrote: Anyone know of a description of each of the CFQUERYPARAM CFSQLTypes? They map exactly to the JDBC spec (http://java.sun.com). How JDBC datatypes match your database native datatypes should be in the documentation of the JDBC driver. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
SOT: Pending XP SP2 Changes
Caught this blog entry that specifically explains some of the IE changes that are being made in the upcoming XP SP2 release: http://blogs.msdn.com/jeffdav/archive/2004/03/22/94080.aspx Specifically, he mentions changes to popups, auto-downloads, and activeX control installations. The popup changes are particularly involved, though I can't tell what exactly needs to change in a developer's code to get around the lock down. Regards, Dave. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Linkpoint API Host not responding problem.
Thanks Ian, I will try this... I still have yet to get an answer from LinkPoint. Gosh the sad thing is I have heard they are supposed to be pretty good. If that true I can't imagine what others are like. I guess since they no longer support ColdFusion it's not going to be easy to get help from them. Neal Bailey Internet Marketing Manager E-mail:mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] _ From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 8:53 AM To: CF-Talk Subject: RE: Linkpoint API Host not responding problem. Here is an example from the documentation.I'm not sure exactly where you would put this in our code, quite possibly you would put it in multiple locations of your code. blockquote * You can nest cftry blocks. For example, the following structure is valid: cftry code that may cause an exception cfcatch ... cftry First level of exeption handling code cfcatch ... Second level of exception handling code /cfcatch /cftry /cfcatch /cftry If an exception occurs in the first level of exception-handling code, the inner cfcatch block can catch and handle it. (An exception in a cfcatch block cannot be handled by cfcatch blocks at the same level as that block.) /blockquote This shows the concept of putting nested try-catch blocks inside the the catch block of other try-catch blocks. (That is not an awkward sentence!) Anyway, you can use something like this to try a piece of code as many times as you like, then still have an out of none of the trays work. What I would probably do is put the code I'm trying in some kind of included source (cfinclude, custom tag, UDF or CFC) then I could call the code in multiple locations of the nested try-catch blocks without having to re-code it every time. HTH -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA C code. C code run. Run code run. Please! - Cynthia Dunning _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
What exactly are you doing in your application that demands wimpy ecryption? And what do you when the hardcore hacker hits your site? Sounds to me that people do silly, potentially harmful things like url encryption simply because they don't properly consider data input, output and transfer and then make themselves feel better by saying that it deters casual hackers, whatever the hell that means. - Original Message - From: Kazmierczak, Kevin [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:49 am Subject: RE: Securing CF Apps. Yeah I agree encrypting all variables is a bit much, but encrypting some of them might be enough to make the casual hacker move on to a differentserver without encrypted variables.If that person really wanted to decrypt those variables, they could.The most important thing to do is to make sure data is validated before you do anything with it. Kevin _ From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 AM To: CF-Talk Subject: Re: Securing CF Apps. There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
If only they encrypted their URL variables.That would've fixed it. - Original Message - From: Tangorre, Michael [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:54 am Subject: RE: Securing CF Apps. Nice! Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutput/cfoutput 109 : http://www.sys-con.com/java class=headbJava 110 :cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
Tim Blair wrote: As for using the security of your DB instead of application-based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! Which is of course set up to only allow connections from the web server, regardless of the credentials offered. Layer after layer after layer :-) A few pointers I use when thinking about the security of CF web apps: 1. Make sure CF server is suitably locked down - e.g.: Compared to this, the rest is probably insignificant. The total number of compromised sites/servers based on weaknesses in the OS and webserver is probably a magnitude larger as the number of exploited sites/servers based on anything that can be influenced by CF code/setup. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Image Tag
CFX_Image and there a bunch of tags built based on it Bryan Stevenson B.Comm. VP Director of E-Commerce Development Electric Edge Systems Group Inc. t. 250.920.8830 e. [EMAIL PROTECTED] - Macromedia Associate Partner www.macromedia.com - Vancouver Island ColdFusion Users Group Founder Director www.cfug-vancouverisland.com - Original Message - From: Bailey, Neal To: CF-Talk Sent: Tuesday, March 23, 2004 9:02 AM Subject: Image Tag Hello all, I lost me link to a site that had a few types of Image manipulation tags. The tags or whatever could crop, resize, sharpen and a ton of other things. I can't seem to Google it either. I was hoping you guys would know. I think the creator is on this list too. The site was dark redish with several examples. Its drive me crazy... I seem to remember it being called farcy, firefly, freakout I dunno it was something like that. Thanks, Neal Bailey Internet Marketing Manager E-mail:mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Image Tag
Hello Neal, efflare.com Tuesday, March 23, 2004, 12:02:37 PM, you wrote: BN Hello all, BN I lost me link to a site that had a few types of Image manipulation tags. BN The tags or whatever could crop, resize, sharpen and a ton of other things. BN I can't seem to Google it either. I was hoping you guys would know. I think BN the creator is on this list too. The site was dark redish with several BN examples. BN Its drive me crazy... I seem to remember it being called farcy, firefly, BN freakout I dunno it was something like that. BN Thanks, BN Neal Bailey BN Internet Marketing Manager BN E-mail:mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] BN [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
If only they encrypted their URL variables.That would've fixed it. That was cool. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Exactly what I was looking for - Thanks -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:04 PM To: CF-Talk Subject: Re: Securing CF Apps. http://www.blinex.com/~sam/CF_SQL_TYPES.cfm -Matt On Mar 23, 2004, at 11:58 AM, Robert Redpath wrote: Anyone know of a description of each of the CFQUERYPARAM CFSQLTypes? I Googled them but couldn't fine an in-depth description of each one and what it's suitble use. Mostly I just found the list - most are self explanatory but some are not. CF_SQL_CHAR CF_SQL_BIGINT CF_SQL_BIT CF_SQL_CHAR CF_SQL_BLOB CF_SQL_CLOB CF_SQL_DATE CF_SQL_DECIMAL CF_SQL_DOUBLE CF_SQL_FLOAT CF_SQL_IDSTAMP CF_SQL_INTEGER CF_SQL_LONGVARCHAR CF_SQL_MONEY CF_SQL_MONEY4 CF_SQL_NUMERIC CF_SQL_REAL CF_SQL_REFCURSOR CF_SQL_SMALLINT CF_SQL_TIME CF_SQL_TIMESTAMP CF_SQL_TINYINT CF_SQL_VARCHAR -Original Message- From: Tangorre, Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:54 AM To: CF-Talk Subject: RE: Securing CF Apps. Nice! Error Occurred While Processing Request Element PUB_JDJ is undefined in APPLICATION. The error occurred in E:\Inetpub\wwwroot\content\roundup.cfm: line 110 Called from E:\Inetpub\wwwroot\coldfusion\cffooter.cfm: line 23 Called from E:\Inetpub\wwwroot\coldfusion\article.cfm: line 302 108 : cfoutputa name=#dir#/a/cfoutput 109 : a href="" class=headbJava/a 110 :cfmodule template=/sc/pub_overview.cfm pub_id=#application.pub_jdj# catids=677 datasource=#application.datasource_syscon# 111 : /td/tr/table 112 : hr color=efefef _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Image Tag
Imagemagick is really good too, but it requires the installation of the imagemagick program on the server and then you can use the magicktag to access it though.Pretty nice. John -Original Message- From: Critter [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:19 PM To: CF-Talk Subject: Re: Image Tag Hello Neal, efflare.com Tuesday, March 23, 2004, 12:02:37 PM, you wrote: BN Hello all, BN I lost me link to a site that had a few types of Image manipulation tags. BN The tags or whatever could crop, resize, sharpen and a ton of other things. BN I can't seem to Google it either. I was hoping you guys would know. BN I think the creator is on this list too. The site was dark redish BN with several examples. BN Its drive me crazy... I seem to remember it being called farcy, BN firefly, freakout I dunno it was something like that. BN Thanks, BN Neal Bailey BN Internet Marketing Manager BN E-mail:mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] BN [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
As for using the security of your DB instead of application- based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! Which is of course set up to only allow connections from the web server, regardless of the credentials offered. Layer after layer after layer :-) And has no external network access except through the DMZ that the CF server is sitting in, behind the firewall that...Oh, no, I'll stop there I think.;) Tim. -- --- CF_CodingContest mode=judging newentries=false Maze Solver - http://tech.badpen.com/cfcontest/ --- RAWNET LTD - Internet, New Media and ebusiness Gurus. WE'VE MOVED - for our new address, please visit our website at http://www.rawnet.com/ or call us any time on 0800 294 24 24. --- This message may contain information which is legally privileged and/or confidential.If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. --- [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
ActivScan
CFdev used to sell a program that allowed integrating a Twain compliant device into a CF application for capturing scanned images (ActivScan). Best I can tell there were some unresolvable issues regarding new releases of the Windows OS. Does anyone know of an alternative, or at least what the issues might have been? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
cf_sql_types (WAS Re: Securing CF Apps.)
While we're on the topic Has anyone besides me encountered an instance where using the cf_sql_types doesn't work, but using jdbc types does? In other words, in a stored proc, I have this procparam which works: cfprocparam cfsqltype=varchar value=#arguments.category# !--- category --- If I change the vachar to cf_sql_varchar it fails. (Oracle 8.1.7 varchar2 field.) Is this a bug? An undocumented feature that you can use the jdbc types instead of the cf_sql_types? I don't see anything about that in the docs: http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-b16.htm#wp1102102 -Deanna - Original Message - From: Matt Liotta http://www.blinex.com/~sam/CF_SQL_TYPES.cfm -Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
And has no external network access except through the DMZ that the CF server is sitting in, behind the firewall that... Oh, no, I'll stop there I think. ;) No, don't do that. The CF server SHOULD NOT be in the DMZ. No server should be in the DMZ unless it is a bastion host, which an application server by definition is not. -Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
I agree that data validation is the most important thing you can do. But if you have information that you don't want a user messing around with that happens to be in a form or url, it doesn't seem like there isn't any harm in weakly encrypting it.For example, this might deter my grandma from inserting drop table SQL commands in the url. If a hardcore hacker hits your site, you look for the most recent backup ;) Kevin _ From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:59 AM To: CF-Talk Subject: Re: RE: Securing CF Apps. What exactly are you doing in your application that demands wimpy ecryption? And what do you when the hardcore hacker hits your site? Sounds to me that people do silly, potentially harmful things like url encryption simply because they don't properly consider data input, output and transfer and then make themselves feel better by saying that it deters casual hackers, whatever the hell that means. - Original Message - From: Kazmierczak, Kevin [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:49 am Subject: RE: Securing CF Apps. Yeah I agree encrypting all variables is a bit much, but encrypting some of them might be enough to make the casual hacker move on to a differentserver without encrypted variables.If that person really wanted to decrypt those variables, they could.The most important thing to do is to make sure data is validated before you do anything with it. Kevin _ From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 AM To: CF-Talk Subject: Re: Securing CF Apps. There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
No the db is locked down in the same way. Roles are only granted execute on packages/procs that they need. In production your db shouldn't allow any client tools to connect, however even if the user does connect to your db, they still have the same restrictions. They can only do/see what you've allowed for that role. My issue with cfquery is that you are exposing your db design. It's alot harder to hack a db is you dont know the table and column names. With cfstoredproc all you are expsoing in the code is the procedure name and the types of arguments it takes. Whats actually going on in the db, is completely hidden. As for encrypting the fuseaction, the question is why not? Users can start throwing errors by trying different fuseaction calls. Which in turn could expose too much info if you dont have a site wide error handler. The topic of this thread is securing cf apps. Although it may not be 100% necessary, it sure doesn't hurt. (minimal processing increase aside) -adam -Original Message- From: Matt Liotta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:47 PM To: 'CF-Talk' Subject: Re: Securing CF Apps. my datasources are locked down in CFIDE to only allow stored procedure calls. That doesn't sound very locked down. Why didn't you do that at the database user level? Doing it with CF is not even close to as secure as doing it with the database. Oh and the other part about cfquery being insecure is just plain foolish. Certainly cfquery can be a security problem, but then again so can cfstoredproc. It all depends on how you use them. -Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
second try: customizing JRun servlet 500 error page
Sent this yesterday and got no responses. Trying again today, maybe with all the security talk somebody will have an answer. I'd like to be able to completely (or as completely as possible) conceal what technology is running my web application (with extensionless URLs, renamed and/or encrypted CFID/CFTOKEN identifiers, modified web server identification headers, etc.) I'm not trying to accomplish security through obscurity; I view this as just an additional layer of abstraction. I'd like to get rid of all information leaks that identify the web/app servers since the user has no need for that information. My question: on CFMX 6.1 if I feed in a query string containing an invalid URL character encoding (like %zz), I get a 500 Internal Server Error response back identifying itself as a JRun servlet error. For example, requesting this: page.cfm?test=%zz produces the response: headtitleJRun Servlet Error/title/headh1500 null/h1body /body Is it possible to modify the error handler that is producing this response? One solution that would deal with this situation as well as all other responses not coming from within my application or my own error handler would be to add a filter at the web server that checks all responses for a certain custom header, and redirects/rewrites them if that header is not present. I've poked around in /CFusionMX/wwwroot/WEB-INF/web.xml, and I see the following two entries, but they don't appear to correspond to the error I'm getting back. I think those point to the standard templates for unhandled errors within java/Cold Fusion. error-page exception-typejava.lang.Throwable/exception-type location/WEB-INF/exception/java/lang/Exception.cfm/location /error-page error-page error-code500/error-code location/WEB-INF/exception/java/lang/Exception.cfm/location /error-page Thanks, Conan [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
Come on Kaz... We all know your Grandma is really the 9 year old programming kid genius from Germany on his Alienware mega machine who just housed the Microsoft development team at topcoder.com last night... Lets be honest ok. I agree that data validation is the most important thing you can do. But if you have information that you don't want a user messing around with that happens to be in a form or url, it doesn't seem like there isn't any harm in weakly encrypting it.For example, this might deter my grandma from inserting drop table SQL commands in the url. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
exactly. I only mention not using cfquery as a final security against someone who gets access to the file system and can read your cfms. but you are most definitely right, the most important part of security is locking down the server. -adam -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 05:11 PM To: 'CF-Talk' Subject: Re: Securing CF Apps. Tim Blair wrote: As for using the security of your DB instead of application-based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! Which is of course set up to only allow connections from the web server, regardless of the credentials offered. Layer after layer after layer :-) A few pointers I use when thinking about the security of CF web apps: 1. Make sure CF server is suitably locked down - e.g.: Compared to this, the rest is probably insignificant. The total number of compromised sites/servers based on weaknesses in the OS and webserver is probably a magnitude larger as the number of exploited sites/servers based on anything that can be influenced by CF code/setup. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
no one ever claimed that security is simple. a generalization would be that the more complex security is, the harder it is to crack. -adam -Original Message- From: Tim Blair [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 05:19 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. As for using the security of your DB instead of application- based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! Which is of course set up to only allow connections from the web server, regardless of the credentials offered. Layer after layer after layer :-) And has no external network access except through the DMZ that the CF server is sitting in, behind the firewall that...Oh, no, I'll stop there I think.;) Tim. -- --- CF_CodingContest mode=judging newentries=false Maze Solver - http://tech.badpen.com/cfcontest/ --- RAWNET LTD - Internet, New Media and ebusiness Gurus. WE'VE MOVED - for our new address, please visit our website at http://www.rawnet.com/ or call us any time on 0800 294 24 24. --- This message may contain information which is legally privileged and/or confidential.If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
My personal opinion is that your app should be smart enough not to let people pass SQL commands in the URL.I would imagine that everyone knows that much. I think some of the suggestions that have come out were just mentioning what could be done to help prevent a lot of trouble if people somehow get access to the code by compromising the server.That was Adam's thing about using Stored Procedures.Then if someone somehow downloaded all of your code, they couldn't figure out your database structure by looking through your CFQUERY calls.I think he would agree that it's still not 100% secure by any means but it does solve that particular problem for people figure out your schema by seeing your queries. The other suggestion that I would make is that on pages where you're doing some kind of database manipulation queries based on form or url variables to do a check to make sure that the request is coming from the same domain or have a list of acceptable domains if you're expecting posts from other domains. That can help to prevent hackers from posting to your pages unless somehow they can execute the code from your server, in which case, you have some other problems that you need to address. My 2 cents, John -Original Message- From: Kazmierczak, Kevin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:40 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. I agree that data validation is the most important thing you can do. But if you have information that you don't want a user messing around with that happens to be in a form or url, it doesn't seem like there isn't any harm in weakly encrypting it.For example, this might deter my grandma from inserting drop table SQL commands in the url. If a hardcore hacker hits your site, you look for the most recent backup ;) Kevin _ From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:59 AM To: CF-Talk Subject: Re: RE: Securing CF Apps. What exactly are you doing in your application that demands wimpy ecryption? And what do you when the hardcore hacker hits your site? Sounds to me that people do silly, potentially harmful things like url encryption simply because they don't properly consider data input, output and transfer and then make themselves feel better by saying that it deters casual hackers, whatever the hell that means. - Original Message - From: Kazmierczak, Kevin [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:49 am Subject: RE: Securing CF Apps. Yeah I agree encrypting all variables is a bit much, but encrypting some of them might be enough to make the casual hacker move on to a differentserver without encrypted variables.If that person really wanted to decrypt those variables, they could.The most important thing to do is to make sure data is validated before you do anything with it. Kevin _ From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 AM To: CF-Talk Subject: Re: Securing CF Apps. There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
here is a snippet that I use in my application.cfm files to prevent cf tags in form fields... I think the webrat made this...good idea nonetheless. !--- This section protects against FORM Hacks in which a user (if they knew coldfusion) could set session variables by typing in coldfusion in a field value and submitting it to the server for evaluation. ~Todd R --- !--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER --- cfif isDefined(FORM) and IsStruct(FORM) and StructCount(FORM) GT 0 cfloop collection=#FORM# item=y cfset checkHackAgainst = evaluate(y) cfif checkHackAgainst contains CF cflocation url=""> addtoken=No /cfif /cfloop /cfif !--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER ---!--- ANTI HACKER --- -Original Message- From: Burns, John D [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:47 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. My personal opinion is that your app should be smart enough not to let people pass SQL commands in the URL.I would imagine that everyone knows that much. I think some of the suggestions that have come out were just mentioning what could be done to help prevent a lot of trouble if people somehow get access to the code by compromising the server.That was Adam's thing about using Stored Procedures.Then if someone somehow downloaded all of your code, they couldn't figure out your database structure by looking through your CFQUERY calls.I think he would agree that it's still not 100% secure by any means but it does solve that particular problem for people figure out your schema by seeing your queries. The other suggestion that I would make is that on pages where you're doing some kind of database manipulation queries based on form or url variables to do a check to make sure that the request is coming from the same domain or have a list of acceptable domains if you're expecting posts from other domains. That can help to prevent hackers from posting to your pages unless somehow they can execute the code from your server, in which case, you have some other problems that you need to address. My 2 cents, John -Original Message- From: Kazmierczak, Kevin [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:40 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. I agree that data validation is the most important thing you can do. But if you have information that you don't want a user messing around with that happens to be in a form or url, it doesn't seem like there isn't any harm in weakly encrypting it.For example, this might deter my grandma from inserting drop table SQL commands in the url. If a hardcore hacker hits your site, you look for the most recent backup ;) Kevin _ From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:59 AM To: CF-Talk Subject: Re: RE: Securing CF Apps. What exactly are you doing in your application that demands wimpy ecryption? And what do you when the hardcore hacker hits your site? Sounds to me that people do silly, potentially harmful things like url encryption simply because they don't properly consider data input, output and transfer and then make themselves feel better by saying that it deters casual hackers, whatever the hell that means. - Original Message - From: Kazmierczak, Kevin [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:49 am Subject: RE: Securing CF Apps. Yeah I agree encrypting all variables is a bit much, but encrypting some of them might be enough to make the casual hacker move on to a differentserver without encrypted variables.If that person really wanted to decrypt those variables, they could.The most important thing to do is to make sure data is validated before you do anything with it. Kevin _ From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 11:39 AM To: CF-Talk Subject: Re: Securing CF Apps. There is nothing inherently wrong with letting users see fuseaction names. And to use a very weak form of encryption that makes you think that you're somehow safe against attacks is an extremely bad situation to be in. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 9:24 am Subject: Re:Securing CF Apps. Point being, if you want a secure app, don't let users see your fuseaction names. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 04:14 PM To: 'CF-Talk' Subject: Re:Securing CF Apps. Yes. All URL and FORM variables should be encypted. This is beyond silly. Especially if you are using a fusebox methodology. Using or not using Fusebox has nothing to do with the situation. _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Securing CF Apps.
My issue with cfquery is that you are exposing your db design. It's alot harder to hack a db is you dont know the table and column names. huh? As for encrypting the fuseaction, the question is why not? Because it's useless. Let's think this through: I have a fuseaction called products.list It encrypts to wafiawjfw I type in wafiawjfw in the url. It lists the products. Where's the security? Users can start throwing errors by trying different fuseaction calls. Which in turn could expose too much info if you dont have a site wide error handler. Let me get this straight.I should waste time encrypting urls, and yet be stupid enough not to have an error handler. Let's think this one through: I type in wiejfiawefijwf, which doesn't decrypt properly. The site then throws an error, and since I don't have a site wide error handler, it exposes a whole bunch of information. Where's the security? The topic of this thread is securing cf apps. Although it may not be 100% necessary, it sure doesn't hurt. It doesn't help either. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Invoking CFCs
Is it possible to use a path (relative or physical) in the component property of the cfinvoke tag instead of dot notation? Cutter [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Securing CF Apps.
Another generalization is that the more complex security is, the harder it is to make sure there aren't any holes. IMHO, security should be blindingly simple.Only by doing that can you make sure you identify and test all the edge cases.You can stack layer upon layer of security, but each layer should be simple and independent. Not to say that it's always possible to keep is really simple, but the simpler the better in my book. Cheers, barneyb -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 9:49 AM To: CF-Talk Subject: Re: Securing CF Apps. no one ever claimed that security is simple. a generalization would be that the more complex security is, the harder it is to crack. -adam -Original Message- From: Tim Blair [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 05:19 PM To: 'CF-Talk' Subject: RE: Securing CF Apps. As for using the security of your DB instead of application- based security - in my opinion this is possibly *less* secure - it means that anyone with a login for your webapp automatically has a direct login for your database server! Which is of course set up to only allow connections from the web server, regardless of the credentials offered. Layer after layer after layer :-) And has no external network access except through the DMZ that the CF server is sitting in, behind the firewall that...Oh, no, I'll stop there I think.;) Tim. -- --- CF_CodingContest mode=judging newentries=false Maze Solver - http://tech.badpen.com/cfcontest/ --- RAWNET LTD - Internet, New Media and ebusiness Gurus. WE'VE MOVED - for our new address, please visit our website at http://www.rawnet.com/ or call us any time on 0800 294 24 24. --- This message may contain information which is legally privileged and/or confidential.If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
