2

I have built up a login on my website where I set a $_SESSION['user'] variable if the login was successful.

Now I protect all the content for logged in users by 

if(!isset($_SESSION['user'])) {
    header('Location: login.php');
}

This means that if there hasn't been a successful login, you directly come back to the login page.

Now my question: Is this secure? Couldn't a $_SESSION['user'] variable have been set by another website?

  • 1
    sessions are written to file on the webserver so another website could set a session called `user` but it would be set on a different site and valid on a different site – Professor Abronsius Aug 11 '16 at 07:20

5 Answers5

3

This is correct. This is the way generally used by most websites using PHP.

The $_SESSION is a super global variable that is only managed by your server.

What happens:

  1. You call session_start()
  2. A cookie named PHPSESSID (or anything that you name it in php.ini) with a cryptographically secure value will be generated.
  3. PHP declares a variable called $_SESSION, which is internally stored with association to the generated cookie value.

Why it cannot be changed by other websites:

  1. The value of $_SESSION is only stored internally. Not even the client knows its value. It only holds a cookie for session ID, but it doesn't even know what that session ID means, nor what other people's session ID should be.
  2. This session ID cookie cannot be stolen or modified by other websites. By default, the cookie path is set to your own domain, and the client should only send it to you. (If the client wants to send to other websites, it's leaking its own credentials and it is none of your responsibility but the bug of the client browser)

Unless you are running other websites on the same server, this won't be a problem (under normal circumstances).

As a side note, please be reminded that you should add a return; statement after using header("Location: index.php");. This is a common source of bugs, and in this context, it may expose your server to danger, because even though your browser won't display the content after it received the Location header, your server is actually still sending the data that should be generated for the user as if he has logged in.

TL;DR: if you have a script that should not send any data if client is not logged in, not adding the return; statement after header("Location: ..."); will make the server still send the data, but normal browsers will not display it (because it redirects), but if there is someone who tries to view the data sent (using methods as simple as curl without adding the -L option) will easily see them.

Panda
  • 6,955
  • 6
  • 40
  • 55
SOFe
  • 7,867
  • 4
  • 33
  • 61
  • Is cookie can set by other website? – Naveen DA Aug 11 '16 at 08:15
  • @NaveenDA Theoretically no if you don't want it to happen. Actually, if you send the cookies properly (default action), they aren't even sent to other websites. – SOFe Aug 11 '16 at 09:09
  • 1
    Just imagine, if every website's cookie is seen by every website you visit, suppose you have visited 1000 websites that use cookies, every time whichever website you visit you are sending 1000 cookies unnecessarily, which is very unreasonable. Unless the browser has bugs, cookies from different websites shouldn't interceptat all. – SOFe Aug 11 '16 at 09:10
  • I forgot to mention that you may as well want to consider about CSRF (cross-site request forgery) attacks. In CSRF attacks, other websites can't retrieve cookies, but they can make the browser send a request to your server using the cookies the browser has as if a normal user. The other websites can't access the data returned in the request's response if cross-site access-control is set properly (as default), but if the server does something else in the request, e.g. executes something on behalf of the user, the impacts will still be made despite the response isn't returned to the referrer. – SOFe Dec 14 '16 at 13:43
2

What you have done so far is fine and seems not vulnerable, and no attacker setting session variable from other site doesnt effect yours, but take care how you handle session once a session is created. Also generate random session tokens on each login and also change session tokens when passwords are changed.

StackB00m
  • 502
  • 1
  • 5
  • 16
2

In general a session itself can be considered safe. The problem is that is possible to steal a session allowing a hacker to have total access to whatever is in that session.

Since PHP stores the session ID as a cookie, a hacker can steal the session simply by using XSS.

Maybe have a look here for further information: Is this a safe use of Session Variables?

Community
  • 1
  • 1
eol
  • 23,236
  • 5
  • 46
  • 64
1

You're not likely to face this problem unless there's another login page on the same server. Say, login of admin and front end users.

If you want to strengthen your session and other security components, you could refer to this:

PHP Session Security

Community
  • 1
  • 1
Indrasis Datta
  • 8,692
  • 2
  • 14
  • 32
0

No.

Your website creates an unique hash and file on the server machine for the session and the hash is stored in the users browser as a cookie so when it hits your webserver, it could know which file exactly to read.

If any other website sets the same key to the $_SESSION variable it will be only for its hash, which your server wont read.

Vasil Rashkov
  • 1,818
  • 15
  • 27