Cookies - The First Defense
The main objective to present a simple and short Use Case, quick analysis
of the issues and subject background. We are also presenting the architect
to address the Use Case.
Cookies and Security
How can Cookies be used as a first stage of web security?
Briefly Describe This Use Case
Cookies can be used as a security parameter(s) on web, mobile or any new technologies. They
also can help with the personalization and customization of web pages. Vendors can share
cookies to service their common clients.
Site visitor or client
Our architect should present a quick solution to handle web, mobile or any technologies
used; it should also support the implementation of personalization, customization and
first security layer. Cookies should be shared by different vendors to handle
personalization, customization without any security risk.
What is a Cookie?
An HTTP cookie is a small piece of data (string) sent from a site (web server) to a user's web
browser. Every time the user visits the site, the browser sends the cookie back to the server
to notify the user's previous activity. In a nutshell, a cookie is a string of information
that a site's web server stores on the browser's side and gets it back when the user visits the site.
Cookies' developers have been loading cookies with data to make their tasks easier. Sadly loaded
cookies with data can be used by hackers to gain information about users and site servers. Third-party
tracking cookies are commonly used as ways to compile long-term records of individuals' browsing
histories; which is a potential privacy concern. Third-party tracking cookies are shared by different
vendors for personalizing and customizing web pages.
Issues with Cookies?
The problem is cookies are being misused and mobile vendors are restricting the number of cookies
and usage on mobile platforms. Not to mention Apple and Google have their own unique approach, Apple
has Universal Device Identifiers (UDID) and Google has an identifier all of its own.
Cookies, Security and Services:
Cookies can be used as a security parameter(s) on web, mobile or any new technologies. They also
can help with the personalization and customization of web pages. Vendors can share cookies to
service their common clients.
Browser vendors have the biggest role in keeping or eliminating cookies. They can make life easier
for security and web architects and developers. Sadly there is no standardization of cookie handling
and developers are developing different code for different browsers.
Our architect addresses a number of topics such as loosely coupled, refactoring,
timestamp, Memento Design Pattern Dynamic Business Rules, plus storing Java objects
with timestamp for tracking and audit trailing. The Cookie itself is nothing
but a string which would be saved in the browser. We are proposing 16 byes string
as our cookie.
Cookies-Browser Architect Diagram
The Cookies-Browser Architect Diagram presents a Cookies Object Factory (using Java Object)
which creates Java Cookie Objects. The diagram shows how the flow of cookies are traveled
back and forth between the browser and the Cookies Factory.
The proxy server would generate the business object and that is what we "Cookies Generator
Services (Cookies Objects Factory)". This business object is a service. Our Services are
also Java objects and uses a number of subservices which will call engines. Each engine
performs only one task, and a service object may instantiate a number of engines to perform
the required tasks or functionalities.
Once the Business object is instantiated, it would perform a number of tasks including the following:
• Parses in the coming cookie and based on that there could be a number of actions
• Checks the timestamp
• Checks the saved Cookies Java objects which would save any database access over head
• Extracts data from the database
• Create a new Cookie string based on the business
• Save the Cookie back in the browser
We will not cover sessions and our handling of sessions at this point in the time.
Our Cookies Structure and Bit Mapping
To address all these cookies issues and the future of cookies, we have an alternative approach. We believe
we need to create an "ID Address" (IDA) similar to an IP Address. IDA will be used to identify the customer
and would be stored on the browser/mobile. It will be a string of 16 bytes and consists of the following two sections:
• Public substring (8 bytes - 2 set of 4 bytes string)
• Private substring (8 bytes - 2 set of 4 bytes string)
One of these Bit Flags can be used in combo to set multiple options. For example, if we
use two bits as a combo we have four options for one browser's setting as follows:
00 = no time expiration date or use the browser expiration setting
01 = use the included timestamp as the expiration date
10 = other option such as end of month expiration
11 = expire on exist
Sharing IDA by Vendors:
4 or more bits (in the second public substring - Browser's On/Off settings) can be used as a password
or a Group ID for vendors to share IDA. This means that the browser would include the IDA for this IP
vendor plus all the IDA which have the same bit password or Group ID in "HttpServletRequest". As for
mobile, it would return a comma separated string with all the IDA with the same Group ID or password.
Visitor's ID Usage:
Not only can the 4 bytes (32 bits) be used as an ID but also as a setting to compile long-term records
of an individuals' browsing histories. Such history would be hashed into turning bits On/Off as is
currently done with browser settings. As a security measure, these hashed bits would be only known to
the group or vendors sharing the common IDA.
We are planning on releasing a template of our java code, displaying our approach to 16 bytes IDA (cookies structure).
Dynamic Business Rules and Timestamp:
The Dynamic Business Rules and timestamp can be formulated to create an endless number of ID
and settings which would make it almost impossible for internal and external hackers to figure out.