HTTP is a
stateless protocol. You may use cookies and sessions to maintain the state of
an application specific to an end user.
What are the differences between sessions and cookies?
Cookies
HTTP cookie (web
cookie/ Internet cookie, browser cookie or simply cookie) is a small piece of
data sent from a website and stored in the user's web browser while the user is
browsing. If programmer doesn’t assign
an expiration date to the cookie, it is lost with browser close. These are
In-memory cookies for the browser, on the other hand you may set expiration
date for the cookie to make it Persistent cookie. Persistent cookie deems to be
stored on the client side hard drive and retrieved on next visit of website
based on expiration date set by server side..
Programmers may
use Response object to create and set cookie values, and Request object to
retrieve the values of cookies created during previous interaction. Cookies are
associated with a website, not with a specific page, so the browser and server
will exchange cookie information no matter what page the user requests from
your site (exception: see benefit section for Path property of Cookies).
Limitations:
1. The security
of cookie generally depends on the security of the issuing website and the
user's web browser, and on whether the cookie data is encrypted. Security
vulnerabilities may allow a cookie's data to be read by a hacker, used to gain
access to user data, or used to gain access (with the user's credentials) to
the website to which the cookie belongs. You should never store sensitive data
in a cookie, such as user names, passwords, credit card numbers, and so on. Do
not put anything in a cookie that should not be in the hands of a user or of
someone who might somehow steal the cookie information. This also means, on
server side you should safeguard server side logics with extra validations,
when you are taking inputs from cookies. (Less secured than session)
2. Most
browsers support cookies of up to 4096 bytes. This limit is applied to the name-value
portion of the cookie only. (No size limits in session)
3. Most
browsers allow only 20 cookies per site; if you try to store more, the oldest
cookies are discarded. Some browsers also put an absolute limit, usually 300,
on the number of cookies they will accept from all sites combined. So, you may
have to create cookies with sub-keys, in case you are reaching the count limits.
( No count limit in sessions)
4. User has the
rights to deny using cookies. As per Cookie Law, your website must inform
visitors how you use cookies. Also, you must write a dummy cookie in your web
application implementation and read on server side, to verify if current
browser of user is supporting cookies. (Session is server side, so user can’t
handle /control sessions)
5. User has the
ways to clear cookies on his web browser, no matter what expiration time you
mentioned. (User can’t clear sessions without exposed functionality given to
user)
6. You must
check for nonexistence of a cookie key in request object to avoid null
reference errors. (But similar is also true for sessions too)
7. In the
request object, you will not get the expiration date of the cookie, if you are
too much concerned about expiration date; you need to reset it every time on
server side. (Session timeout is controlled in web.config in .net apps)
Benefits:
1. You may
limit the scope of specific cookie to specific folder of website by defining
Path property of cookie.
2. You may set
the Domain property of cookie to limit scope to a specific domain/sub-domain.
3. You may
request a browser to delete a cookie by setting expiration date earlier than
current time, say yesterday.
4. You may
create a new cookie on server side with same name as existing cookie and send its
value to client, to modify an existing cookie.
5. We will
discuss later in this post, what are server side sessions and how they may get
benefit from cookies.
Session
A session can
be defined as server-side storage of information that is desired to persist
throughout the user's interaction with the web site or web application. Dealing
with sessions without cookies is a mess as described in benefits of cookies
above. Web applications transmit session Ids from server side as cookie, so
that during next request session id in next request may identify the session.
Some older browsers do not support cookies or the user may disable cookies in
the browser, in that case sessionId may be munged in the each href clickable on
the page. This seems more unsecured to me than disabling cookies though.
Types of
Session Implementation: Sessions may be implemented in-memory on server side
(InProc session mode), using state server services (Aspnet_state.exe), SQL
server or by custom providers in .Net applications and SQL Server session mode
is a more reliable & secure session state management as per Jana (2009). In
PHP based applications, you may edit php.ini and set the session.save_handler
and use external DB to store sessions as per Waterson (2015). Possible values
for save_handler in PHP could be files (default), mm, database and SQLLite. PHP
provides a function that lets you override the default session mechanism by
specifying the names of your own functions for taking care of the distinct
tasks as per Shiflett (2004).
Benefits:
1. Easier to
maintain user specific data across all the requests.
2. Kind of
objects being stored are vast.
3. Much more
secured and hidden from user as compared to cookies.
4. Under
in-memory model, session data in a memory object of the current application
domain. So accessing data is very fast and data is easily available.
5. There is not
requirement of serialization to store data in InProc session mode.
6. In .Net
Sessions may be handled at page level too. We may disable session or make it
read-only on a specific page using EnableSessionSate property of page.
Limitations:
1. There is an
overhead involved to serialize and de-serialize
objects in case of StateServer
and SQLServer session modes.
2. Under InProc
session mode, If the worker process or application domain is recycled, all
session data will be lost. We may want to switch to state services, external DB
or custom provider here.
3. InProc
session mode is the fastest, more session data and more users can affect
performance, because of memory usage.
4. Under
multiple server farm scenarios, InProc session mode is not used at all.
When might a developer choose one or the other?
First thing
first, as defined in definition of session above, session needs cookie to be
implemented for storing session Id at least. If a specific information need not
be secured (as defined in limitation 1
of cookie above), and the size is small, cookie may be chosen to store this
information, e.g. cart items of the user, user preferences without login for
next visit on the same site and so on. On the other hand, secured and heavy
information is never passed on to client side cookies as defined in benefit 3
of session above.
Are there any privacy or security implications to using
either?
Session objects
are on server side, that does not mean they are fully secured, but for sure
much more secured than cookies on client side they are. Sessions will be as
much secure as you make them, but cookies don't qualify to be in this race as
defined by limitation 1 of cookies. You may try to make session more secured by
using external DB or use EnableSessionSate property of web pages to make them
more secured in .Net.
What benefits do they provide to the developer that might
override those privacy and security implications?
Cookies put
less overhead on the server side, if the information need not be secured like
tracking cookies, website usability etc. we may choose it. Detailed benefits
and limitations of cookies as compared to sessions may be analyzed in
Limitation/Benefit sections above.
References
Auger, R. (2011,
January). Cross Site Scripting. Retrieved March 03, 2016, from
http://projects.webappsec.org/w/page/13246920/Cross Site Scripting
Iain. (n.d.). Browser
Cookie Limits. Retrieved March 03, 2016, from http://browsercookielimits.squawky.net/
Jana, A. (2009,
January 23). Exploring Session in ASP.NET. Retrieved March 03, 2016, from
http://www.codeproject.com/Articles/32545/Exploring-Session-in-ASP-Net
LassoSoft. (n.d.).
Lasso Programming: Tutorial: Understanding Cookies and Sessions. Retrieved
March 03, 2016, from http://www.lassosoft.com/Tutorial-Understanding-Cookies-and-Sessions
Microsoft. (n.d.).
Maintaining Session State with Cookies. Retrieved March 03, 2016, from https://msdn.microsoft.com/en-us/library/ms526029(v=vs.90).aspx
Microsoft. (2011).
ASP.NET Cookies Overview. Retrieved March 03, 2016, from https://msdn.microsoft.com/en-us/library/ms178194(v=vs.100).aspx
Optanon. (n.d.). The
Cookie Law Explained. Retrieved March 03, 2016, from https://www.cookielaw.org/the-cookie-law/
Shiflett, C. (2004,
December 14). Storing Sessions in a Database. Retrieved March 03, 2016, from http://shiflett.org/articles/storing-sessions-in-a-database
Waterson, K. (2015,
May 8). Introduction To PHP Sessions. Retrieved March 03, 2016, from http://www.phpro.org/tutorials/Introduction-To-PHP-Sessions.html
