Great Ideas. Always Flowing.

We are not happy until you are happy. Client satisfaction guaranteed. Whatever your needs and requirements, we have the skills and resources for the job!

Popular Tags...

Tags

SnowCovered Top Sellers

Frustrated over the lack of customization for your user's registration fields? Dynamically setup your DNN Portal with custom registration fields, layout, questions, and other core integration options......

Ultra Video Gallery is a brother product of Ultra Media Gallery, UVG allows you to upload videos in various format and automatically encode them to flv or H264 format, you also can add videos from internet or record live videos from your webcam.

Build high performance, completely customizable data-entry forms and views driven by your DNN and external databases. New built-in tools make it a snap to quickly create data entry forms, data views, and even database tables. Plus, add your own HTML, CSS, Javascript, SQL commands, stored procedures,

The most advanced DotNetNuke shopping cart on the planet. Easy to use e-Commerce, Secure Shopping Cart Software and SEO friendly. B2C / B2B Ecommerce Sites.

One stop solution for events calendar and events registration! FREE DOWNLOAD is available now!

Cookie Creation & Session Management

Week 4: Cookie Creation and Session Management


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.


In Figure 1 below, we see a user attempting to login to an application using his username and password.


Figure 1

 

Figure 2 shows the response received from the server.

 

Figure 2

 

Figure 3 shows the menu listing for an authenticated user.

 

Figure 3

 

As you can see above, the response sets a series of cookies associated with the application. The “UserInfo” cookie collection contains three separate cookie values, userid, isadmin and isloggedin. We also see the developer chose not to encrypt the values associated with these cookies. If these cookie values are used to determine functionality of the application, this can lead to serious security issues, such as privilege escalation and even worse, identity theft.

 

Using a web proxy, such as Burp Proxy or one of several browser add-ons, such as Tamper IE for Internet Explorer or Live HTTP Headers for Firefox, we can intercept and manipulate requests to and from the browser. By intercepting and manipulating the requests to the application, we can determine if changing the values of the cookies has any effect on the application itself. In Figure 4 below, we have changed the “isadmin” cookie value from “f”, assuming this means False, to “t” for True.

 

Figure 4

 

We can see in Figure 5 below that this value was being used to determine specific functionality of the application. We see by changing the value from “f” to “t”, a new menu item called “Admin” was added to the page. This allowed our malicious user to escalate his privileges to gain access to the administrative portion of the application.

 

Figure 5

 

One of the menu items of interest for an authenticated user is the “My Account” link. In Figure 6 below we see the page displayed when this link is clicked.

 

Figure 6 (Note: User account information is fictitious.)

 

We see from the page displayed above that a specific user’s details are displayed on the “My Account” page. These details include the user’s name, address and credit card information. The next thing we, as a malicious user, would attempt to do is see if we can gain access to another user’s account information. By looking at the application’s cookies, we see a “userid” with the value “12151”. By intercepting and manipulating this value by incrementing it, we can determine if this will allow us to access other user’s accounts.

 

In Figure 7 below we have change the “userid” value in the request from “12151” to “12152”.

 

Figure 7

 

We can see in Figure 8, that the “userid” cookie was being used to determine the identity of the user accessing the application. By changing this value we, as the malicious user, have successfully gained access to another user’s account information allowing us to steal their personal information.

 

Figure 8 (Note: User account information is fictitious.)

 

The previous examples demonstrate the serious security issues that can arise when cookies are implemented incorrectly. Because the above cookies are persistent, this information is also saved locally on the user’s machine. If a malicious user were able to gain access to this cached cookie they could use it to access the application and impersonate the user, thus gaining access to their account information. In summary, it is developer preference whether to use a persistent or non-persistent cookie. It is also recommended never to store sensitive or personally identifiable information within a cookie value. Finally, it is considered a security best practice to encrypt any data stored within a cookie.

 

 

Feedback Comments

Feedback

SharePoint Web Parts


All Data Springs Web Parts Support WSS 3.0, SharePoint 2007, and SharePoint 2010 Frameworks

Please select license option for each web part you wish to purchase. We highly recommend the SharePoint Bundle to get all Data Springs Web Parts for maximum value!

 

 

      
Cart


Data Springs Sharepoint Bundle

Best Value! The Bundle gives you all 5 web parts in one package at a very attractive price! Best Value! We think you will be very happy with the SharePoint bundle and great price discounts you will receive. With your purchase all of the web parts below will be included.
 
 
 
 

Random Image Web Part

With Random Image for Sharepoint 2007, you can select multiple images to display randomly when the web part loads...
 
 
 
 

Stock Quote Web Part

Giving your site visitors relevant information is critical. With the Data Springs Stock Web Part you can provide your users with up to date financial information
 
 
 
 

Dynamic Image Rotator Web Part

Who would have thought? Adobe Flash® with Sharepoint! The FIRST and ONLY image rotation web part for Sharepoint using Flash Technology from Adobe! The Dynamic Image Rotator displays selected images and then rotates between the images. Several extended and optional features allow you to select the time to rotate each image, fade between
 
 
 
 

SharePoint Charts Web Part

The MOSS Chart Web Part is a web part built by Data Springs for the purpose of rendering several chart types based on data from a SharePoint list on a MOSS 2007 or WSS 3.0 Site
 
 
 
 

Dynamic News Ticker Web Part

Provide current news items with a user-friendly news ticker for your Sharepoint Portal. With millions of web sites offering information you need a fun way to display information and the solution is Flash News Ticker....
 
 
 
 

Tailored Text Web Part

 Tailored Text Web Part allows you to add text/html to your web site that can be different for anonymous users, registered users,  and even individual users specifically.

 
 
 
 

Dynamic Views Web Part

Dynamic Views is an excellent tool to:
Personalization allows you to go the extra mile in communicating or connecting one to one with your clients. When it comes to technology and web site content, you now have the power to leverage this personalization directly with your users on your DotNetNuke® site

 
 
 
 

Dynamic Login Web Part

Your site content isn't vanilla, so why is your portal's login?

Add pizazz and functionality with Dynamic Login! Use custom templates, localization, redirection rules for various roles and many more features!
 
 
 
 


 
 

Join our mailing list...

Get current news and events the easy way
 
 
   
Subscribe Me

Recent Blogs...

 
Copyright 2005 - 2011 by Data Springs, Inc.