Viewed   82 times

Currently when user logged in, i created 2 sessions.

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name

So that, those page which requires logged in, i just do this:

if(isset($_SESSION['logged_id'])){
// Do whatever I want
}

Is there any security loopholes? I mean, is it easy to hack my session? How does people hack session? and how do I prevent it??

EDIT:

Just found this:

http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script

http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/

Just found the links, are those methods good enough?? Please give your opinions. I still have not get the best answer yet.

 Answers

3

Terminology

  • User: A visitor.
  • Client: A particular web-capable software installed on a particular machine.

Understanding Sessions

In order to understand how to make your session secure, you must first understand how sessions work.

Let's see this piece of code:

session_start();

As soon as you call that, PHP will look for a cookie called PHPSESSID (by default). If it is not found, it will create one:

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

If it is found, it takes the value of PHPSESSID and then loads the corresponding session. That value is called a session_id.

That is the only thing the client will know. Whatever you add into the session variable stays on the server, and is never transfered to the client. That variable doesn't change if you change the content of $_SESSION. It always stays the same until you destroy it or it times out. Therefore, it is useless to try to obfuscate the contents of $_SESSION by hashing it or by other means as the client never receives or sends that information.

Then, in the case of a new session, you will set the variables:

$_SESSION['user'] = 'someuser';

The client will never see that information.


The Problem

A security issue may arise when a malicious user steals the session_id of an other user. Without some kind of check, he will then be free to impersonate that user. We need to find a way to uniquely identify the client (not the user).

One strategy (the most effective) involves checking if the IP of the client who started the session is the same as the IP of the person using the session.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    die('Session MAY have been hijacked');
}

The problem with that strategy is that if a client uses a load-balancer, or (on long duration session) the user has a dynamic IP, it will trigger a false alert.

Another strategy involves checking the user-agent of the client:

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}

// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
    die('Session MAY have been hijacked');
}

The downside of that strategy is that if the client upgrades it's browser or installs an addon (some adds to the user-agent), the user-agent string will change and it will trigger a false alert.

Another strategy is to rotate the session_id on each 5 requests. That way, the session_id theoretically doesn't stay long enough to be hijacked.

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['count'] = 5;
}

// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
    session_regenerate_id();
    $_SESSION['count'] = 5;
}

You may combine each of these strategies as you wish, but you will also combine the downsides.

Unfortunately, no solution is fool-proof. If your session_id is compromised, you are pretty much done for. The above strategies are just stop-gap measures.

Friday, August 5, 2022
5

After revisiting this topic several times, I have figured it out. There were two problems.

  1. session_regenerate_id() must be called before any HTML output is displayed and/or headers are sent. (It needs to be called as one of the first functions, just like session_start()).
  2. Order matters. session_name("TMU") needs to be called BEFORE session_start() to have the desired result - I didn't catch this before.

Basically what was happening to me was calling session_name("TMU") after session_start() was causing it to set TWO session ID cookies - two sessions - one named TMU the other just the default PHPSESSID. Changing the order fixed all my problems and regenerating the ID / destroying the old session works as expected now.

For anyone having problems doing this I suggest you echo out the $_SESSION and $_COOKIE arrays to see what is happening in your particular application.

Tuesday, October 18, 2022
 
5

You should:

  • encrypt sensitive data
  • avoid:
    • avoid sql injection
    • Session hijacking
    • Session fixation

Recommended Reading:

PHP Security Guide

Thursday, December 15, 2022
3

It's hard to quantify in exact terms. First, remember that cookies are transferred between the client and the server in every single request. That's potentially many opportunities for someone to intercept them. Just assume that cookies will be intercepted at some point by somebody.

Storing the username, userid and (encrypted) password in the cookie:

  • leaks information which may or may not be useful or usable for nefarious purposes; i.e. for a successful login you need a username and a password, and you are waving both high up in the air shouting CAPTURE ME, the username even in plaintext
  • relies solely on the secrecy of your encryption algorithm for the password; if it becomes known, you have quite a security problem
    • since the encrypted password is known, an offline brute force attack can be mounted against it to reveal the encryption algorithm and plaintext password; this attack may or may not be purely theoretical, the fact that it exists at all should bother you
    • if it is possible at all to decrypt the password, you have already lost; the password is a secret only the user alone should know, not even you want to know at any point what the password is; if you do know the password, you have a giant responsibility to safeguard it, certainly you do not want to send it back and forth over HTTP the whole time; ? see password hashing
  • gives you no control over anything, all login information rests with the client (i.e. what do you do if you know any of the above was compromised?)
  • does not let you change passwords without invalidating all active logins

On the other hand, using only a meaningless session id:

  • reveals no useful information in the cookies
  • no opportunity to crack or brute force anything of value
  • server holds the ultimate power since sessions can be revoked at any time
  • it's simpler (simpler is always good in security)
  • using a full session with server-side state allows you to escalate privileges; e.g. require the user to have actively logged in with his password within the last x minutes from the current IP to allow him to change his password or email address ? provides security even if the session cookie should be hijacked

In short: session ids present no attack surface at all, since they're inherently meaningless. Userids, names and passwords present a very juicy target. Just from those basic points sessions should seem a lot more appealing. Assuming a perfect implementation with otherwise perfect security, both should be rather secure. However, you do not know what insecurities you have, you won't have perfect security. Assuming this, knowing this, the simpler system with fewer caveats should always be preferable.

Sunday, August 21, 2022
 
4

For receiving frames destined to all hosts you must set your network interface in promiscuous mode.

For getting frames you can use different alternatives:

  1. pcap API (library libpcap)
  2. packet sockets: http://man7.org/linux/man-pages/man7/packet.7.html
  3. Look at ebtables (I've never used it so I'm not sure in this point): http://linux.die.net/man/8/ebtables
  4. Here netfilter is proposed: How to capture network frames in a kernel module

If you still want to hack the kernel you don't need to create a new Ethernet device driver, just write a kernel module that registers to receive frames received from the Ethernet device driver. Look at kernel file http://lxr.free-electrons.com/source/net/core/dev.c , you can begin with function:

int netif_rx(struct sk_buff *skb)

This is the one receiving frames from the device driver.

Thursday, December 8, 2022
 
7bstan
 
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :