Building Secure PHP Apps

Building Secure PHP Apps

English | 2015 | 102 Pages | PDF, EPUB, MOBI | 10 MB

Do you ever wonder how vulnerable you are to being hacked? Do you feel confident about storing your users sensitive information?
Imagine feeling confident in the integrity of your software when you store your user’s sensitive data. No more fighting fires with lost data, no more late nights, your application is secure.
In this short book I’ll give you clear, actionable details on how to secure various parts of your web application. You will also find scenarios to handle and improve existing legacy issues.
Several years ago I was writing a web application for a client in the CodeIgniter PHP framework, *shudder*, but CodeIgniter didn’t include any type of authentication system built in. I of course did what any good/lazy developer would do and went on the hunt for a well made library to supply authentication capabilities. To my chagrin I discovered that there weren’t any clean, concise libraries that fit my needs for authentication in CodeIgniter. Thus began my journey of creating Ion Auth, a simple authentication library for CodeIgniter, and a career long crusade for securing web applications as well as helping other developers do the same.
Here we are years later, a lot of us have moved on to other frameworks or languages, but I still repeatedly see basic security being overlooked. So let’s fix that. I want to make sure that you’ll never have to live the horror of leaking user passwords, or have someone inject malicious SQL into your database, or the suite of other “hacks” that could have been easily avoided. Let’s make sure we all get home on time and sleep well at night.
This is a quick read, at just over 100 pages. This is a handbook style guide to specific items you can act on. The following sections will be covered:

  • Never trust your users – escape all input
  • HTTPS/SSL/BCA/JWH/SHA and other random letters, some of them actually matter
  • Password Encryption and Storage for Everyone
  • Authentication, Access Control, and Safe File Handing
  • Safe Defaults, Cross Site Scripting and other Popular Hacks

HTTPS/SSL/BCA/JWH/SHA and Other Random Letters; Some of Them Actually Matter.

Once again, it’s time for a little story. In October 2010 Eric Butler released a Firefox extension named Firesheep to highlight a huge problem on the web that most people hadn’t been paying enough attention to. Firesheep allowed any regular ol’ user to watch the non-encrypted traffic on their local network and then hijack other user’s sessions. Firesheep exploits a type of man in the middle attack, sidejacking. Sound scary? It should, because it is. Maybe you’re thinking, well this is conjecture. Alright fine, facts in. Let’s walk through an illustration to make the point.

It’s December 2010, Jane is out of town on a work trip for Achme Inc and is staying at a Hilton Garden Inn, it just so happens to be the same hotel that John is staying at. John is in the running for a position that Jane is also trying to get. Jane recently heard about Firesheep on the news and is in a mischievous mood. She logs on to the hotel wifi and runs Firesheep. Luckily for Jane, John is using the wifi and she sees that he has an unsecured connection to their company web email portal. With one click she is now logged in to John’s email account. Just take a second and think of the trouble she could cause him, the private things she has access to, the general control/chaos email can exert in someone’s life.

This type of exploit, session hijacking via unencrypted network traffic (aka sidejacking), has always been possible by those that knew what they were doing. Now with the release of Firesheep this is possible by anyone that knows how to download an extension and click a button.

While you go download Firesheep, (yea thats right, I know what you’re doing you jerk) you might be thinking that this is a horrible thing to happen. Quite the opposite actually, this has spurred web companies to finally get off of their respective laurels and take HTTPS seriously. Gmail, Facebook, and Twitter now all default to using HTTPS throughout their entire site. Previously the standard had been to only encrypt login pages, which secured the user’s login credentials but left their current session open to hijacking as in our example above.

Password Encryption and Storage for Everyone

You should know how this works by now. Chris is a junior developer working for Marvel Comics12 web team. It’s an abnormally hot summer in Burbank. He has just been tasked with building the login functionality for the new web/tablet comic portal his team is building. His “team” really means Chris and the other developer. Chris might have forgotten to wear deodorant today, why is it so hot.

Chris plans out how the login system will work. It’ll have the normal things you would expect, login/logout/forgot password/etc… In regards to passwords he’ll need to store the user’s password, compare it on login, and then email it back to the user if they forget it. Minutes pass. As he thinks through each part of the login process he starts to worry about the security implications of having users’ passwords available to read by anyone who has, or gains, access to the database. He knows he should encrypt the passwords but what about decrypting for login? Or when a user forgets their password?

After researching for an excruciatingly boring 45 minutes Chris decides that he needs to use PHP’s built in mcrypt_encrypt() and mcrypt_decrypt() methods. Chris is pretty stoked, secure encrypted passwords and all the dirty work on encrypting and decrypting is done by PHP. He’s going to be done with this project in half the time quoted.

That my friends (we’re friends right?), is why when you reset your password on you get your plain-text password sent to you in an email. AN EMAIL. WITH YOUR PASSWORD IN IT. This is why you should go change your password to something you have never used anywhere else right now. Go ahead, I’ll wait. I’ll just be sobbing in the corner thinking about all of the people that will be exploited by this soon enough.

The moral of the story, don’t store passwords. Store one way hashes of users’ passwords. Now let’s walk through how to do this right.

Authentication, Access Control, and Safe File Handing

Erica works for a small, local manufacturing company as their programmer and general IT person. She was recently tasked with developing software for the office staff, to upgrade them to the digital age instead of using paper records.

The first step was to have staff members scan documents when they were finished with them. Instead of filing the paper forms, they would be stored electronically.

Development of the archiving system proceeded well. The system consisted of a basic database listing of all the documents, with various filters such as department, date, tags, etc. Nothing too complex; Erica wanted to keep it simple.

The documents displayed to users are filtered based on the user’s department and their position (e.g., user, manager, director). Everything worked well for several months, then it happened. There was a breach of a secure document. The subsequent investigation determined a disgruntled employee gained access to a file meant only for senior management. The employee leaked the document to a competitor to secure a winning bid for a cushy position for themselves at said company.

So how did it happen? Erica has been working all weekend trying to figure it out, when boom, she finds it. It’s so obvious, but she never thought to secure it.

In Erica’s system, files are uploaded and named after the ID fields of their respective database records. An uploaded PDF might be named “13424.pdf”, while the next file, a DOC for example, would be named “13425.doc”, and so on. Erica had secured the document listing that each user sees, but had not considered securing the files themselves when opened or downloaded by the browser. There was no protection to stop a user from gaining access to sensitive documents by simply guessing filenames by incrementing the ID.

The stories are getting a little long, but…