, ,

To get Books of Sanjib Sinha…

About the Author….

Web pages hold temporary data. To make it dynamic, we can store
our data on the server. We can use session to achieve this special
To work with session, we can store and retrieve data by its
We start with a simple session_start() function.

Consider someone has logged in by filling out a form. We can
keep or store that name just by starting session. It is something like
– you have issued a ticket to someone who can now enter your
application and stay there for some time. When his or her session
ends, the user has to leave.

To store data in session, we use super global $_SESSION array.
In the above code, we have done two things. First we have stored
a name and then we created a hit counter. Each time the particular
user or visitor visits this page, the hit counter refreshes and the value
increases by one.
We have two links in this page. Let’s see the code of the other
two pages. First, we’ll see the code of the page ‘get-session.php’.

In this page we get the name of the user. If you don’t come to this
page from the previous page, you won’t see the name. it will throw
up an error.
Secondly, we will see the code of the ‘nextpage.php’.

In this code, we see the count of the page. However, we will be
able to see that only if we come to this page from the previous page.
That is the magic of session.
So as you can see, you are able to store data between page pro-
cesses. This data isn’t preserved forever. It times out automatically
and it depends on how you set it in the php initialization file –
Before digging deep let’s see some more examples so that the
conception is more clear.
We have two pages – session-one and session-two.
In the session-one page we have started our session this way
and try to store some data:.

We will see in the session-two page, how we can get back these

Here we get back our data along with an idea of session ID.
Since we store data in session, it is extremely important that we keep
the security perspective in our mind. All data for a particular session
will be saved in a file in the directory specified by the session,save_-
path item. However, there are more to consider.
To preserve certain data across subsequent accesses, we need
session support. So far this part is clear.
You need to understand that when a visitor accesses your web
site, he/she is assigned a unique ID. This is either stored in a cookie
on the user side, or it is transmitted in the URL. When a visitor visits
your web site, php will check automatically if
session.auto_start is set to 1 or not. You can make it start
and set it to 1 with the session_start() function. The super global
$_SESSION and all registered variables are serialized by php using
the inner mechanism of serialization handler specified by the
‘session.serialize_handler ini’ setting.
Some cautions must be mentioned here. Because session data
is serialized, resource variables (such as your database or FTP
connection) cannot be stored in the session. Resource variables hold
special handles to opened files, database connections, image canvas
areas and the like.
There are some pre-defined constants session use – one of them
is SID. You have seen it in one of the examples above. This constant
will only be available when the session starts or it is dynamically
loaded. This constant contains either the session name or session
ID in the form of “NAME=ID” or empty string.
Session security is also important, although there is not enough
scope to elaborate here. You may consult my book written for php
security only. And there are other few good books available on the
same topic.
Let me give a very short introductory note on the topic.
The problem of session module is it cannot guarantee the
security always. The information stored in a session is not safe
always. Someone else can see them. For preventing that, you have
to take extra precautions. Every session always carries some type
of data. If this data is important, you need to deploy additional
measures. It may come at a price. It may reduce convenience for
the users.
Suppose you want to protect users from simple social engineer-75
Session, Cookie
ing tactics. You have to enable “session.use_only_cookies”. In that
case, cookies must be enabled unconditionally on the user side. If
it’s not, sessions will not work.
Session IDs can be leaked to third parties. There are several
ways. You may think of JavaScript injections, session ID in URLs,
packet sniffing, physical access to device and many others.
A leaked session ID enables the third party to access all re-
sources that are associated with the specific ID. The first vulnerable
point is URL. The URLs carry session IDs. If you link to an external
site, the URL including the session ID might be stored in the external
site’s referrer logs.
The second scenario is more sinister. A more active attacker
might listen to your network traffic. If it is not encrypted, the session
IDs will flow in plain text over the network. Implementing SSL/TLS
on your server is mandatory for users. HSTS should be used for
better security.
Remember, HTTPS cannot protect confidential data at all times.