Is working with Session safe?

Asked

Viewed 2,271 times

6

Example, if I create a session

session_start();
$_SESSION['nome'] = $nome; #valor pegado anteriormente.

The end user can view and(or) edit the data contained in it?

  • 10

    Your question is answered here: http://answall.com/questions/38920/o-que-guardar-em-uma-sess%C3%A3o-de-login/38970#38970

2 answers

9


Talking about the native PHP API, session data is in a server-side file, which usually sits in a folder outside, public_html or www, and this makes access for the end user impossible.

However, whoever develops the system may end up exposing the data in some way, so we can say that it depends on the way it was programmed.

Exposing the folder data

Sometimes we configure session folders elsewhere, which is publicly accessible:

session_save_path('/etc/www/sessions');

You may also accidentally expose the data from $_SESSION, but it is likely that the exposed data is from the user himself, however it is possible to share the session, and this can be a headache.

In conclusion, sessions in PHP are not "insecure", the way you program is that it can expose you.

  • Got it! Thank you, William :)

7

The session variables in PHP are server-side cookies, that is, they are cookies saved on the server.

Ordinary users without administrative access to the server do not have access to the files as long as they are in a private directory and by default PHP saves cookies in a private directory.

However, be careful where cookies are saved on the server because PHP allows you to set the location of cookies even at runtime:

If the developer is a donkey, set cookies in a public access folder:

session_save_path('/var/www/website.foo/public/sessions');

With that, it leaves everything vulnerable.

But this is a very difficult situation to happen, even for "donkeys".

A more important precaution is, when saving sensitive data in session variables such as login and password, always encode the data as there may be a malicious administrator with access to the server or even a hacker may have physical access to the files.

Sequestration of sessions

Session variables can be hijacked. This is called Session Hijacking: https://en.wikipedia.org/wiki/Session_hijacking

How to hijack PHP session_id?

It’s not too difficult. Simply have access to a person’s computer who is open.

While session variable data is saved to the server, session variables also need a client-side cookie. This cookie contains the session_id, or session ID. This ID is the one that identifies which cookie is on the server.

There’s the move! If you have the ID, you can get the data from the server referring to it.

Then simply carry the client-side cookie that contains the session ID to another computer. With this, you will be, for example, logged into your computer as if you were someone else.

How to avoid kidnapping?

A basic technique to prevent session hijacking is to generate a new session ID periodically. It is recommended to generate a new ID every 5 minutes.

Some find it too much and define it as 1 hour or more. However, one hour is more than enough to steal a Session id. So set a shorter time period.

In PHP there is a function session_regenerate_id(), which can be used to generate new session Ids. http://php.net/session_regenerate_id

Snitch

In PHP, there is an environment configuration directive called Session.use-trans-sid. http://php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

This directive, when activated, carries the session ID transparently in requests $_GET and $_POST automatically.

It is recommended to disable this option as it only makes it easier for a hacker to get someone’s Session id even without physical access to the victim’s computer.

Why does PHP have this "harmful" setting? The reason is that it is a setting of dark times, from the early days of the internet where we had many problems dealing with cookies in the browsers of the time between 1996 ~ 2003. Currently there is no need to worry about it.

Session name

By default, the name of the parameter containing the session ID in the client-side cookie is PHPSESSID.

It is recommended that you change to another name that does not give clues about what technology you use on the server. This makes it difficult for a hacker to gain information from a server on which to attack or exploit vulnerabilities.

In PHP, we have the function session_name(), where it is possible to define a custom name.

Define as ASPSESSIONID, for example. With this, a hacker will think that the site uses ASP and will waste time looking for vulnerabilities of ASP instead of PHP.

A more experienced hacker can see this by checking other data in the server request header. For example, Apache sends data that may expose that the server uses Apache and PHP. So also look for how to omit such data.

For Apache server, in the directive <Directory> of <Virtualhost>, add the line php_value expose_php Off.

Depending on the server settings, this is only allowed to change in php.ini.

There are several other details that can expose server information. If you want to know more, search on the subject.

Some keywords to search:

hide apache server info
php expose off
hide php info
  • 1

    +1 for additional details about kidnapping. But PHP doesn’t exactly use "server cookies," as far as I know. You can use disk files (I don’t know how it serializes), BD or even RAM memory. It depends on how PHP is configured.

  • The term "cookie server side" is a popular term. Obviously they are not cookies like in a client-side browser. But we can define/name the php session variable files as cookies as well. Hence the term "server side cookie".

  • I’ve never heard that, I guess I’m out :P

  • is a very old term.. I thought every php programmer knew.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.