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:
- generating a session identifier
(SID) to
be associated a group of web pages (or activities) with a particular
user,
- sending this SID to the users browser,
- making sure that
this same SID is sent back by the browser along with each
subsequent request, and
- 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: http://www.examplesite.com?sid=Hu33Ymd923Js1ULsd45
- 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
Cookies
- 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 2.0.0.5.
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., ASP.net)
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)
Response.Cookies.Add(aCookie)
Dim CookieTo As New HttpCookie("myname", strOrdNo)
HttpContext.Current.Response.AppendCookie(CookieTo)
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.
- ASP.net ViewState (ASP.net): 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.Lock()
Application(PageCounter) += 1
lblPageCounter.Text = Application(PageCounter)
Application.Unlock
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.
<configuration>
<sessionstate
mode="inproc"
cookieless="false"
timeout="20"
sqlconnectionstring="data source=127.0.0.1;user
id=<userid>;password=<password>"
server="127.0.0.1"
port="42424"
/>
</configuration>
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.