Techniques for Making Cookies Secure

[Will]

Is there a good article - or maybe a good chapter in a book - that someone
can recommend on the topic of how to make cookie handling secure?

I'm interested in common techniques for:

- encrypting the cookie

- verifying integrity of the cookie

- organization of different cookie types, and typical entities maintained in
each cookie type

- parsing the cookie on the server side to scan for any injection that a
hacker may have inserted

- attributes commonly stored in the cookie to maintain user identity and
state (e.g., public IP, private IP, machine name, login account name,
kerberos or other time-based ticket)

--
Will

[pcx99]

Will wrote:

Is there a good article - or maybe a good chapter in a book - that someone
can recommend on the topic of how to make cookie handling secure?

I'm interested in common techniques for:

- encrypting the cookie

- verifying integrity of the cookie

- organization of different cookie types, and typical entities maintained in
each cookie type

- parsing the cookie on the server side to scan for any injection that a
hacker may have inserted

- attributes commonly stored in the cookie to maintain user identity and
state (e.g., public IP, private IP, machine name, login account name,
kerberos or other time-based ticket)

I'll assume you've already looked up the wikipedia entry which goes on
quite nicely about security and privacy.

For encryption you can do a search on md5 javascript which at least will
point you in the right direction if you need anything more secure.

The cookie itself can have a "secure" setting and such a cookie will
only be transmitted between client and server if an encrypted connection
has been established between the web-server and the client.
Additionally, on the server side, the cookie can be designated a HTTP
cookie and will be invisible and unavailable to javascript.

NONE of these methods secures the cookie. As in on-line multi-player
games the cardinal rule is *NEVER, EVER* trust the client.

To that end, the only use of cookies you should consider is as a unique
client identifier which will let you match that client with your
server-side database record. You can encrypt the identifier or make it
as obscure as humanly possible of course and even then an HTTP cookie
would be an even better route. But storing any other data where you are
actively considering encryption and verifying integrity is a really,
really bad idea.

Here's the documentation on php's setcookie command (complete with
further instructions on http and secure: http://www.php.net/setcookie

And a public domain javascript function which will do much the same
(well except for http setting, that would be silly):

function setCookie( name, value, expires, path, domain, secure ) {
var today = new Date();
today.setTime( today.getTime() );
if ( expires ) {
expires = expires * 1000 * 60 * 60 * 24;
}
var expires_date = new Date( today.getTime() + (expires) );
document.cookie = name+'='+escape( value ) +
( ( expires ) ? ';expires='+expires_date.toGMTString() : '' ) +
//expires.toGMTString()
( ( path ) ? ';path=' + path : '' ) +
( ( domain ) ? ';domain=' + domain : '' ) +
( ( secure ) ? ';secure' : '' );
}
And finally, the rfc for cookies can be found here:
http://www.faqs.org/rfcs/rfc2109.html

Hope that helps you out a bit.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[Dr J R Stockton]

In comp.lang.javascript message <lB***************@newssvr19.news.prodig
y.net>, Sat, 3 Feb 2007 23:57:39, pcx99 <[e-mail]:

>
And a public domain javascript function which will do much the same
(well except for http setting, that would be silly):

function setCookie( name, value, expires, path, domain, secure ) {
var today = new Date();
today.setTime( today.getTime() );
if ( expires ) {
expires = expires * 1000 * 60 * 60 * 24;
}
var expires_date = new Date( today.getTime() + (expires) );

There should be better code available.

// today.setTime( today.getTime() ); // pointless

var D = new Date()
D.setDate(D.getDate() + expires)

then use D in the write statement. That will give one civil day even
over Summer Time changes.

It's a good idea to read the newsgroup and its FAQ. See below.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[pcx99]

Dr J R Stockton wrote:

In comp.lang.javascript message <lB***************@newssvr19.news.prodig
y.net>, Sat, 3 Feb 2007 23:57:39, pcx99 <[e-mail]:

>And a public domain javascript function which will do much the same
(well except for http setting, that would be silly):

function setCookie( name, value, expires, path, domain, secure ) {
var today = new Date();
today.setTime( today.getTime() );
if ( expires ) {
expires = expires * 1000 * 60 * 60 * 24;
}
var expires_date = new Date( today.getTime() + (expires) );

There should be better code available.

// today.setTime( today.getTime() ); // pointless

Heh yea, that does seem to be more than a bit odd. I clipped this
function from: http://www.dustindiaz.com/top-ten-javascript/ an
otherwise excellent reference. My guess is Dustin just clipped this as
well because it was public domain.

>
var D = new Date()
D.setDate(D.getDate() + expires)

then use D in the write statement. That will give one civil day even
over Summer Time changes.

Much cleaner.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA