Session Management

HTTP and Session Management

  • Stateless HTTP
    • HTTP provides no integrated way to maintain stateful interactions throughout user's subsequent requests
    • In web programming all the information within a page is lost when the page is posted back to the server.
  • State Management
    • Proper management of states allows clients and servers to exchange information within a context of state called "session".  The management of sessions is called session management.
    • Web applications maintain session management by:
      1. generating a session identifier (SID) to be associated a group of web pages (or activities) with a particular user,
      2. sending this SID to the users browser,
      3. making sure that this same SID is sent back by the browser along with each subsequent request, and
      4. setting the applications to an "idle" mode to wait for the client's next HTTP request.
  • Applications:
    • personification
    • on-line shopping
    • web-based email
    • etc.
  • Problems:
    • SIDs are usually stored locally in browser cookies.
    • Web applications are using predictable URL/form actions in a repeatable way.
    • When an user is currently authenticated to the site and sends requests with legitimate credential, the site has no way to tell if the request has been forged.

Session Management Methods

There are three widely used methods for maintaining sessions in web applications. They are all not safe.

    URL Querystring
  • A querystring is information added to the end of a page's URL using ? as the separator between the URL and the querystring and & to separate each querystring pair.  
  • Example:
  • Pros:
    • Lightweight and easy to employ.
    • Useful when the client browser cookie function is disabled.
    • Transferable through a copy of the URL.
  • Cons
    • URL length has limitations: usually 255-character.
    • Visible and easy to tampered.
    Hidden Form Field
  • A hidden form field stores text data with the HTML <input style="hidden"> tag. 
  • A hidden form field is not visible in the browser, but the value can be sent to the server along with the other form fields.
  • Example: <input type=hidden name=sid value=Hu33Ymd923Js1ULsd45>
  • Pros:
    • Useful when the client browser cookie function is disabled.
    • Not as visible as the querystring.
  • Cons
    • URL length has limitations: usually 255-character.
    • Visible and easy to tamper. Internetishop Demo
  • Cookie is a technology initially designed for Netscape Navigator 1.0 to mitigate some of the problems stemming from HTTP's stateless nature.
  • A cookie is a small text file that stores data on the client's machine or is persistent in-memory during the client browser session. When the browser requests a page, it sends the information in the cookie along with the request information.
  • Pros:
    • Cookies time span can be regulated.
    • Session information is embedded within the pages served to the client browser.
    • Invisible and relatively not easy to tamper.
  • Cons:
    • Cookie is limited to 4KB in memory.
    • Browser cookie function might be disabled.
         Cookie Attributes (RFC 2965)
    • name=value: This attribute contains a string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, URL encoding is recommended. This is the only required attribute on the HTTP Set-Cookie header.
    • domain: This attribute is used to compare against the domain of the server in which the URL is being created and requested. If the domain matches or if it is a sub-domain, then the path attribute will be checked next.
    • path: This attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. If the path attribute is set too loosely, then it could leave the application vulnerable to attacks by other applications on the same server. If the path is not specified, it is assumed to be the same path as the document being described by the header which contains the cookie.
    • expiration: This attribute is used to set persistent cookies to be expired until the set date is exceeded. Once the expiration date has exceeded, the browser will delete the cookie. If this attribute is not set, then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends. The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT
    • secure: This attribute (True/False) tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS.
    • HttpOnly: This attribute, first implemented in 2002 by Microsoft Internet Explorer developers for Internet Explorer 6 SP1, is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via a client side script such as JavaScript. Firefox started supporting it in its version
         Cookie Maintenance
    • Cookies can be issued by including an appropriate <META> tag in the returned HTML document, for example:
    • <meta http-equiv=Set-Cookie content="sessionid=123">
    • Cookies can be issued by including a Set-Cookie HTTP header in the web servers response.
    • Cookies can be issued, retrieved and deleted by using document.cookie in JavaScript using the format: 
    • document.cookie = 'cookie_name=cookie_value; expires=date; path=/' 

    • Cookies can also be issued, retrieved and deleted by using server-side scripting (e.g.,
    • Response.Cookies("userName").Value = "patrick"
      Response.Cookies("userName").Expires = DateTime.Now.AddDays(1)

      Dim aCookie As New HttpCookie("lastVisit")
      aCookie.Value = DateTime.Now.ToString()
      aCookie.Expires = DateTime.Now.AddDays(1)

      Dim CookieTo As New HttpCookie("myname", strOrdNo)
      Dim CookieBack As HttpCookie
      CookieBack = HttpContext.Current.Request.Cookies("mycartno")

Session Management Approaches: Client-side vs. Server-side

Session management can be broadly classified into client-side and server-side, based on the contents of the session token passed between the client and and server and withins the applications.

    Client-side Session Management
  • Session information is stored in a cookie, a querystring value pair, or a hidden form in the browser or on the client machine.
  • ViewState ( The Control.ViewState property provides a way for retaining values between multiple requests for the same page. When a page is processed, the current state of the page and controls is hashed into a string and saved in the page as a hidden field. When the page is posted back to the server, the page parses the view state string at page initialization and restores property information in the page.  The key restriction for view state is that it works only when a page posts to itself. 
  • Is ViewState safe? No. Try this ViewState Decoder which is a tool used to decode the ViewState values.
    Server-side session management

    Session information is stored on the server and passed between pages.
  • ASP.NET session ID: When a user first opens their Web browser and then goes to a website that implements ASP.NET session state, a cookie is sent to the browser with the name "ASP.NET_SessionId" and a 20-character value. ASP.NET Session keeps track of the user by creating a cookie called ASP.NET_SessionId in the user browser. This cookie value is checked for every request to ensure that the data being served is specific to that user.
  • Application State: An application's state is stored using the application's state object (HttpApplicationState class) for each active web application. Application state is a global storage mechanism accessible from all pages in the web application and is useful for storing information that needs to be maintained between server round trips and between pages. Use Application.Lock to provide concurrent assess to the state. An example for the use of application state is the counter for page visits.:
    Sub Page_Load()
        Application(PageCounter) += 1
        lblPageCounter.Text = Application(PageCounter)
    End Sub
  • Session State: Besides application state, ASP.NET also can store session states using a session state object (HttpSessionState class) for each active Web Application. Session state is similar to application state, but it is scoped to the current browser session. If different users are using an application, each user will have a different session state. If a user leaves the application and returns later, that user will have a different session state. Session state is a key-value dictionary structure for storing session-specific information that needs to be maintained between server round trips and between requests for pages. Once we add our application-specific information to session state, the server manages this object for us. Depending on the options we specify, session information can be stored in cookies, an out-of-process server, or a SQL Server.  Session state settings in ASP.NET can be configured through the web.config file.
          sqlconnectionstring="data source=;user id=<userid>;password=<password>"

Session Attacks

  • Session Hijacking: An attacker gains access to the users session by intercepting, predicting or brute-forcing his SID issued by the web server.
  • Session Fixation: Instead of hijacking a SID, an attacker can issue (set or fixate) a user session ID before the user even logs into the target server and force the users browser into using the chosen session.