[Gllug] Sticky cookies

Simon Wilcox essuu at ourshack.com
Fri Aug 15 10:39:39 UTC 2008

Chris Bell wrote:
> On Fri 15 Aug, Simon Wilcox wrote:
>> Chris Bell wrote:
>>>    I impose a general "no cookies" rule for best security, but a
>>> neighbourhood site isists on using them. I am considering setting up a
>>> dedicated account that will allow a cookie on another local box so that the
>>> cookie is confined to that account. Would this still work if I then access
>>> that account through a window on another box using ssh/screen remote access?
>> Cookies are just bits of text. The only threat from cookies is that they 
>> may be used to track your browsing behaviour (c.f. doubleclick)
>    that is almost certainly what it is there to do as the site claims that
> it supplies sanitised data to their advertisers.

On it's own that's not necessarily a bad thing if it's just a single 
site. I object to the way Doubleclick do (did?) it though.

>> or that 
>> they may encode sensitive information that would be useful if obtained 
>> (e.g. some dumb websites that put user login information in the cookie).
>    probably not, but who can tell?

Any obvious plain text or clue as to what created it (e.g. PHP_SESSION) ?

Tried decoding the string with base64 or uudecode ?

If it's a public site can you name them ?

At the end of the day, most of the concerns bandied around about cookies 
are just a load of bullsh!t. A cookie on its own can't steal your 
passwords, crash your computer or eat your granny. It's just a piece of 

What the cookie droppers do with their own cookies is a legitimate cause 
for concern but you need to analyse the risk and then allow or disallow 
the cookie on a case by case basis.

If you have anything unauthorised on your computer that can read your 
cookies and send them to people other than the site that dropped them 
then you have bigger problems :-)

Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list