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]> 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 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]> 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]> 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] > 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] > 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] > 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] > 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-engine-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 > > > > > > > blog: http://australian-search-engine.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Cheers > > > > > > Simon Haddon > > > > > > 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 > > > > > > blog: > > > > > > <http://australian-search-engine.blogspot.com/>http://australian-search-engine.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > >>> <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 > > > > > blog: > > > > > <http://australian-search-engine.blogspot.com/>http://australian-search-engine.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > -- > > > > >>> <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 > > > > blog: > > > > <http://australian-search-engine.blogspot.com/>http://australian-search-engine.blogspot.com/ > > > > > > > > > > > > > > -- > > Cheers > > Simon Haddon > > 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 > > blog: <http://australian-search-engine.blogspot.com/> > > http://australian-search-engine.blogspot.com/ > > > > > > -- Cheers Simon Haddon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
