Eating Cookies...not So Bad for Your PC Health

Cookies Explained

A cookie is a small internet-mediated capsule of information if you like, which is downloaded by your machine and read by the remote computer during your session on their web site, or upon your next visit.

A cookie is just a small text file really, with a unique user ID, a small amount of related information and reference to the host website. Cookies can only be held on one or two file locations ( eg temporary internet files) and can only be short files conforming to a set syntax ( layout) , and this security step is managed by your browser.

The cookie session ID is a number usually a simple, long integer, which allows for continuity in a single session between the little http handshakes which go on between activities, or an ID which can be referred to between visits to the web site. The ID number relates your session or log-in to information stored on the server (remote computer).


Cookies can be used between visits, aka "permanent cookies": The cookie can include username for example as well as the UID and cookie host name. One security issue here we will come back to is that this can auto-populate fields with user names and if you specify, password, with these words being held on your computer in the cookie. A time "print" from the server clock and an expiry date can be set as well in the cookie. The default expiry is when you exit your browser, and in fact the usual browsers- IE, Firefox, Safari and Chrome- allow you to set "delete all cookies" when you close the programme.


Security Issues and Cookies

When you ask facebook or hotmail to "remember me on this machine" this is what it does, via the cookie, so it is important that you don't do this on public computers and best not to if asked while using a public WiFi with your laptop.

Some cookies will contain user name and password, verbatim, for autocompleting forms or for an auto log in, and this is really very bad security. The majority use a UID alone luckily and this will be part of a site getting SSL certification to use https.

Also with further due diligence to your own personal security you must not use your user names and passwords from more important accounts, like your online bank or Paypal/Amazon etc, or the e-mail account itself, on less important log in's. This is when you can save these in the tick box option so don't get the site to save these: they may be just left, completely readable on a cookie! Or site server may not be secure or you may be intercepted by a session hijack in a public Wifi hot spot or LAN at school/the office.



Many people consider this a breach of privacy or potential security: this would only be so if the server hosting say Amazon, was hacked and your ID number associated to your credit card for example. However some spyware ( an executable you inadvertedly download or get form an infected disk/stick) may look at cookies to examine where you have been, and determine what content to serve up to you dependent on your cookie host names.

Cookies can only be held on one file location and can only be short files, and this security step is managed by your browser. Also, due to the cross site policy installed in all good browsers, other web sites do not have permission to access the cookie, but as for example in google-ads / doubleclick.com, a cookie can be requested from them and used to record your surfing behaviour while on those first party sites: this is called a third party cookie, and you should be able to block this happening: it just creates a lot more http requests which can be slow and then you will be served up "relevant" ad's when you go to G-mail: this is how they know, Google pay for access to other web sites so they can send these cookies.


PHP_session_IDs is the small identifier which could be picked up on a public network and a hijacking cookie written. This is why for any sensitive info, an https/SSL session should be used.

Secrutiy concerns are valid, but the use of cookies is not risky. Rather the opposite : the UID is so long and only temporary to the session, so it is very unlikely that a hacker would be able to guess or pre-empt it, or copy it. Even if they had some nasty spy ware or control ware, or as "session hijack" or a middle-man-attack over your machine in an internet WiFi cafe say, it would probably be obvious there was somethign wrong with your session and you should log out switch off your internet connection immediately.

In the most common language these days, PHP, cookies are sent from the server when the php file has a 'session_start' command at the top. The client's browser then replies to confirm it has saved the cookie.


'Session' Explained

A session is actually a description of capturing data for a user on the server side in a file. It is rightly called session because it helps continuity between http based requests and handshakes while the user is still using the web site. Good examples are in internet shops, when the session holds information on your progress through the buying process.

Using POST and GET for Submitting Data from Browser Side Web Pages
Post sends a hidden data capsule, which has a defined legnth of characters: so it is best for password/username submission in simple non https/SSL set ups or some transaction data in internet shops.

