You are on page 1of 12


Name: Gopal Benakanawari

Rno : 10IS12F

1. What is HTTP cookie?

HTTP cookie is a packet of information sent by a server to the World Wide Web browser
and then returned by the browser each time it accesses that server. It is stored on user’s
computer by their web browser. A cookie can be used for authentication, storing site
preferences, shopping cart contents etc. A cookie consists of one or more name-value pairs
containing bits of information, which may be encrypted for information privacy and data security
purposes. The cookie is sent as a field in the header of the HTTP response by a web server to a
web browser and then sent back unchanged by the browser each time it accesses that server.

Other words,

A computer cookie is a piece of data which often includes an unique identifier, that is
sent to your browser from a web site you visit, stores as a file on your computer,
identifies you as a unique user and track your web usage. Computer cookies can do
everything from monitoring your visit throughout web sites, tracking how many times
you've visited the site, how long you've been on the site, your log-in information at a
particular page to remembering important information about your computer.

2. Why Cookie is used if there is session id concept implanted by all web

The general pattern is for the server to set a single cookie called session id and
then store any data that needs protecting on the server in an area called session.
The session cookie is used to look up the session object on the server and the
session object on the server is used to store information such as current logged –
in. session id is assigned to user and is stored in cookie for user track.

• It informs each page what session the request belongs to when a user accesses
during a session.
• It retrieves all the session information stored on the server.
• Cookies can persist for a much longer period of time than session that has a
timeout value usually of 20 minutes and hence can store information even when a
user is off the site.

3. Explain set cookie and get cookie function used in websites.

Transfer of Web pages follows the HTTP. Regardless of cookies, browsers request a page from
web servers by sending them a usually short text called HTTP request. For example, to access the
page, browsers connect to the server
sending it a request that looks like the following one:

GET /index.html HTTP/1.1


Browser ---------------------------- server

The server replies by sending the requested page preceded by a similar packet of text
called HTTP response. This packet may contain lines requesting the browser to store

             HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Browser< ------------------------------------------------server

The server sends lines of Set-Cookie only if the server wishes the browser to store
cookies. Set-Cookie is a directive for the browser to store the cookie and send it back in
future requests to the server ,if the browser supports cookies and cookies are enabled. For
example, the browser requests the page by sending the
server a request like the following:

GET /spec.html HTTP/1.1


Cookie: name=value; name2=value2

