Claude, querying via ODBC and JDBC is one of the sections I have in that resource list, so do check out the resources I list there. Hope you may find your answer. /charlie
_____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Claude Raiola Sent: Tuesday, January 15, 2008 8:56 PM To: [email protected] Subject: [cfaussie] using an ezxcel file as a datasource under cf8 Hi i am running the query under cf 5 connecting to the excel spreadsheet via the odbc connection and it all works fine however when i try and do the identical thing using the idential code under cf 8 i receive the following error message can anyone shed some light as to why cf 8 does not allow the table name as indicated below yet cf 5 it works like a treat Macromedia][SequeLink JDBC Driver][ODBC Socket][Microsoft][ODBC Excel Driver] 'Chall_data$' is not a valid name. Make sure that it does not include invalid characters or punctuation and that it is not too long. The error occurred in E:\Website\ManagerReports\ad_hoc_reports\chall_easydoc_retention_template.cf m: line 389 387 : 388 : <div align=center> 389 : <CFQUERY NAME="chall_retention" datasource="Chall_Ret_01_08"> 390 : select loanid, [borrower name] as borrower_name, BorRate, invstloanrate, feefreerate, bmm1, bmm2, sub, OtherFeeRate, load, Diff_Perc, SrvMarginAs_perc 391 : from "Chall_data$", "EasyDoc2_1$" Regards Claude Raiola B.Econ (Acc), B.Hot.Mngt. Websites: www.AustralianAccommodation.com www.SAMARIS.NET www.WebSiteSolutions.com.au Mobile: 0414 228 948 On Wed Jan 16 9:41 , 'Blair McKenzie' sent: Reminds me of the "orange" captcha Jeff Atwood uses on his blog - you have to type in orange to comment. That one absurd precaution apparently blocks 99.9% of his comment spam. Blair On Jan 16, 2008 12:04 PM, Taco Fleur <[EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Hi Simon, You're probably right, and where there is a will there is always a way. In this case, I do see this as a SIMPLE extra step to make life more difficult for people looking to do harm. Any script kiddy would probably not go through the hassle of getting around this fix. In which case I've done my job ;-) On 1/16/08, Simon Haddon <[EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Hi Taco, Your probably right about receiving the response back but, then again, once a tcp/ip connection is open then the ip address means nothing as a packet response on the same connection would not be effected by duplicate ip addresses. As for changing your IP address. Yes, you just set it in your network setting and maybe even tunneled through someone elses machine. This is all theory to me as I am no tin the habit of doing this sort of thing myself. The main thing to remember is that tcp/ip is not secure and can be intercepted in many ways if required. All tcp does is provide a reliable network over ip. Another method would be to use telnet even and send your own custom cgi parameters or write modify your own version of a browser to send the cgi parameters that you want. Wouldn't even need to modify your own IP address that way. I am sure there are plenty more examples that ppl in that field could give. When things are transmitted in clear text then you have to assume acceptance of a certain level of risk. The questions are probably along the lines of. How valuable is the persons data to someone else, how tempting is your server for hackers for other reasons (ie, other web sites). Cheers, Simon On 16/01/2008, Taco Fleur <[EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Hi Simon, Thanks for your feedback. Really, is IP faking the easiest thing to do? I'm not being sarcastic here, just that I've been doing lot's of research into security for the past years, and never come across something that would easily fake your IP, i.e. allowing you to make a request from IP 123.456.789.9 and make it looks like its 123.4.7.0 <http://123.4.7.0/> and still receive a response back on IP 123.456.789.9 I think, yes, you can fake an IP, but can't make a request from a fake IP and also receive a response back... Please correct me if I'm wrong. Very interested to hear more about this. Cheers. On 1/16/08, Simon Haddon < [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: IP Address faking is the easiest thing to do. The only thing that would be done is security by obscurity and sooner or later that would be worked out. You could say there are some very clever cookies out there trying to steal your information. I understand that you can set a cookie in SSL but what I was suggesting is that you don't refer to or use a cookie at all in SSL. Just use your cookie for normal transaction once logged in. Might not be possible cause you would probably have to change your cfapplication setting to switch from no cookie to a cookie on the fly and that might reset your session. Kinda gets complicated quickly when all you are trying to do is prevent the SecureScan message. Another way would be to have a separate application for signon that then passes information to your normal part of your web site with validated credentials. Just a thought Simon On 16/01/2008, Taco Fleur < [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: No, still looks sound to me ;-) Anyone see why this would not prevent a hacker stealing a cookie and using it? On 1/15/08, Taco Fleur < [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Just thought of something, and this might sound stupid when I wake up tomorrow.... 1. set a cookie cookie.securityHash = hash( cgi.remote_addr & application.seed ) 2. upon each request check compareNoCase( hash( cgi.remote_addr & application.seed ), cookie.securityHash ) neq 0 ------> cookie hijacked! hmmm... On 1/15/08, Taco Fleur < [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Thanks Simon, I realize its not unique to ColdFusion. But I had to mention it to stay on topic ;-) There are no transactions that we really need to worry about, we do need to worry about peoples' personal information etc. Not setting a cookie would just not work for us. Passing ids through the url really poses more of a security threat than using cookies. I'd like to get rid of the secure scan message if possible and do things better, but if not possible, then so be it ;-) BTW They're not complaining about setting the cookie under SSL, its the fact its not under SSL. On 1/15/08, Simon Haddon < [EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Interesting question. This is not a problem unique to ColdFusion. Any site that uses cookies are subject to this type of attack. In fact, cookies or not, when using html over clear text (non-ssl) then hackers can find a way of intercepting and interfering with the communications. One option is to not use cookies at all. Passing all session ids on the network and storing all user information on the server side. Even then , if you are not staying in a secure session, the connection between the client and server is vulnerable. The real questions are in relation to the importance (security wise) of your data, the importance of the clients and how safe the data needs to be. Look at the worse case scenario and work back from there. You really need to do a risk assessment against the type of transactions you want to perform in non-secure mode. If you are willing to let most of the traffic go via clear text then it probably isn't that important that someone will try to masquerade as another person. Under no circumstances should you have anything that hints towards username or password stored in the cookie if you decide to take that route. If all you are interested in doing is stopping the Securescan message then just don't set a cookie when in SSL and leave it till after. Cheers, Simon On 15/01/2008, Taco Fleur <[EMAIL PROTECTED] <javascript:top.opencompose('[EMAIL PROTECTED]','','','')> > wrote: Hello all, Got a question in relation to setting cookies in ColdFusion and session hijacking. We've just had our site scanned by ScanAlert (if interested, read more > http://australiansearchengine.wordpress.com/2008/01/14/a-secure-search-engin e-in-coldfusion/ <http://australiansearchengine.wordpress.com/2008/01/14/a-secure-search-engi ne-in-coldfusion/> ) and a couple of low alerts came up. One of them being about cookies, see below. Missing Secure Attribute in an Encrypted Session (SSL) Cookie The application sets a cookie over a secure channel without using the "secure" attribute. RFC states that if the cookie does not have the secure attribute assigned to it, then the cookie can be passed to the server by the client over non-secure channels (http). Using this attack, an attacker may be able to intercept this cookie, over the non-secure channel, and use it for a session hijacking attack. My question is; even if we would set the cookie over a secure channel, we would not put SSL over our whole site, because it would take up to much processing power. This would mean that once the user goes from SSL to normal HTTP, the cookie would be passed over a non-secure channel again. Am I missing something? How do I fix this, if at all? -- Looking for a business, product or service? Try the new Australian search engine www.clickfind.com.au <http://www.clickfind.com.au/> blog: http://australian-search-engine.blogspot.com/ -- Cheers Simon Haddon http://www.clickfind.com.au <http://www.clickfind.com.au/> Looking for a business, product or service? Try the new Australian search engine <http://www.clickfind.com.au/> www.clickfind.com.au <http://www.clickfind.com.au/> blog: <http://australian-search-engine.blogspot.com/> http://australian-search-engine.blogspot.com/ -- >>> <http://www.clickfind.com.au/> http://www.clickfind.com.au <http://www.clickfind.com.au/> Looking for a business, product or service? Try the new Australian search engine <http://www.clickfind.com.au/> www.clickfind.com.au <http://www.clickfind.com.au/> blog: <http://australian-search-engine.blogspot.com/> http://australian-search-engine.blogspot.com/ -- >>> <http://www.clickfind.com.au/> http://www.clickfind.com.au <http://www.clickfind.com.au/> Looking for a business, product or service? Try the new Australian search engine <http://www.clickfind.com.au/> www.clickfind.com.au <http://www.clickfind.com.au/> blog: <http://australian-search-engine.blogspot.com/> http://australian-search-engine.blogspot.com/ -- Cheers Simon Haddon http://www.clickfind.com.au <http://www.clickfind.com.au/> Looking for a business, product or service? Try the new Australian search engine <http://www.clickfind.com.au/> www.clickfind.com.au <http://www.clickfind.com.au/> blog: <http://australian-search-engine.blogspot.com/> http://australian-search-engine.blogspot.com/ -- Cheers Simon Haddon www.clickfind.com.au blog: http://australian-search-engine.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
