Member Avatar for justted

Hello all,

Just wanted to see if I am leaving open some security hole in a script I have! When the user logs in it creates a session based on the id field of the users table! For example .... my id is 10 so a session is created with based on that.

What I wanted to know is if I want a secure way to identify a genuine user based on their session then should I make this session more complicated by adding further details? Or even create multiple sessions?

I am currently checking the user against my sql table id against their session but thought that if someone created a session from another website with for example the number 10 then I wouldnt want them being able to access my members account whose ID number is 10!

Hope this makes sense and someone can clarify the best way around it

Thanks

  • 3 Contributors
  • 2 Replies
  • 116 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by somedude3488

Dani AI

Generated

Short answer: it depends how you implement it. If you only store the numeric user id in a server-side session (for example $_SESSION['user_id']) and rely on PHP's session cookie, an attacker on another site cannot simply set user_id = 10 for your domain. The real risks are session fixation/hijacking (if an attacker can force or steal a session id), XSS that steals cookies, unencrypted transport, and any code that accepts user IDs from GET/POST/cookies without server-side verification.

Practical hardening (do these rather than creating extra "sessions"):

  • Always use HTTPS so cookies cannot be sniffed.
  • Configure the session cookie with HttpOnly, Secure and a SameSite policy.
  • Regenerate the session identifier when a user authenticates and after privilege changes to prevent fixation.
  • Keep sessions short (idle timeout + absolute timeout) and track last activity server-side.
  • Store session records server-side (DB) so you can invalidate them, and optionally store a hashed per-session token and light fingerprint (partial UA or subnet) for anomaly detection — but be cautious with strict IP checks because of mobile/proxy churn.
  • Protect against XSS and CSRF; those are common vectors that defeat session protection.

Example for a secure long-lived "remember me" token (store only the hash in DB):

$token = bin2hex(random_bytes(32));
$hash  = hash('sha256', $token);
// store $hash with user_id and expiry in sessions table
setcookie('remember', $token, $expire, '/', '', true, true);

Both and have the right instincts: sessions are workable, and adding redundant session variables is not a substitute for the core protections above. If you find your code is setting raw user ids in client-side cookies or trusting query parameters, change that to server-side sessions or to unpredictable tokens validated against a DB.

Recommended Answers

All 2 Replies

Member Avatar for somedude3488

Its pretty secure. Adding more info and creating extra session is unnecessary overhead.

The best way to prevent this is to run session_regenerate_id(true).

[kireol explains everything nicely, I posted at the same time. Didn't see that post]

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.