In the following slide I am going to demonstrate the difference between Cookies and Session and how to use each and why. Also, I am going to talk a bit about session hijacking
2. YOU HAVE ZERO PRIVACY
ANYWAY
Scott McNealy (Sun Microsystems)
3. What is Cookie?
A cookie is a text-only string created by the
website you navigate and gets entered into
the memory of the browser.
If the lifetime of this value is set to be longer
than the time you spend at that site, then this
string is saved to file for future reference.
4. Historical Brief
Lou Montulli, protocols manager in
Netscape's client product division, wrote the
cookies specification for Navigator 1.0.
Netscape Navigator 1.0 the first browser to
use the technology.
5. Cookie Anatomy
A Cookie can have 6 parameters passed to it
Name (Mandatory)
Value (Mandatory)
Expiration Date (If not set the default is end of
session).
Path
Domain
Secure Connected Required
6. Cookie Anatomy – Expiration Date
The expires parameter lets you determine the
lifetime of the cookie.
If not set explicitly, then it defaults to end-of-
session.
The length of a session is the length of time
that the browser is open for (even if the user
is no longer at that site).
7. Cookie Anatomy – Path
It sets the URL path the cookie is valid
within.
Pages outside of that path cannot read or
use the cookie.
8. Cookie Anatomy – Domain
If a site uses multiple servers within a domain then it is important to
make the cookie accessible to pages on any of these servers.
Cookies can be assigned to individual machines, or to an entire
Internet domain.
The only restrictions on this value is that it must contain at least two
dots (.myserver.com, not myserver.com) for the normal top-level
domains, or three dots for the "extended" domains
(.myserver.ny.us, not myserver.ny.us)
The server issuing the cookie must be a member of the domain that
it tries to set in the cookie.That is, a server called
www.myserver.com cannot set a cookie for the domain
www.yourserver.com.The security implications should be obvious
If Domain is not set explicitly, then it defaults to the full domain of the
document creating the cookie.
9. Cookie Anatomy – Secure
False by default; only used in HTTPS
websites.
10. Create Cookie
In PHP use the function: setcookie
Setcookie takes the 6 parameters
Name
Value
Expire Date
Path
Domain
Secure
11. Retrieving a Cookie Value
Cookies can be read on the browser side or the server side.
Again, the determining factor is the language used.
The main limit on retrieving a cookie is that you can only
retrieve cookies that are valid for the document your script
resides in.That is, a script on www.myserver.com cannot
read cookies from www.yourserver.com.
Also for subdirectories within your site.A cookie valid for
/dirOne cannot be read by a script in /dirTwo.This is mainly
governed on the browser side, as browsers know the URL
that they are accessing, and only transmit cookies for that
server across the connection.
13. Clearing Cookie Value
Set the cookie's value to null.
Set the cookie's expiration date to some
time in the past.
14. What is a session?
You are working with an application.You
open it, make some changes, and then you
close it.That is a session.
15. How session works?
Each user accessing the website has a unique
ID assigned to him managed by PHP.
Session Stores the information on the server
rather than the client side like in Cookies.
16. What is $_SESSION
It is a special array used to store
information across the page requests a
user makes during his visit to your website
or web application.
17. Starting Session
session_start() starts the session between
the user and the server, and allows values
stored in $_SESSION to be accessible in
other scripts later on.
18. Killing Session Variables
To end single session variable use unset(‘session
variable’)
To unset all of the session’s values, you can use
the session_unset() function.
It is very important to clean up after yourself
to ensure maximum security when dealing
with potentially sensitive information.
To avoid having a huge amount of stale
session data sitting on the server.
19. Terminate Session
session_destroy() is responsible for
terminating the session so you can no more
access/store session variables in the array
$_SESSION.
20. Session Security Tips
SettingTimeout
Regenerate Session ID
Destroy Session
Use Permanent storage
21. Session Timeout
Timing-out sessions is a very important
action if you are dealing with users logged
in to your website or application. If a user
logs in to your site in an Internet café and
then leaves the computer and café without
logging out, how do you stop the next user
on that computer from still having access
to the previous user’s session?
22. Regenerate Session ID
The session_regenerate_id() function creates a
new unique-ID for to represent the current user’s
session.
This should be regenerated time any important
authentication action is performed, such as
logging in or updating user profile data.
Giving the sessions a new ID after such actions
make your application more secure by reducing
the risk of a specific attack known as “Session
Hijacking.”
23. Destroy Session
This stops attackers from hijack the stale
session, again increasing the session-related
security of your web site.
24. Use Permanent Storage
Use a database to store data at the earliest
moment you know the data will be persistent;
don’t let it stay as part of the session for too
long as this opens it up to possible attack.
Really think about whether the data belongs
should be stored in $_SESSION because
session data is meant to be transient.
26. Session Fixation (Prediction)
Rarely used.
Prediction refers to guessing a valid session
identifier.With PHP's native session
mechanism, the session identifier is
extremely random, and this is unlikely to be
the weakest point in your implementation.
27. Session Fixation (Capture)
Most Common.
Because session identifiers are typically propagated
in cookies or as GET variables, the different
approaches focus on attacking these methods of
transfer.
While there have been a few browser vulnerabilities
regarding cookies, these have mostly been Internet
Explorer, and cookies are slightly less exposed than
GET variables.
Thus, for those users who enable cookies, you can
provide them with a more secure mechanism by
using a cookie to propagate the session identifier.
28. Sesson Hijacking
Most common session attack
Session hijacking refers to all attacks that
attempt to gain access to another user's
session.
If your session mechanism only consists
of session_start(), you are vulnerable,
although the exploit isn't as simple.
29. Session Hijacking
Rather than focusing on keeping the session
identifier from being captured, focus on how
to make such a capture less problematic.
The goal is to complicate impersonation,
since every complication increases security.
With the most simplistic session mechanism,
a valid session identifier is all that is needed
to successfully hijack a session. In order to
improve this, we need to see if there is
anything extra in an HTTP request that we
can use for extra identification
Editor's Notes
The path parameter is potentially the most useful of the 4 optional cookie settings. It sets the URL path the cookie is valid within. Pages outside of that path cannot read or use the cookie.
... path=/promo ...If Path is not set explicitly, then it defaults to the URL path of the document creating the cookie.
Domain The domain parameter takes the flexibility of the path parameter one step further. If a site uses multiple servers within a domain the it is important to make the cookie accessible to pages on any of these servers.
... domain=www.myserver.com ...Cookies can be assigned to individual machines, or to an entire Internet domain. The only restrictions on this value is that it must contain at least two dots (.myserver.com,not myserver.com) for the normal top-level domains, or three dots for the "extended" domains (.myserver.ny.us, not myserver.ny.us) IMPORTANT: The server issuing the cookie must be a member of the domain that it tries to set in the cookie. That is, a server called www.myserver.com cannot set a cookie for the domain www.yourserver.com. The security implications should be obvious.
4.3 Retrieving a Cookie Value For the most part, retrieving cookies does not require reading the HTTP Cookie: header. Most languages read this header for you and make it accessible through a variable or object. Cookies can be read on the browser side or the server side. Again, the determining factor is the language used. The main limit on retrieving a cookie is that you can only retrieve cookies that are valid for the document your script resides in. That is, a script on www.myserver.com cannot read cookies from www.yourserver.com. This is also true for subdirectories within your site. A cookie valid for /dirOne cannot be read by a script in /dirTwo. This is mainly governed on the browser side, as browsers know the URL that they are accessing, and only transmit cookies for that server across the connection.
4.4 Clearing a Cookie Value When programming a Web site, there are many reasons that you may need to erase a cookie you have created. Often it is because the cookie is no longer needed, or the scheme of your cookie has been altered, and requires resetting. The two main steps to clearing a cookie you have created are:
Set the cookie's value to null.
Set the cookie's expiration date to some time in the past.
The reason you must do both is that simply setting the expiration to a past time will not change it's value until the browser is closed. That is, all cookie names, values, expirations, etc are resolved once the browser program has been closed. Setting the cookie to null allows you to properly test for the cookie until that resolution.
You are working with an application. You open it, make some changes, and then you close it.
While there may be many users accessing the site at the same time, each with his own session, it’s thanks to unique IDs assigned and managed by PHP for each session that allows each user’s session to be available only to himself. Session information is stored on the server rather than the user’s computer (as cookie data is stored), which makes sessions more secure than traditional cookies for passing information between page requests.
$_SESSION is a special array used to store information across the page requests a user makes during his visit to your website or web application. The most fundamental way to explain what a sessions is like is to imagine the following scenario:
Ending a Session
As important as it is to begin a session, so it is to end one. Even though a session is only a temporary way to store data, it is very important to clean up after yourself to ensure maximum security when dealing with potentially sensitive information. It is also good practice and will avoid having a huge amount of stale session data sitting on the server.
To delete a single session value, you use the unset() function:
<?php
session_start();
// set time-out period (in seconds)
$inactive = 600;
// check to see if $_SESSION["timeout"] is set
if (isset($_SESSION["timeout"])) {
// calculate the session's "time to live"
$sessionTTL = time() - $_SESSION["timeout"];
if ($sessionTTL > $inactive) {
session_destroy();
header("Location: /logout.php");
}
}
$_SESSION["timeout"] = time();
It is unwise to rely on anything at the TCP/IP level, such as IP address, because these are lower level protocols that are not intended to accommodate activities taking place at the HTTP level. A single user can potentially have a different IP address for each request, and multiple users can potentially have the same IP address.