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: 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: 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: 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: 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: 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: RE: Securing CF Apps.
Why would you ever do this? BTW, are you ever going to change the admin password from admin? - Original Message - From: Tony Weeg [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 10:52 am Subject: 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 [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 [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 [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, outputand 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:Sec
RE: RE: Securing CF Apps.
BTW, are you ever going to change the admin password from admin? Now that is going a little too far! Don't you think you should have done that OFF LIST? Paul [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? Also should someone gain access to your file system they can build a pretty complete picture of your database from the queries. You can't do this when all you are using is Stored Procedures, especially if your variable names don't match your column names.Throw in views and you can obscure it even more. You've got bigger problems should someone gain access to your file system. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked. Listen man.You do whatever you feel comfortable doing.No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around your application and it's data.Obscurity is just one more tool you can use to do that. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:16 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
It is a positive sign when so many people on this list recognize the need for security in their web applications. The next step after acknowledging that security is needed is to determine how much security is needed. We don't want to protect 10c of assets using security worth $1000. Once we know how much we can spend on securing our assets we proceed to security planning. In cf talk discussion thus we should look at easy and cheap to implement security vis more expensive security implementations. After all, if we have unlimited budget we could do something silly like hiring someone to watch every request our website is about to process. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:12 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. 1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? Also should someone gain access to your file system they can build a pretty complete picture of your database from the queries. You can't do this when all you are using is Stored Procedures, especially if your variable names don't match your column names.Throw in views and you can obscure it even more. You've got bigger problems should someone gain access to your file system. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
Tim, Nice writeups.. I'm glad I brought the topic up this morning because a lot of good avice and insght has been given. Everyone does it differently and all we can do is improve on what we thought secure was yesterday. Mike 1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation. If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked. Listen man.You do whatever you feel comfortable doing.No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around your application and it's data.Obscurity is just one more tool you can use to do that. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
There are very specific equations that can help you decide how much you need to spend on risk mitigation and security.Unfortunately most web developers don't know where to look for information like this.Also doing a large scale risk analysis can be expensive and time consuming, enough that it will be skipped by people that do know how to conduct one correctly. The things that we have talked about thus far are all easy to implement, and free.You are using the security that is part of your database, and using the security that you yourself build into your application.The encryption stuff I wrote is freely available on cflib.org (all though I do need to update it).Documentation on best practices is all over the net.Open up google and look for web application security, or something similar.You can get quite an education for free these days, I know I have. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:39 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. It is a positive sign when so many people on this list recognize the need for security in their web applications. The next step after acknowledging that security is needed is to determine how much security is needed. We don't want to protect 10c of assets using security worth $1000. Once we know how much we can spend on securing our assets we proceed to security planning. In cf talk discussion thus we should look at easy and cheap to implement security vis more expensive security implementations. After all, if we have unlimited budget we could do something silly like hiring someone to watch every request our website is about to process. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:12 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. 1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? Also should someone gain access to your file system they can build a pretty complete picture of your database from the queries. You can't do this when all you are using is Stored Procedures, especially if your variable names don't match your column names.Throw in views and you can obscure it even more. You've got bigger problems should someone gain access to your file system. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: RE: Securing CF Apps.
If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
I am not sure about security discussed here as all being free. After all, your extra time spend programming is probably valuable to you. Thus there is cost involved, through hidden (you don't actually fork cash out, you spend more time programming). For example, it takes a bit more time to use cfqueryparam than not to use it. I agree that detailed analysis is in most situations out of the question, however developer can still do some quick common sense analysis of his security needs. By this I mean he/she can opt out of more advanced security if system carries relatively unimportant data. Or, on the other hand, use every security tool available if working on a financial data manipulation application for a large bank. TK -Original Message- From: Heald, Tim [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:42 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. There are very specific equations that can help you decide how much you need to spend on risk mitigation and security.Unfortunately most web developers don't know where to look for information like this.Also doing a large scale risk analysis can be expensive and time consuming, enough that it will be skipped by people that do know how to conduct one correctly. The things that we have talked about thus far are all easy to implement, and free.You are using the security that is part of your database, and using the security that you yourself build into your application.The encryption stuff I wrote is freely available on cflib.org (all though I do need to update it).Documentation on best practices is all over the net.Open up google and look for web application security, or something similar.You can get quite an education for free these days, I know I have. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:39 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. It is a positive sign when so many people on this list recognize the need for security in their web applications. The next step after acknowledging that security is needed is to determine how much security is needed. We don't want to protect 10c of assets using security worth $1000. Once we know how much we can spend on securing our assets we proceed to security planning. In cf talk discussion thus we should look at easy and cheap to implement security vis more expensive security implementations. After all, if we have unlimited budget we could do something silly like hiring someone to watch every request our website is about to process. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:12 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. 1. If your properly encrypting the url your going to change your seed (key) every request.That way it is different every time What possible value does this bring? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? Also should someone gain access to your file system they can build a pretty complete picture of your database from the queries. You can't do this when all you are using is Stored Procedures, especially if your variable names don't match your column names.Throw in views and you can obscure it even more. You've got bigger problems should someone gain access to your file system. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
I agree with Kwang Suh, security through obscurity is no security at all. This is quite well known throughout security community and all encryption standards available to the wide public adhere to it. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:56 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
Obscuring an encryption method is different form hiding the architecture or structure of your application. The open source community likes to make the point that security through obscurity doesn't work.Just because someone says it doesn't make it true. the methods I use to secure my site are open.hell you can go download the udf I use to do url encryption right now to see how I do it.You can even crack it if you take the time.It's a seed bump.Just like you have to decide how much time and money your going to put into securing your application or site, so does the intruder have to decide to go after you or another weaker site. Also not all encryption standards are widely available.As a matter of fact in some instances it is illegal to let people know the detail of high level encryption algorithms. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:18 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. I agree with Kwang Suh, security through obscurity is no security at all. This is quite well known throughout security community and all encryption standards available to the wide public adhere to it. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:56 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system
Re: RE: RE: Securing CF Apps.
You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 07:55 PM To: 'CF-Talk' Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: RE: Securing CF Apps.
If thats the case, then whats the big deal with the MS code leak? -adam -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 08:08 PM To: 'CF-Talk' Subject: RE: RE: RE: Securing CF Apps. I agree with Kwang Suh, security through obscurity is no security at all. This is quite well known throughout security community and all encryption standards available to the wide public adhere to it. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:56 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: RE: Securing CF Apps.
I'd say something like Amazon.com is an application, and boy, would I ever hate it if I couldn't bookmark a link to a book.Or their wish lists.That's not a site. Some parts of an application can be public facing, you know. How about Web Services?Are those an application?Well, I can sure tell you they're not a site.Should I be obfuscating those links too?That sure would suck. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 1:43 pm Subject: Re:RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 07:55 PM To: 'CF-Talk' Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription
RE: RE: RE: Securing CF Apps.
In what way does a bookmark make an application less secure? Wouldn't you consider it a good idea to bookmark an application if it means the user uses the application more? If a bookmark allows a person to access a secure section, it should ask them for their credentials, if valid, it should let them access it. If the bookmark allows them to bypass the security, then the application isn't secure. Steve Nelson -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:43 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
MS code leak illustrates my point very well. MS OS is not more secure than say Linux because it source code is not available to the public. Hmm, I think Linux vis MS security was already mentioned on this list in the past few months. TK -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:47 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If thats the case, then whats the big deal with the MS code leak? -adam -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 08:08 PM To: 'CF-Talk' Subject: RE: RE: RE: Securing CF Apps. I agree with Kwang Suh, security through obscurity is no security at all. This is quite well known throughout security community and all encryption standards available to the wide public adhere to it. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:56 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have prevented from putting your system at risk. (slammer, blaster etc.)By duplication of your efforts, by overlapping your protection you're trying to create a shell around yourapplication and it's data. If what you're building is that important to secure, I recommend that you never ever make it available on the public internet. Obscurity is just one more tool you can use to do that. I used to work with a security/cryptology expert.His #1 rule: Never, ever use obfuscation. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
There are different controls that you would use for different purposes. Obviously an ecommerce SITE (which is what Amazon is) needs users to be able to return to a specific product. Web services security is very different from either public site or application security.You're comparing apples and oranges. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:54 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. I'd say something like Amazon.com is an application, and boy, would I ever hate it if I couldn't bookmark a link to a book.Or their wish lists. That's not a site. Some parts of an application can be public facing, you know. How about Web Services?Are those an application?Well, I can sure tell you they're not a site.Should I be obfuscating those links too?That sure would suck. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 1:43 pm Subject: Re:RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 07:55 PM To: 'CF-Talk' Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell
RE: RE: RE: Securing CF Apps.
I don't like giving the user browser controls even.Which is why I tend to pop my apps in a new window with no controls (back forward and so on).Why? I have business rules that I want them to have to follow.I want them to follow a specific process for accessing and entering information. Also as the proponent of team based development you should know that not everyone meets the same standards.I know that if I require my developers to encrypt urls that even if they forget something else, like checking a role, it will get caught, because the user cannot randomly access different parts of the application. Someone earlier said it was useless to limit sql execution in the administrator. Well what if your dba or dbd forgot to only give specific grants?I know were talking about duplication of efforts to a certain extent, however I think that you end up making your application more secure. Like I said I only want to give the user the choices I provide them with, no more, no less. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Steve Nelson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:58 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. In what way does a bookmark make an application less secure? Wouldn't you consider it a good idea to bookmark an application if it means the user uses the application more? If a bookmark allows a person to access a secure section, it should ask them for their credentials, if valid, it should let them access it. If the bookmark allows them to bypass the security, then the application isn't secure. Steve Nelson -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:43 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
What is funny to me is that the number of Linux vulnerabilities far surpasses the number of M$ ones.Look into it.It's just that M$ products are more commonly used, and therefore more commonly attacked. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:59 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. MS code leak illustrates my point very well. MS OS is not more secure than say Linux because it source code is not available to the public. Hmm, I think Linux vis MS security was already mentioned on this list in the past few months. TK -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:47 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If thats the case, then whats the big deal with the MS code leak? -adam -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 08:08 PM To: 'CF-Talk' Subject: RE: RE: RE: Securing CF Apps. I agree with Kwang Suh, security through obscurity is no security at all. This is quite well known throughout security community and all encryption standards available to the wide public adhere to it. TK -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 2:56 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal CERT, I can tell you this, there is always going to be some new exploit. It's going to be something you didn't think of.But that zero day exploit isn't going to be the one that does all the crazy damage.It's going to be some known vulnerability that you could have
RE: RE: RE: Securing CF Apps.
Amazon.com is primarily a web site, the backend where the staff manages everything is an application.Web sites let anonymous users browse content, while web applications let authenticated users perform actions that affect other users/visitors. The only part of amazon.com that is an application (of the stuff you can see) is the checkout process, and you can't bookmark one of those pages. Well, you can, but when you come back, you'll get a message that says you need to start over or something like that, with a link back to the web site portion. Cheers, barneyb -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:51 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. I'd say something like Amazon.com is an application, and boy, would I ever hate it if I couldn't bookmark a link to a book. Or their wish lists.That's not a site. Some parts of an application can be public facing, you know. How about Web Services?Are those an application?Well, I can sure tell you they're not a site.Should I be obfuscating those links too?That sure would suck. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 1:43 pm Subject: Re:RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 07:55 PM To: 'CF-Talk' Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfland the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted.There is the risk of SQL injection if your not doing the correct validation.If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web server they have nothing.Now my db which is on the other side of a firewall, and only accepts connections from specific ips, if they got in that it could become problematic.Why?Because there are no user names or passwords stored on my web server.There is no way to open a direct connection into my db without having a user account on the db.Your rights and roles are also stored in that db, not in the application, and so you would not really get anything other than images and source code.You don't even get the code of the procedure calls, and so you are still blind to the schema of my db. If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password.Or I could simply delete everything on the web server. Kwang, again, this is a layered approach to security.No one thing is going to protect you from everything.You just continue to lock down things in order to mitigate risk.You can never be without risk, and anyone who thinks they have completely secured their site deserves to be attacked.Listen man.You do whatever you feel comfortable doing. No more, no less. But moving towards my CISSP and GSEC, having been a cyber threat analyst for the last two years, and soon to be managing a federal
Re: RE: RE: Securing CF Apps.
How many non web applications have bookmarks? Just because its there doesnt mean it's useful. Websites yes. Applications... pointless. Furthermore you never know what page they are going to bookmark... what if they bookmark a page that required a form submission? If you have a user wanting to bookmark your application's internal pages, then you should revist usability. -adam -Original Message- From: Steve Nelson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 08:56 PM To: 'CF-Talk' Subject: RE: RE: RE: Securing CF Apps. In what way does a bookmark make an application less secure? Wouldn't you consider it a good idea to bookmark an application if it means the user uses the application more? If a bookmark allows a person to access a secure section, it should ask them for their credentials, if valid, it should let them access it. If the bookmark allows them to bypass the security, then the application isn't secure. Steve Nelson -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:43 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
I used to work with a security/cryptology expert. His #1 rule: Never, ever use obfuscation. While I wouldn't categorize myself as a security expert, much less a cryptologist, I would disagree with this. At the very least, I'd amend it to Never, ever use obfuscation as your sole method of security. There is nothing wrong with security through obscurity, as long as you don't rely on it as your only protection. I would draw an analogy between computer security and getting shot at. When you're being shot at, there are two sorts of protection you might resort to. You might take cover by getting behind a solid object that can block fire. You might conceal yourself behind something that would obscure you as a target. When you're getting shot at, cover and concealment are both useful; concealment won't stop a bullet, but it'll lessen the likelihood of people shooting in your direction. Ideally, you want both cover and concealment, of course, if for no other reason than to avoid the stress of being shot at. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
What is funny to me is that the number of Linux vulnerabilities far surpasses the number of M$ ones.Look into it.It's just that M$ products are more commonly used, and therefore more commonly attacked. Hmmm, but isn't the number of possible subsystems in Linux far greater than that of Windows? (I know I read that somewhere, but can't remember where. Perhaps somebody can confirm/reject this.) You need to look at the *percentage* of vulnerabilities in each OS before making that statement. If Windows only has 25 vulnerabilities in 75 subsystems, and Linux has 30 vulnerabilities in 150 subsystems, Windows has the greater *percentage* of vulnerabilities, thus making it the more vulnerable OS. Also, while I'm sure the greater use statement holds some merit, it's not that black and white either. If you lurk around the Linux world, you'll see that hackers/programmers are constantly trying to break into each others' systems, Linux included. Heck, there's even formal contests set up to do this. Linux is just as attacked as Windows I would wager, but you only hear about the Windows attacks in the news because of the number of people a vulnerability might effect. Regards, Dave. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: RE: Securing CF Apps.
nice analogy Dave...that is it to a T !! 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: Dave Watts To: CF-Talk Sent: Tuesday, March 23, 2004 1:24 PM Subject: RE: RE: RE: Securing CF Apps. I used to work with a security/cryptology expert. His #1 rule: Never, ever use obfuscation. While I wouldn't categorize myself as a security expert, much less a cryptologist, I would disagree with this. At the very least, I'd amend it to Never, ever use obfuscation as your sole method of security. There is nothing wrong with security through obscurity, as long as you don't rely on it as your only protection. I would draw an analogy between computer security and getting shot at. When you're being shot at, there are two sorts of protection you might resort to. You might take cover by getting behind a solid object that can block fire. You might conceal yourself behind something that would obscure you as a target. When you're getting shot at, cover and concealment are both useful; concealment won't stop a bullet, but it'll lessen the likelihood of people shooting in your direction. Ideally, you want both cover and concealment, of course, if for no other reason than to avoid the stress of being shot at. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
In my opinion most of the time when one sees or writes about the luck of security in obfuscation one refers to a situation where obfuscation is the sole security measure in an environment that requires some hard core security. Bottom line is, obfuscation provides some limited security and is not recommended as the sole security measure in say a bank. Also one can start a new thread about different methods ofobfuscation and their respective benefits in security context. I think application security should be loosely defined as a method of making it difficult for the attacker to get information that is secured by it. How difficult (resource wise) do you want to make it for the attacker is up to you. Obfuscation alone might just not make it difficult enough for the attacker to get to your sensitive data in some cases. TK [Tom Kitta]-Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 4:24 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. I used to work with a security/cryptology expert. His #1 rule: Never, ever use obfuscation. While I wouldn't categorize myself as a security expert, much less a cryptologist, I would disagree with this. At the very least, I'd amend it to Never, ever use obfuscation as your sole method of security. There is nothing wrong with security through obscurity, as long as you don't rely on it as your only protection. I would draw an analogy between computer security and getting shot at. When you're being shot at, there are two sorts of protection you might resort to. You might take cover by getting behind a solid object that can block fire. You might conceal yourself behind something that would obscure you as a target. When you're getting shot at, cover and concealment are both useful; concealment won't stop a bullet, but it'll lessen the likelihood of people shooting in your direction. Ideally, you want both cover and concealment, of course, if for no other reason than to avoid the stress of being shot at. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
As far as I know, in the Linux hacker community cracking Linux box of your enemy hacker is far more worthy of a prize than hacking some MS box of some inexperienced user. Anyway, I think this is getting off topic now, lets go back to CF application security exclusively. TK -Original Message- From: Dave Carabetta [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 4:38 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. What is funny to me is that the number of Linux vulnerabilities far surpasses the number of M$ ones.Look into it.It's just that M$ products are more commonly used, and therefore more commonly attacked. Hmmm, but isn't the number of possible subsystems in Linux far greater than that of Windows? (I know I read that somewhere, but can't remember where. Perhaps somebody can confirm/reject this.) You need to look at the *percentage* of vulnerabilities in each OS before making that statement. If Windows only has 25 vulnerabilities in 75 subsystems, and Linux has 30 vulnerabilities in 150 subsystems, Windows has the greater *percentage* of vulnerabilities, thus making it the more vulnerable OS. Also, while I'm sure the greater use statement holds some merit, it's not that black and white either. If you lurk around the Linux world, you'll see that hackers/programmers are constantly trying to break into each others' systems, Linux included. Heck, there's even formal contests set up to do this. Linux is just as attacked as Windows I would wager, but you only hear about the Windows attacks in the news because of the number of people a vulnerability might effect. Regards, Dave. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: RE: Securing CF Apps.
Precisely my point. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 4:36 PM To: CF-Talk Subject: RE: RE: RE: Securing CF Apps. I used to work with a security/cryptology expert. His #1 rule: Never, ever use obfuscation. While I wouldn't categorize myself as a security expert, much less a cryptologist, I would disagree with this. At the very least, I'd amend it to Never, ever use obfuscation as your sole method of security. There is nothing wrong with security through obscurity, as long as you don't rely on it as your only protection. I would draw an analogy between computer security and getting shot at. When you're being shot at, there are two sorts of protection you might resort to. You might take cover by getting behind a solid object that can block fire. You might conceal yourself behind something that would obscure you as a target. When you're getting shot at, cover and concealment are both useful; concealment won't stop a bullet, but it'll lessen the likelihood of people shooting in your direction. Ideally, you want both cover and concealment, of course, if for no other reason than to avoid the stress of being shot at. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
Putting in a review is not an action? Picking items from the gold box is not an action? - Original Message - From: Barney Boisvert [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 3:02 pm Subject: RE: Securing CF Apps. But the point is that you're still browsing content, you're not performingany actions.At least in my mind, that's really what differentiates a site from an application.Amazon is definitely very complex, but it's still a web site in my book, at least until you get to the checkout phase. Cheers, barneyb -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 1:31 PM To: CF-Talk Subject: RE: Securing CF Apps. How about the wish lists, recommendations, gold box, trivia, product ratings, product reviews, etc? I'd say that's an application.Just because I don't have to go through some authentication process doesn't mean I'm browsing a site. - Original Message - From: Barney Boisvert [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 2:05 pm Subject: RE: RE: RE: Securing CF Apps. Amazon.com is primarily a web site, the backend where the staff manageseverything is an application.Web sites let anonymous users browse content, while web applications let authenticated users perform actions that affect other users/visitors. The only part of amazon.com that is an application (of the stuff you can see) is the checkout process, and you can't bookmark one of those pages.Well, you can, but when you come back, you'll get a message that says you need to start over or something like that, with a link back to the web site portion. Cheers, barneyb -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:51 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. I'd say something like Amazon.com is an application, and boy, would I ever hate it if I couldn't bookmark a link to a book. Or their wish lists.That's not a site. Some parts of an application can be public facing, you know. How about Web Services?Are those an application?Well, I can sure tell you they're not a site.Should I be obfuscating those links too?That sure would suck. - Original Message - From: Adrocknaphobia [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 1:43 pm Subject: Re:RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 07:55 PM To: 'CF-Talk' Subject: Re: RE: RE: Securing CF Apps. If my user.login is encrypted one time as kjdfljsldfl and the user comes back and types in kjdfljsldfl they don't get taken to that circuit, because it's different this time. This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless. 3. The objection to using cfquery is multifaceted. There is the risk of SQL injection if your not doing the correct validation. If your errors are not being handled correctly you can give away table and column names in the error message. So don't you think it's more important to handle errors properly than say don't ever use cfquery? I think that with all the benefits of procedures, if you have them available, you're a fool not to use them, and not just because of the enhanced security.Obviously proper error handling is important AS WELL. This is not an either/or argument, rather a complimentary one. What's wrong with: cfquery exec my_stored_proc /cfquery ? 2. By using plain text variable names your going to give the potential intruder a decent insight into your application design, and this will give them the ability to make educated guesses as to your other circuit names. So? So by understanding the structure of an application, you can then begin to analyze it's weaknesses.In the environment in which I work we want to give them as little as possible to go on. You've got bigger problems should someone gain access to your file system. Is that so??I disagree.If someone gains access to my web
RE: RE: RE: Securing CF Apps.
Difficult, yes, pointless, no way! It is difficult to do because by bookmarking a url they *may* leave out form information, or they don't have client/session/cookie/etc variables available. But the end user doesn't care that you consider it an application vs a site. Problems as a programmer are not the same as problems for the end user. The end user wants to jump back to some page quickly. Creating a way to force them to relogin if they have timed out or sending them back to a form if they're missing form variables are problems that are not *too* difficult to solve. My point is that bookmarks don't make an application less secure. How would you differentiate a site and an application? Would you consider an application one that allows the user to type stuff into a form? Steve -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 4:06 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. How many non web applications have bookmarks? Just because its there doesnt mean it's useful. Websites yes. Applications... pointless. Furthermore you never know what page they are going to bookmark... what if they bookmark a page that required a form submission? If you have a user wanting to bookmark your application's internal pages, then you should revist usability. -adam -Original Message- From: Steve Nelson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 08:56 PM To: 'CF-Talk' Subject: RE: RE: RE: Securing CF Apps. In what way does a bookmark make an application less secure? Wouldn't you consider it a good idea to bookmark an application if it means the user uses the application more? If a bookmark allows a person to access a secure section, it should ask them for their credentials, if valid, it should let them access it. If the bookmark allows them to bypass the security, then the application isn't secure. Steve Nelson -Original Message- From: Adrocknaphobia [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 3:43 PM To: CF-Talk Subject: Re: RE: RE: Securing CF Apps. You do realize we are talking about applications and not websites. There is a big difference, and I've never once found it a good idea for a user to bookmark a part of application. -adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
What a weak argument.Prove to me that is the definition of a web site. - Original Message - From: Heald, Tim [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 3:38 pm Subject: RE: Securing CF Apps. I think something used to either sell products on the web, or provide information on the web is a site.Now the site might be controlled by a back end content management system, or some sort of inventory application,but the rest of it is a web site. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: RE: Securing CF Apps.
Precisely why I don't agree with pretty much everything you've stated today. - Original Message - From: Heald, Tim [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 4:28 pm Subject: RE: Securing CF Apps. Why do I need someone to agree with me?I have my own mind.I can asses the objective reality of whether I feel something is useful to me. You should check out some Ayn Rand some time. -- Timothy Heald Web Portfolio Manager Overseas Security Advisory Council U.S. Department of State 571.345.2319 The opinions expressed here do not necessarily reflect those of the U.S. Department of State or any affiliated organization(s).Nor have these opinions been approved or sanctioned by these organizations. This e-mail is unclassified based on the definitions in E.O. 12958. -Original Message- From: Kwang Suh [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 6:28 PM To: CF-Talk Subject: Re: Securing CF Apps. This is precisely why my security co-worker was so adament against obfuscation: absolutely no one can agree on its usage and usefulness. - Original Message - From: Jochem van Dieten [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 2:53 pm Subject: Re: Securing CF Apps. Dave Watts wrote: I used to work with a security/cryptology expert. His #1 rule: Never, ever use obfuscation. While I wouldn't categorize myself as a security expert, much less a cryptologist, I would disagree with this. At the very least, I'd amend it to Never, ever use obfuscation as your sole method of security. I would amend it differently: Never, ever use obfuscation if it adds complexity for yourself. There is nothing wrong with security through obscurity, as long as you don't rely on it as your only protection. I would draw an analogy between computer security and getting shot at. When you're being shot at, there are two sorts of protection you might resort to. You might take cover by getting behind a solid object that can block fire. You might conceal yourself behind something that would obscure you as a target. When you're getting shot at, cover and concealment are both useful; concealment won't stop a bullet, but it'll lessen the likelihood of people shooting in your direction. Ideally, you want both cover and concealment, of course, if for no other reason than to avoid the stress of being shot at. Unless you have cover by an object that will stop the small arms fire from the other side, but at the same time so well concealed your side doesn't see you and you die from 'friendly' fire when your side bombs the opponent. Obfuscation can hurt the obfuscator, just like a firewall can introduce a risk to an otherwise well protected computer. 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: RE: Securing CF Apps.
May I point out that definitions cannot be proven, they are just statements that we use in proofs. A good definition captures the concept that it is defining well, bad one does not. Bottom line is you can define web site as pigs that fly and it will be a valid definition. In fact I think that even today (or at least 2 years ago) the question of 0 (zero) being a Natural number or not was not uniformly accepted. Different professors used different definitions, which is OK (however I sure hope one day they will go one way or the other). I am in the camp that says 0 is Natural. For me having no money is a natural state :) TK [Tom Kitta] -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 7:13 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. What a weak argument.Prove to me that is the definition of a web site. - Original Message - From: Heald, Tim [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 3:38 pm Subject: RE: Securing CF Apps. I think something used to either sell products on the web, or provide information on the web is a site.Now the site might be controlled by a back end content management system, or some sort of inventory application,but the rest of it is a web site. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: RE: Securing CF Apps.
I for one do not believe in creating definitions out of thin air to suit a particular argument, as was done here. -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: March 23, 2004 8:04 PM To: CF-Talk Subject: RE: RE: Securing CF Apps. May I point out that definitions cannot be proven, they are just statements that we use in proofs. A good definition captures the concept that it is defining well, bad one does not. Bottom line is you can define web site as pigs that fly and it will be a valid definition. In fact I think that even today (or at least 2 years ago) the question of 0 (zero) being a Natural number or not was not uniformly accepted. Different professors used different definitions, which is OK (however I sure hope one day they will go one way or the other). I am in the camp that says 0 is Natural. For me having no money is a natural state :) TK [Tom Kitta] -Original Message- From: Kwang Suh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 7:13 PM To: CF-Talk Subject: Re: RE: Securing CF Apps. What a weak argument.Prove to me that is the definition of a web site. - Original Message - From: Heald, Tim [EMAIL PROTECTED] Date: Tuesday, March 23, 2004 3:38 pm Subject: RE: Securing CF Apps. I think something used to either sell products on the web, or provide information on the web is a site.Now the site might be controlled by a back end content management system, or some sort of inventory application,but the rest of it is a web site. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
