Solved

Session hijacking in PHP (see this OWASP video)

Posted on 2013-01-23
4
338 Views
Last Modified: 2013-02-07
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?
0
Comment
Question by:Frosty555
  • 2
4 Comments
 
LVL 34

Accepted Solution

by:
gr8gonzo earned 250 total points
ID: 38813925
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.
0
 
LVL 34

Expert Comment

by:gr8gonzo
ID: 38813938
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.
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 38816592
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)
0
 
LVL 61

Assisted Solution

by:btan
btan earned 250 total points
ID: 38821601
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
https://www.trustworthyinternet.org/ssl-pulse/
https://www.ssllabs.com/ssltest/index.html

SSL best practice - https://www.ssllabs.com/projects/best-practices/index.html
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
Ransomware continues to be a growing problem for both personal and business users alike and Antivirus companies are still struggling to find a reliable way to protect you from this dangerous threat.
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now