Data submitted from websites in html and xhtml are refered to as forms, like name and address lines, and this also applies to radiobuttons, check boxes and hidden letter log in fields.
GET sends the request in a URL, which has the benefit that you can have very long and very variable content for the "string" or form data. Browsers have an encoding routine which takes the string from the field in the form and converts it to a URL, and this incidentally eliminates conflicting characters like ampers And "&", "=" and "!" , and encodes them to their ASCII hexadecimal codes. This also has a security implication in other POST and URL constructs, whereby a hacker may get unauthorised access to a database which is not covered by the browser tidy on form submission/Get/Post operations.

Cookie data, like username, can be requested before opting to allow just a "post " ie field populates or user UID session is referred to.


Summary On Issues With Cookies

Cookies are actually a quite secure set of information files. Firstly in that the browser only allows them to live in one or two places, and they must be small and confrom to the right syntax. Also serious programmers will only ever store a user session ID number and not embedd user name or worse, the password information in the cookie.

Taking these two together, then the system is way more secure than the weak external link: homo sapien Mrk1. Also because cookies establish a long UID number, and to some extent manage the user session via this, the continuity in identity makes this a security feature both in and outside SSL (https) connections.

A third party would have to attain this number from the cookie in transit, to be able to hijack the session: if we relied on IP addresses for UID, then it would be possible for someone to mimmick your session and run a parallel attack. Also network administrators and ISPs would have to (c) 2011 Authors appoint proper IP addresses to all users, visible to the internet sites and nodes outside their routers.

The next layer of security is the cross-site-policy: once again in the browser, it will not allow other sites or owners to see your cookies from other web pages: the loophole in this is that if one web site incorporates a cookie which comes from another owner, like Google Analytics or DoubleClick.com, then that site can get information about your browsing across different domains and then serve you ad's in your Gmail or other sites they own or have a permitted prescence on.

Currently there has been little evidence I have seen on the web, that 3rd party cookies do anything else but intrude on your privacy a little, and lead to 'personalised' banner ad' serving based on your surfing habits. However, if you visit sites in countries with poor DNS policing, then a third party may be able to fake being some other site and run a middle man con based on knowing there was continuity in the user: ie you are still on the computer with the cookie and they know a little bit about you, even if it is just you have been on an unsavoury or inadvisable web site: that could be enough for a blackmail attempt for example.

Internet Explorer v 8 ( IE8) does allow for blocking of third party cookies, in the advanced panel in privacy window in internet settings. Earlier firefoxes had this included, now you will need cookie monster as a plug in to selectively stop this automatically.

So essentially, cookie use is more secure than your own human error, ignorance or gullability. If you must use a public machine or a machine on a public network ( include hot-desking at work in this!) , then it can be worth to do the folowing :

a) request warning and approval for cookies to be accepted in internet options, privacy settings ( advanced) ; there by will you know how many cookies are coming and what their sources actually are.

b) do not check the box "remember me on this computer" and especially do not check the box for "remember my password"

c) ensure your delete all cookies in internet options in the browser and then close the browser down when you walk away.

d) use a wholly different, unique user name and password for different web sites:

I recommend having a second "light security" use e-maill account in a non guessable pseudonym: freddampy@geewhizmail for example, because so many sites stipulate e-mail as login/user name. For this and your primary hot/gmal log in, use long and strong passwords. This has become more of an issue for escalation of a potential identity theft now that youtube, gmail and blogger have a common Gmail log in, and with Facebook Shares, other sites could just rip off your FB log in: thus if someone learns your log in they can grab more inforamtion on you, like address etc, and if you are worth stealing identify from. ie high credit rating.

Use an unrelated user name and password for banking and shopping, and if your bank or account version do not include a digital token pendant, then opt over to one that does.

(c) 2011 Authors

Sources: Prof D Malan, Harvard, E75 course on Dynamic Web Sites
Mozilla Corp. Inc User Help Web Site