• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 366
  • Last Modified:

Session hijacking in PHP (see this OWASP video)

I have a web application written in PHP which runs on a dedicated server in my office.

I was looking at this video on the OWASP.org website and it has be concerned about the security of my application.

My biggest concern is the threat of somebody hijacking an authenticated user's PHP session.


This video discusses the importance of running your ENTIRE WEB APP under HTTPS security, not just the login page.  I have configured my web application to do so - it makes complete sense and actually it's easier for me to do it that way.

However, look at what they say at the 2:45 mark:


The video discusses the vulnerability of a man-in-the-middle attack for websites which are HTTPS secured, but that first initial request by the user is over unsecured HTTP. When the webserver sends that first 302 redirect over HTTP to send the user to the HTTPS secured site, that initial unsecured communication is supposed to be vulnerable to a man-in-the-middle attack.

My application falls under that category, it is vulnerable to this.

I don't think I can enable Strict Transport Security on my application as the video suggests - besides the compatibility issues and not knowing how to do it, the "HTTP" part is not hosted by me. My domain registrar provides a "domain forwarding" service which I use to send the user to the HTTPS encrypted page. So my domain registrar's servers handle the 302 redirect, not me.

I have attempted to mitigate this risk by doing two things:

   1) The login.php page of my web application destroys the session and creates a new one every time you go to it. Navigating to the login page whilst already logged in will destroy your session and log you out. I'm hoping this means that the session ID for the HTTP unsecured connection is different from the HTTPS secured session, rendering it useless to an attacker.

   2) My web application uses of two-factor authentication (the user is emailed a PIN number each time they login). Failure to enter that PIN number correctly more than a few times freezes the account and sends a warning email to me and the user.

Is there anything else I can do? Or is this really worth worrying about beyond this?
  • 2
2 Solutions
I have not watched the video, but I'm very familiar with web app security.

It doesn't matter if the user starts on an HTTP page if it's not part of your session's domain. The key part is that you want HTTPS when the session is CREATED. Your domain registrar does not have anything to do with your session, so no session information is passed at that stage. It is PHP that creates the session, so as long as they end up on an HTTPS page when the session begins, you should be safe.

Bear in mind that session hijacking through sniffing is rather uncommon. This requires someone to actually be in the path of the network packet AND be malicious AND be searching for session IDs AND be willing to follow through with an attack. The most common scenario is a network admin who is snooping around and is sniffing outbound packets that come through a company's central router and is looking at specific employees. However, unless there is some personal value in what your application provides (and that value is significant to the network admin), the likelihood of an admin trying to hijack the session is pretty low. Most admins just care about whether or not employees are actually visiting sites like Facebook on company time.

The more likely scenario of session hijacking is through code injection. If your application in any way allows person A to see something that person B has written (e.g. a message board), then you need to ensure that person B's input is sanitized. Otherwise, person B can write HTML code that will inject Javascript that quietly sends a person's session information to a remote location, which then allows for easy hijacking.
Also, the 2-factor auth of an emailed PIN seems a little excessive and cumbersome to me. If it makes sense internally, that's fine, but keep in mind that email can go down, can be incorrectly flagged as spam, be delayed (extremely important), can be intercepted easier than sniffing packets, or may not even be available if the user is on the road without direct access.

It is also not very scalable, since your email volume will grow with your application's usage.

The last thing you want is to annoy your users by making them wait a few minutes in order to get an email before being able to log in, or preventing them from being able to log in at all.

If you want to do 2-factor and you have the capability of distributing things to your users, then use an established method like the RSA token or (less expensive) Yubikey. Otherwise, you're gaining only a little more security at a HUGE cost.
your're talking about HSTS
the only way to mitigate the risk of a MiTM attack (which allows stealing your application's session ID) is to reject any requests on HTTP
I wrote mitigate and not inhibit, 'cause a browser still may contain wrong bindings which you can't control from your application (I'd qualify this as a very low risk)

@gr8gonzo, I disagree that it is safe to create a session for HTTPs only, that's to late as the attacker already controls the connection (see sslstrip)
btanExec ConsultantCommented:
just some thoughts from owasp

SESSION @ https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

- Renew the Session ID After Any Privilege Level Change: For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.
- Web Content Caching: web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers
- Simultaneous Session Logons:  recommended for web applications to add user capabilities that check the details of active sessions at any time, monitor and alert the user about concurrent logons, etc

AUTHENTICATE @ https://www.owasp.org/index.php/Authentication_Cheat_Sheet

- Implement Account Lockout: However, password lockout mechanisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts.

Transport Layer Protection @ https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

- Do Not Mix TLS and Non-TLS Content
- Keep Sensitive Data Out of the URL
- Prevent Caching of Sensitive Data
- Use a Certificate That Supports All Available Domain Names: A user should never be presented with a certificate error, including domain mismatch certificate errors
- Note that the redirect is actually REMOVED in owasp since it is not effective

BEAST was famously exploiting the SSL/TLS1.0 and if interested, check put ssllab

SSL best practice - https://www.ssllabs.com/projects/best-practices/index.html
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now