🔑
Security

Session security — secure cookie, hijacking protection and regeneration

08.07.2034
← All articles

A session is a continuous connection between the user and the server. After the user logs in, the session ID is sent with every request, and the server recognizes which user it is. If an attacker obtains this session ID, they will fully access the user's account — without even knowing the password. Therefore protecting the session ID is extremely important.

Secure cookie settings

In PHP the session ID is usually stored in a cookie. The settings of this cookie must be correct. Through session_set_cookie_params() the following are set: secure=true (only sent over HTTPS), httponly=true (cannot be read from JavaScript), samesite='Lax' or 'Strict' (CSRF protection), path='/' (works across the site). These settings must be done before session_start().

Session hijacking

Session hijacking is when the attacker obtains the user's session ID. This happens in several ways: through XSS (if cookie is not HttpOnly), network sniffing (if no HTTPS), sending session ID in URL, man-in-the-middle on public WiFi. Protection: mandatory HTTPS, HttpOnly cookie, no session ID in URL (session.use_only_cookies=1 in php.ini), and IP/User-Agent checking.

Session regeneration

At the moment the user logs in or performs important actions, the session ID needs to be regenerated. This is done through session_regenerate_id(true). The true parameter deletes the old session. Why is this needed? In a session fixation attack, the attacker first creates their session ID and forces the user to log in with this ID. Then they can act on behalf of the user through that ID. Regeneration prevents this.

Session timeout

A session should not last indefinitely. There are two types of timeout: absolute timeout and idle timeout. In banking applications idle timeout is usually 5-15 minutes, absolute timeout 1-2 hours. On regular sites idle can be 30 minutes, absolute 24 hours.

Logout — ending session

When the user logs out, the session must be completely ended. This consists of three steps: 1) clear $_SESSION, 2) call session_destroy(), 3) delete cookie. Doing only one is not enough — all three are needed.

Sayt.uz practice

On the Sayt.uz platform session cookies are automatically set with Secure and HttpOnly flags. SameSite=Lax setting provides CSRF protection. When logging in session_regenerate_id is mandatory. Idle timeout is 30 minutes, absolute timeout 24 hours. By hosting your site on Sayt.uz hosting, sessions are securely transmitted over HTTPS.

Related articles

🛡️ Ransomware Protection: Backups, Segmentation, EDR, and Incident Response 🎣 Protecting Employees from Phishing Attacks: Training and Technical Measures 📋 Security Audit Checklist: WordPress, Server, SSL, and Backup Review 🔐 SSL Certificate Monitoring: Expiry Tracking and Auto-Renewal
🌐 Language
🇺🇿 O'zbek 🇺🇿 Ўзбек 🇷🇺 Русский 🇬🇧 English