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.
https://www.youtube.com/watch?feature=player_embedded&v=zEV3HOuM_Vw
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:
http://youtu.be/zEV3HOuM_Vw?t=2m45s
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?
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.
https://www.youtube.com/watch?feature=player_embedded&v=zEV3HOuM_Vw
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:
http://youtu.be/zEV3HOuM_Vw?t=2m45s
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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)
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)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.