General PHP Security Overview

Security and PHP
#1

Hi guys. I hope this is okay. If not, I’m happy to remove it.

This is so important to me as a learning coder (and should be to everyone) so I wanted to put down a summary of my PHP security understanding and do’s/dont’s when it comes to building a php application.

It’s a list that I will maintain with any information/tips/tricks that the experienced members reply with and consists of 3 main topics of which I am aware (at this point) are the main security areas that should be considered.

Let me know if anything should be amended, added, removed or elaborated on.

GENERAL

  • Never trust input from an unknown source, especially user input from forms.

  • Always validate and sanitize data that is not presented directly within your code e.g. user form.

  • Browser side validation e.g. Javascript is not an effective validation method, always use a secondary server side method.

  • Never rely on the $_REQUEST superglobal, always specifically define $_POST or $_GET.

  • Always use the trim() function on $_POST variables prior to validation.

  • Always handle errors effectively within your production environment by : Setting error_reporting to E_ALL || setting display_errors to OFF || setting log_errors to on (to ensure you are able to capture generated errors within your script) || setting error_log to effectively define the path where log_errors should be saved within your site root.

  • Always store application sensitive data files (e.g. database connection include) outside of the public html folder of your production environment. Most hosting companies provide a private html folder that can be used.

DATABASE SECURITY

  • Always use PDO & Prepared Statements for all DB CRUD operations as it negates the risk of SQL Injection.

CROSS SITE SCRIPTING (XSS)

  • Always declare the utf-8 character encoding as the first meta tag in the head of your html pages

  • Implement CSRF (Cross Site Request Forgery) token protection methodology on all form input.

  • Regardless of the source, always wrap generated output to the browser in the htmlentities($string, ENT_QUOTES, 'UTF-8') function.

  • Extra stringent validation methods must be implemented in forms that allow file uploads

If anybody has links to good content anywhere on this forum, that provides a guide or further information to any of the above points, then please share and I will embed them in the post.

/Danny

#2

In my opinion a few things could be changed:
Never trust user input…period!

Validation and Sanitizing data are similar but not the same. Not validating data most of the time will just break the script unless you have some kind error garbage collection code going on. Sanitizing data should be done on user’s input as there are some 3rd party software that actually does a good job in the security department. Though you have to do research to make sure that is the case. I personally don’t consider a HTML form to be 3rdy party, but the code that process the form might be and that needs to be sanitized especially going to a third party script or at least in the format that the third party requires. As that I consider user input as you didn’t write the script yourself.

I had advice from someone long time ago and that was when it comes to security leave it to the security experts to handle it. What I mean when it comes to a person’s really sensitive information, such as any transactions that deal with online purchase, banking or information that needs to be processed in order to get something of value leave to it to a trusted 3rd party script. That is why I will never write a script for an online store as example when it comes to the actual purchase and I will leave it to a trusted 3rd Party Company for the script (PayPal for example).

#3

PHP gives you the option to log errors without displaying them; this advice could be more complete by taking that into account.

error_reporting controls what errors PHP reports. I believe this should always be set to E_ALL to report all errors.

display_errors controls whether errors are displayed to the end user - usually meaning in the browser. This should be on in development environments to make sure you see errors quickly, but should be off in production environments to make sure you don’t show a potential attacker anything useful.

log_errors controls whether errors are logged to a file on the server. You should always enable this in production to catch any errors that have made it onto your live site. It’s not essential in development, but you may find times where it’s useful.

error_log controls where your errors will be logged to if log_errors is set. Make sure this is a path your web server can write to, or you will lose your error logs.

#4

I have actually just created a site for a friend who has a ‘lightweight’ store, but actually at this time does not want to accept payments online. Instead the cart is populated and an online order is generated (via email). He then contacts the person directly to arrange payment by bank transfer, cash or PayPal.
When the times come that he decides to accept online payments, I will as you say, leave that end to the experts and look at different payment gateway options, most likely PayPal.

That being said, I am also working on a script for a company that does not involve transactional payment data, but does involve database crud operations against business sensitive data.
This is the most common scenario for me, the data could be anything, from secret food recipes to product specification and/or pricing data.

For this, it is important that my user login script is robust, along with the crud functions that manage the data. The good thing in this situation is that the users are pre-known. This means I can set up the user account(s) in advance, with no need for random user registration.

I also never use cookies for user login, but stick only with sessions. I know this can annoy some users, as it means they have to re-login every time they close the browser, but for me, there is less chance of their login data being hijacked than than there is by using cookies.
I am also investigating how I can integrate validation of organisational device or user AD credentials with a php live environment.

The other thing that is critically important is to have confidence in the company that is responsible for hosting my production environment. My code can be water tight, but if the host does not know how to secure the environment correctly, it’s all just a waste of time.
Personally I am working with Cloudways at the moment. I am not sure if anyone has any experience of these guys, but they seem pretty solid.

#5
  • GENERAL - Added comment about correct storage of sensitive data include files.
#6

Anytime you use a third party server “someone” or many “someones” have full access to everything on that server.

1 Like
#7

This is very true! 80% of security problems come from server side in my experiance.

Sponsor our Newsletter | Privacy Policy | Terms of Service