Accept: */*


4. Is there any bound on the size of cookie by web browsers?


4 KB per cookie maximum

300 total cookies, for a total of 1.2 Mbytes maximum

20 cookies accepted from a particular server or domain

According to the HTTP protocol, cookies can’t be larger than 4096 Bytes each

There is a limit to the number of cookies per domain. The number differs per
browser, however, the generally used limit is twenty cookies. This is to prevent a
single domain from hogging the disk space of the client.

5.  Does expire cookie function work in every browser?
Expire cookie uses the same command as creating cookie. The 
cookie value is left blank and expiration time needs to be 
in the past. To expire the cookie  ‘user’ use:
The second parameter is the cookie value and is set to blank with the double quotes. The
third parameter is the expiration time. A value of zero here indicates that the cookie is to
remain valid until the browser is closed. A positive value indicates the time at which the
cookie is to expire. Many sources indicate using something like

which sets the expiration time 3600 seconds (1 hour) in the past
The Expires directive tells the browser when to delete the cookie. It is specified in the form of
“Wdy, DD-Mon-YYYY HH:MM:SS GMT”, indicating the exact date/time this cookie will
expire. As an alternative to setting cookie expiration as an absolute date/time, RFC 2965 allows
the use of Max-Age attribute to set the cookie’s expiration as an interval of seconds in the future,
relative to the time the browser received the cookie. An example of Set-Cookie directives from
Facebook website after a user logged in:

Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; expires=Tue, 15-Jan-2013 21:47:38

GMT; path=/;; httponly
Set-Cookie: made_write_conn=1295214458; path=/;
Set-Cookie: reg_fb_gate=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;
path=/;; httponly

The first cookie lu is set to expire sometime in 15-Jan-2013, it will be used by the client browser
until that time; the second cookie made_write_conn does not have expiration date, it is a session
cookie, it will be deleted after the user closes his/her browser; the third cookie reg_fb_gate has
its value changed to deleted, with an expiration time in the past, the browser will delete this
cookie right away – note that cookie will only be deleted when the domain and path attributes in
the Set-Cookie field match the values used when the cookie was created.
In the case of the __utmc cookie, there is no expiration date set. This is because when a cookie is
written without an expiration date, it automatically expires when the browser closes.

6. Explain cookie setting procedure by websites which uses two 
different domain web 

1. Click the wrench icon on the browser toolbar. Mac users: If you don't see the wrench
icon, go to the menu bar at the top of your screen and click Chrome.
2. Select Options (Preferences on Mac and Linux; Settings on Chrome OS).
3. Click the Under the Hood tab.
4. Click Content settings in the "Privacy" section.
5. Click the Cookies tab in the Content Settings dialog that appears:

Delete cookies

Click Show cookies and other site data.

o To delete all cookies, click Remove all.

o To delete a specific cookie, select the site that issued the cookie, then the cookie,
and click Remove.You can also choose to remove all cookies created during a
specific time period, using the Clear Browsing Data dialog.

7. How   https   handles   cookies?   Is   there   any   kind   of   special 

encryption for cookies parameters?

To prevent session hijacking and cookie replay attacks, secure the cookie by making sure
that it is only passed over SSL connections using the HTTPS protocol. For additional risk
mitigation, encrypt the cookie before sending it to the client and limit the period for which the
cookie is valid. To secure the authentication cookie:

• Restrict the authentication cookie to HTTPS connections.

• Encrypt the cookie and check its integrity.
• Limit cookie lifetime.
• Consider using a fixed expiration period.

Restrict the Authentication Cookie-to-HTTPS Connections:

Cookies support a secure property that determines whether or not browsers should send the
cookie back to the server. With the secure property set, the cookie is sent by the browser only to
a secure page that is requested using an HTTPS URL.

If you are using .NET Framework version 1.1, set the secure property by using
requireSSL="true" on the <forms> element as follows:

<forms loginUrl="Secure\Login.aspx"
requireSSL="true" . . . />

If you are using .NET Framework version 1.0, set the secure property manually in the
Application_EndRequest event handler in Global.asax using the following code:

protected void Application_EndRequest(Object sender, EventArgs e)

string authCookie = FormsAuthentication.FormsCookieName;

foreach (string sCookie in Response.Cookies)

if (sCookie.Equals(authCookie))
// Set the cookie to be secure. Browsers will send the cookie
// only to pages requested with https
Response.Cookies[sCookie].Secure = true;

Encrypt the Cookie and Check Its Integrity:

Encrypt the cookie and check its integrity, even if you are using SSL. This prevents an attacker
from viewing or modifying the cookie if he or she manages to steal it through a XSS exploit. In
this event, the attacker can still use the cookie to gain access to your application. The best way to
mitigate this risk is to implement the appropriate countermeasures to prevent XSS attacks
(described under "Cross-Site Scripting" earlier in this chapter), and limit the cookie lifetime as
described in the next recommendation.

To provide privacy and integrity for the cookie, set the protection attribute on the <forms>
element as follows:

<forms protection="All" Privacy and integrity

Limit Cookie Lifetime:

Limit the cookie lifetime to reduce the time window in which an attacker can use a captured
cookie to gain spoofed access to your application.

<forms timeout="10" Reduced cookie lifetime (10 minutes)

Consider Using a Fixed Expiration Period:

Consider setting slidingExpiration="false" on the <forms> element to fix the cookie expiration,
rather than resetting the expiration period after each Web request. This is particularly important
if you are not using SSL to protect the cookie.

HTTPS cookie 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. On the server-side, it's on the programmer to send this kind of cookie
only on secure connection (e.g. with respect to $_SERVER["HTTPS"]).In a protected
connection (SSL), everything is encrypted, cookies too.
Cookie encryption parameters: encryptCookieNames, encryptCookieValues,
encryptCookieVerifyIP, encryptCookieMatching
“Programmers can require that cookies be delivered and received only
in the context of a Secure Sockets Layer (SSL) session. The SSL session handles the
actual encryption of cookie data”.

8.Determine where physically on your hard drive, cookies are stored. Open some
cookies in a text editor, and describe the general format of a cookie file. Do you
notice any patterns in the content these cookies store?

 When any web page application writes a cookie, it gets saved in a text file on user hard disk
drive. The path where the cookies get stored depends on the browser. Different browsers store
cookies at different locations. E.g. Internet explorer store cookies at “C:\Documents and
Here the “Default User” can be replaced by the current user you logged in as. Like
“Administrator”, or user name like “Vijay” etc. The cookie path can be easily found by
navigating through the browser options. In Mozilla Firefox browser you can even see the cookies
in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then
“Show cookies” button

Sample Cookie File


# Netscape HTTP Cookie File

# This is a generated file! Do not edit. TRUE / FALSE 2082787201 ubid-main 8420-1388495-806370 TRUE / FALSE 887443200 session-id-time 887443200 TRUE / FALSE 887443200 session-id 6808-2461503-219213

Cookie file format of Internet explorer

Cookies are at C:\Documents and Settings\[user name]\Cookies
Cookie name
Cookie value
Host/path for the web server setting the cookie
Exirpation time (low)
Expiration time (high)
Creation time (low)
Creation time (high)
Record delimiter (*)

Conversion of the time to the number of seconds

elapsed since midnight (00:00:00), February 7, 2010,

t = 1e-7*(high*pow(2,32)+low) – 11644473600

The layout of Netscape's cookies.txt file is such that each line contains one name-value pair. An
example cookies.txt file may have an entry that looks like this: TRUE / FALSE 946684799 NETSCAPE_ID 100103

Each line represents a single piece of stored information. A tab is inserted between each of the

From left-to-right, here is what each field represents:

domain - The domain that created AND that can read the variable.
flag - A TRUE/FALSE value indicating if all machines within a given domain can access the
variable. This value is set automatically by the browser, depending on the value you set for
path - The path within the domain that the variable is valid for.
secure - A TRUE/FALSE value indicating if a secure connection with the domain is needed to
access the variable.

expiration - The UNIX time that the variable will expire on. UNIX time is defined as the number
of seconds since Jan 1, 1970 00:00:00 GMT.
name - The name of the variable.
value - The value of the variable.

9. What is the minimum amount of information a Web developer needs to store in

a cookie file  
     in order to identify you when you return to a site? 

(identification number, username,password)

The server cannot grab your e-mail address or any other information from your browser's user
preferences, your hard drive, or anywhere else-unless you actually fill out a form online and send
it in. If you did that, the information could then be saved inside a cookie, and the next time you
visited the site, the server would be able to "remember" that information about you. To see the
contents of the cookie file, just use any text editor to view it in folders named "Temporary
Internet Files" or "Cookies" under the main Windows folder. A cookie generally tells the server :

• the domain from which the cookie originated

• if the cookie requires a secure transmission or not
• specific URLs that may access the cookie
• the cookie's expiration date
• the name of the cookie item
• the actual data for the cookie item

10. A lot of web sites remember your credit card number so that you can quickly
purchase items again. Why would it be a bad idea to store your credit card number
in a cookie?

When sites rely on cookies for every sensitive data then privacy problem may occurs. For
example, some of big online bookstores use cookies to remember users and let you order without
reentering much of your personal information. This is not a particular problem since they don’t
actually display the full credit card number and only let you send books to an address that was
specified when you did enter the credit card in full or use the username and password. As a
result, someone using your computer or stealing your cookie file which contains information. If
the credit card is being stored client side then you're storing it with the key which means it's
vulnerable. If you are storing the credit card server side then you don't need a key of an
encryption key stored on the client. It sounds like a very dangerous situation if what you are
describing is a case where the user is not only not being given the option whether or not they
want to store their details but is also going to have them re-populated without having to
authenticate in any way.

11.  Imagine if stored your checkout total price as the content
portion of a cookie file on your computer while you were filling in information
about your shipping and billing address. Why would that be a bad idea?

Cookies make Web-surfing easier by, among other things, saving your passwords,
purchases, and preferences for you. The use of cookies is an industry standard, and you'll find
cookies at most major Web sites. A cookie lets the Service remember that you've registered,
which allows us to speed up your future activities at our sites. Similarly, if there are any stores
within the Service, a temporary cookie tracks which products you've selected while shopping.
The cookie expires once you're done shopping. Letting it do the record-keeping saves you the
trouble of entering information over and over again during a single visit. If you decline this
cookie, you may have difficulty ordering your selections. The cookie itself does not contain any
personally identifying information although it may enable to relate a user's use of
the Service to personally identifying information that has previously been submitted by the user,
if any. In some rare instances, amateur webmasters actually store credit card or other sensitive
data directly in a cookie. This is extremely bad practice and anyone who discovers it should
most definitely complain loud and clear.This is bad idea because there is chance of cookie
poisonous attack. User or customer can modify the information in the cookie for example if the
total bill is 1200 rs customer can edit it as 12 rs.

12. Can a JavaScript of one site access cookies issued by other sites if yes how?

That depends on how you are making the "request to the other pages". If you make the
request from your code behind, what you're doing is effectively setting the cookie on the server,
rather than on the users browser. Cookies need to be issued by the server to the client browser,
and that is done in the headers of the page response - so you need to direct the users browser to a
page on the other site to issue the cookie from that domain. You could generate a request to the
other page in an IFrame, or try and do it in a self closing pop-up window - but that has other
issues like pop-up blockers, flickering windows, etc.

Another alternative is to tell the other site about the login via a request to it, as in your redirect
suggestion. You could do this in several ways, e.g. by loading the page in an iframe, sending the
data directly from one server to another, and so on.

13a.Perform cookie based csrf attack on your sample site. Find any existing
website with this vulnerability.

CSRF or XSRF stands for Cross Site Request Forgery. The idea is that the attacker is "forging" a
HTTP request when a victim executes html or javascript created by the hacker. Here is an
example CSRF exploit I wrote against XAMPP. The idea is that this html/js is building a POST
request which "rides" on already existing session. The CSRF exploit must be executed by the
browser of an XAMPP administrator that is currently logged in.


<form action=’’ method=’POST’ id=1>

<input type=” hidden” name=”_SERVER[REMOTE_ADDR]” value=””>

<input type=” hidden” name=”xamppuser” value=admin>

<input type=” hidden” name=”xampppasswd” value=password>

<input type=” hidden” name=”xamppaccess” value=”Make+safe+the+XAMPP+directory”>






order to do this the hacker must know a lot about the request ahead of time, most importantly the
destination server and all of the variables. The hacker does NOT need to know the sesion id or
the "basic-auth" header, this is automatically provided by the browser. If you add a randomly
genearted secret then the request cannot be forged unless the hacker knows that value. Its like
having a password for every request you send to the server. A hacker can obtain this token value
using XSS.

The most popular ways to execute CSRF attacks is by using a HTML image tag, or JavaScript
image object. Typically an attacker will embed these into an email or website so when the user
loads the page or email, they perform a web request to any URL of the attackers liking. Below is
a list of the common ways that an attacker may try sending a request.

HTML Methods

<img src="http://host/?command">

<script src="http://host/?command">

14. Write a script to view current cookie stored by all sites in web browser.

All the cookies you can see are in the document.cookie property, which contains a
semicolon separated list of name=value pairs.

var getCookies = function()

var pairs = document.cookie.split (“;”);

var cookies = { };

for (var i=0; i<pairs.length ;i++)

var pair = pairs[i].split(“=”);


Return cookies ; }

Later we can write,

var myCookies=getCookies( ) ;

alert(myCookies.secret) ; // to make secret