What is a Cookie? How is
it important in session management?
Ans
Cookies are small files that websites put on your computer hard disk
drive when you first visit.
Think of a cookie as an identification card that's uniquely yours. Its
job is to notify the site when you've returned. While it is possible to misuse
a cookie in cases where there is personal data in it, cookies by themselves are
not malicious.
Many websites, including Microsoft's, use cookies. Cookies tell us how
often you visit pages, which helps us learn what information interests you. In
this way, we can give you more of the content you like and less of the content
you don't.
Cookies can help you be more efficient. Have you ever put something in a
virtual shopping cart in an online store and then returned a few days later to
find that the item is still there? That's an example of cookies at work.
Cookies let you store preferences and user names, register products and
services, and personalize pages.
But if you never register or leave personal information at a site, then
the server only knows that someone with your cookie has returned to the
website. It doesn't know anything else.
Cookies can be created by client-side script in a Hypertext Markup
Language (HTML) page (for example, by using a script written in Microsoft
Visual Basic Scripting Edition or JScript), by Win32 programs that use the
Microsoft Win32 Internet functions (InternetSetCookie and InternetGetCookie),
or by server-side script (for example, a script written in Visual Basic
Scripting Edition in an Active Server Pages [ASP] page, or a Common Gateway
Interface [CGI] script).
Important: Cookies cannot be used to run code (run programs) or to deliver viruses to your computer.
The purpose of a cookie is to tell the Web server that you have returned to a specific Web page. For example, if you personalize Web pages, or register for products or services, a cookie helps the Web page server to recall your specific information. This may be useful to simplify the process of recording your personal information, such as billing addresses, shipping addresses, and so on. When you visit the same Web site, the information you previously provided can be retrieved, so you can easily use the Web site features that you previously chose.
You have the ability to enable or disable cookies, or have Internet Explorer prompt you before accepting cookies. Note that disabling cookies may prevent some Web services from working correctly, and disabling cookies does not make you anonymous or prevent Web sites from tracking your browsing habits. HTTP requests still include information about where you came from (HTTP Referer), your IP address, browser version, operating system, and other information.
Cookies may be used to maintain data related to the user during navigation, possibly across multiple visits. Cookies were introduced to provide a way to implement a "shopping cart"a virtual device into which users can store items they want to purchase as they navigate throughout the site.
Shopping basket applications today usually store the list of basket contents in a database on the server side, rather than storing basket items in the cookie itself. A web server typically sends a cookie containing a unique session identifier. The web browser will send back that session identifier with each subsequent request and shopping basket items are stored associated with a unique session identifier.
Allowing users to log in to a website is a frequent use of cookies. Typically the web server will first send a cookie containing a unique session identifier. Users then submit their credentials and the web application authenticates the session and allows the user access to services.
Using regular HTML pages, when a browser requests a page from a server,
the server will serve that page to the client then simply forgets about it! No
knowledge of the client is kept between requests. Certainly the client browser
will keep a record of the pages in the History object, but unless we do
something no other information is kept. In a suite of web pages this means that
if we enter information in one form, it will not automatically be available to
other pages in the web application.
·
Query Strings: Information can also be kept in the query
string. The draw back of this of course is that the information is visible.
·
Hidden Input elements: Information can be passed from page to page
using hidden form elements.
·
Cookies: Cookies are strings that are stored on the
clients computer which are Domain specific.
·
Sessions: PHP includes a sessions management system that
allows to treat any single session on a single client as a unified whole.
·
Frames: All the variables would be placed in one of
the Frames using JavaScript. These would then be available in any of the other
frames. This method is really only of Historical interest.
Sessionmanagement
Due to the stateless nature of how HTTP works, it’s virtually
impossible for a web server to differentiate one request from another. As
developers, it is imperative for us to implement some sort of session
management to identify one user’s request from that of another. Most modern
programming languages and web servers have mechanisms in place that ease
management of users’ sessions by creating Session IDs. These session IDs help
identify unique user requests. However, session IDs are often an attack target
where a malicious user might attempt to guess a valid session ID in an attempt
to hijack a current user’s session. Another similar attack would consist of a
malicious user attempting to predict a future session ID. If a future session
ID could be predicted, the malicious user could send a request to the server
containing the future session ID and attempt to hijack a user’s session after
that session ID was assigned.
The strength of a session ID is directly related to its
length and the number of unique characters used to create it. The more
characters the session ID contains, generally the more secure it will be.
Ideally, a session ID should be at least 128 bits of entropy, which equates to
about 16 characters in length. ASP.NET session IDs are 120 bits, but they have
the added value of being signed and encrypted which all but ensures their
security. ASP.NET session IDs are similar to GUIDS (Globally Unique
Identifiers) and are virtually guaranteed to never repeat. If you are not using
a language that generates session IDs or it generates session IDs that aren’t
of sufficient size and strength, it is imperative that you, the developer,
implement secure session IDs that are safe from attack.
In the event the web server you are using doesn’t support
sessions, then the implementation of cookies is the best way to handle session
management. Cookies are basically just pieces of data that can be persistent
(stored on the user’s machine) or non-persistent (only available while browser
is open and session is active). Before using cookies, it’s important to
understand how to use them in a secure manner. The rest of this article will
focus on the following areas of cookie security.
· Persistent
vs. Non-Persistent
· Clear
Text/Encoding/Encryption
· Security
Issues of Poor Implementation
First, let’s get an understanding of what a cookie actually
is and why it is used. Cookies are nothing more than pieces of text that are
transmitted from the web server to the user’s browser. Why are cookies used?
Generally, cookies are used to determine the authentication or authorization
rights of a user; they can be used to track which items a user has added to his
shopping cart in an e-commerce website. They can also be used to track a user’s
actions within an application to determine preferences. These preferences can
then be used for targeted advertising.
Now that we know what a cookie is, let’s clear up some
misconceptions on what a cookie isn’t. Cookies are not harmful, at least not in
the context that they can cause harm to your computer system. Since cookies are
nothing more then text and not executable code, it’s virtually impossible for
them to be used maliciously like a virus or worm. The general concern
associated with cookies has to do with a person’s browsing privacy. Because
cookies can be used to track a user’s preferences and internet browsing
patterns, they can be used to track what websites you have visited. In a
corporate environment this could be an issue if employees are accessing websites
that are in violation of a company’s internet usage policy. So, now that we
know what cookies are and what they aren’t, as well as why they are used, let’s
move on to understanding how developers can use them safely and securely within
their applications.
What is the difference between a persistent and
non-persistent cookie? A persistent cookie is data that is saved to a user’s
machine. A common scenario when a persistent cookie would be created is when a
user logs into an application and chooses to have their identity remembered,
such as using the “remember me” functionality of a site during the login
process. The persistent cookie contains information that identifies the user on
subsequent visits to the site. The cookie may allow the user to bypass the
login functionality and gain automatic access into the site itself. A
non-persistent cookie is data that is only available while the user’s browser
is still open and the session is active. If the user explicitly logs out of the
application or closes their browser the non-persistent cookie is destroyed.
None of the data associated with a non-persistent cookie is written to the
user’s machine.
You should never store
sensitive or personally identifiable information, such as social security
numbers, account numbers, or passwords, in a persistent cookie. When making the
determination on whether to encrypt or encode the data or leave it in plain
text is up to developer preference. However, it is recommended to encrypt any
cookie data that is used as a part of the applications logic, such as if a
cookie value is used to hide or display a link on the page. In the examples
below we’ll look at some common security issues that can arise when cookies are
implemented incorrectly.
No comments:
Post a Comment