SESSION

HIJACKIN
G
When a website successfully authenticates a user, the
browser and the server open a session. A session is an
HTTP conversation in which the browser sends a series
of HTTP requests corresponding to user actions, and the
web server recognizes them as coming from the same
authenticated user without requiring the user to log back
in for each request.
If a hacker can access or forge session information that
the browser sends, they can access any user’s account on
your site. Thankfully, modern web servers contain secure
session-management code, which makes it practically
impossible for an attacker to manipulate or forge a
session.
Session hijacking allow an attacker to access any of your
users’ accounts. This is such a tantalizing prospect that
hackers have found many ways to hijack sessions.
 How sessions work

When a user authenticates themselves under HTTP, the web server

assigns them a session identifier during the login process. The session
identifier (session ID)—typically a large, randomly generated number—is
the minimal information the browser needs to transmit with each
subsequent HTTP request so the server can continue the HTTP
conversation with the authenticated user. The web server recognizes the
session ID supplied with each request, maps it to the appropriate user, and
performs actions on their behalf.
Note that the session ID must be a temporarily
assigned value that’s different from the
username. If the browser used a session ID that
was simply the username, hackers could pretend
to be any user they pleased. By design, only a
very small minority of possible session IDs
should correspond to a valid session on the
server at any given time.
Besides the username, the web server typically stores
other session state alongside the session ID, containing
relevant information about the user’s recent activity. The
session state might, for example, contain a list of pages
the user has visited, or the items currently sitting in their
shopping basket.
 There are two common
implementations, typically
described as server-side sessions
and client-side sessions
Server-side session
In a traditional model of session management, the web
server keeps the session state in memory, and both the
web server and browser pass the session identifier back
and forth. This is called a server-side session.
Simple server session example in PHP
Historically, web servers have experimented with transferring
session IDs in multiple ways: either in the URL, as an HTTP header,
or in the body of HTTP requests. By far, the most common (and
reliable) mechanism the web development community has decided
upon is to send session IDs as a session cookie. When using
session cookies, the web server returns the session ID in the Set-
Cookie header of the HTTP response, and the browser attaches the
same information to subsequent HTTP requests using the Cookie
header.
Cookies have been part of the HyperText Transfer Protocol since
they were first introduced by Netscape in 1995.

Server-side sessions have been widely implemented and are

generally very secure. They do have scalability limitations, however,
because the web server has to store the session state in memory.
During authentication, only one web server stores the established
session. Subsequent requests directed to different servers require
recognition of returning users. To achieve this, web servers must
share session information. Typically, this involves writing session
state to a shared cache or database with each request. However,
these operations are resource-intensive and can reduce
responsiveness, especially for sites with large user bases, as each
user adds significant load to the session store.
Client-side session
Because server-side sessions have proven difficult to scale for large
sites, web server developers invented client-side sessions. A web
server implementing client-side sessions passes all session state in
the cookie, instead of passing back just the session ID in the Set-
Cookie header. The server serializes session state to text before the
session state is set in the HTTP header. Often, web servers encode
the session state as JavaScript Object Notation (JSON)—and
deserialize it when returning it to the server
By using client-side sessions, a site’s web servers no longer
have to share state. Each web server has everything it
needs to reestablish the session with an incoming HTTP
request. Client-side sessions do create an obvious security
problem, however. With a naive implementation of client-
side sessions, a malicious user can easily manipulate the
contents of a session cookie or even forge them entirely.
This means the web server has to encode the session state
in a way that prevents meddling.
One popular way to secure client-side session cookies is to encrypt
the serialized cookie before sending it to the client. The web server
then decrypts the cookie when the browser returns it. This
approach makes the session state entirely opaque on the client
side. Any attempt to manipulate or forge the cookie will corrupt
the encoded session and make the cookie unreadable. The server
will simply log out the malicious user and redirect them to an error
page.
Another approach to securing session cookies is to add a digital
signature to the cookie as it’s sent. A digital signature acts as a
unique “fingerprint” for some input data—in this case, the
serialized session state—that anyone can easily recalculate as long
as they have the signing key originally used to generate the
signature. Digitally signing cookies allows the web server to
detect attempts to manipulate the session state, since it’ll calculate
a different signature value and reject the session if there has been
any tampering