RE: How to protect against cookie stealing?

Mr. Dawes,

I agree with you regarding the XSS issues. The question that we all need to answer to is how critical is the content that we are trying to protect in the first place.  

If the website is a company private site that only needs to be accessed by customers, employees, and partners, and the integrity of the information is a top priority then using such thing as ActiveX is important at the time being. Of course there will always be the danger of a smart cracker sitting in the background eavesdropping and stealing sessions (haven't you known by now that there is no such thing as 100% secured). I believe that we as security professionals need to promote security up to its most extents while keeping other things in mind (such as privacy, Performance, and budget).

If someone needs to totally 100% protect the sessions of his/her website from crackers I advice him/her to shut it down.

Another thing, if we to eliminate things like proxy's that provide anonymity then we are destroying the only thing left out there to protect the privacy of the user. So we are left with no choice but to take the position of sitting ducks waiting to be hunted. Issues such as sessions and cookies will always raise a red flag. A new solution needs to take place; for example, using smart cards in the identification process when a user wants to buy something online (just like the Blue card from American Express). There will always be proxies, there will always be spoofers, and there will always be uber haxors, and no matter what we do, until we have the actual access control generated physically from the user station there will always be session hijacking.

Regards,

Tarek.
-----Original Message-----
From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes@deloitte.co.za] Sent: Friday, July 25, 2003 2:34 AM
To: '.:[ Death Star]:.'; 'Phil Cox'; webappsec@securityfocus.com Subject: RE: How to protect against cookie stealing?

Hi Death, :-)

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

The reason that one can't simply link the IP address to the session is that
there are ISP's, in particular AOL, that use cache arrays in a load balancing configuration. So a request that goes through one proxy could be
followed by one that goes through a different one.

Plus the fact that all users behind a single proxy would be seen to have the
same IP address.

A lot of people do not permit active content such as ActiveX objects, which
would be the only way to get the MAC address from the client. Besides which,
if the originating site can access this object through a script, so could
the attacker through an XSS, and supply that information to the attacker at
the same time as the sessionid.

I think this is the reason that nothing has been done about this problem:

• If the attacker can't XSS the user, they can't get the sessionid (unless it is predictable, which is just stupid!), hence there is no problem.
• If the attacker CAN XSS the user, then they can also get whatever other information that they need to impersonate the user, except for the IP address, which unfortunately, we can't rely on anyway, so we CAN'T do anything about the problem.

Rogan

> -----Original Message-----

Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") that must be accessed and read by clicking here or by copying and pasting the following address into your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre@Deloitte.co.za. Received on Sun Jul 27 11:48:09 2003