PHP Coding Best Practices - Webinar Recap
Every day, millions of pieces of sensitive data, both personal and business related, are processed by web applications. And every day, applications are at risk of being exposed to new PHP security threats that make that sensitive data vulnerable to attack. With the cost of data breaches averaging over $3.8M and mean time to identify attacks topping 190 days, it’s critical to ensure the security and compliance of your PHP applications and stacks.
Last week, Daryl Wood presented the second webinar in our series, PHP Application Code Best Practices. With lots of examples and coding tips, this webinar took a deeper dive into the PHP coding best practices which help with security.
Those in attendance had a lot of questions! For those that were not answered on the live webinar, Daryl took the time to respond below.
If you missed the session, or just want to watch again the on-demand version including slides is available on our website. If you have more questions, comment down below.
Your Questions About PHP Coding Best Practices
Is there a way to rotate the logger? It’s good to have log, but it’s also important to group them (by day for example).
Yes, full implementation of a logging extension, like PHP Monolog, or a logging component of a framework will have all that capability built-in and is a suggested use rather than the simple Logger class component introduced in the webinar. Then, it's a matter of configuration. My goal with the logging part of the presentation was to show a way to segregate the log entries by severity.
Isn’t it easier to add an error-handler function to the PHP framework, instead of setting up a virtual host?
These are two different beasts in a sense that we are talking about web server access and error logging, and PHP error logging. That said, web server access and error logging are, by default, centralized to a location relative to the web server installation. PHP error logging is also centralized if just enabled in the configuration. When enabled, PHP logging is directed to the Linux syslog by default. However, grouping PHP error logging, along with Linux system log entries, into the overall Linux syslog creates a bunch of log content that can be difficult to manage and parse. Regarding the handler, and assuming you are working with a framework, most frameworks will provide the logging handler mechanism and target the logging to the Linux syslog as a default. That's okay if you really want to parse and manage all that log content. It's up to you to determine what your needs require. For sure, logging is a challenge to set up, manage, and parse.
You can think of the Logger class, as shown in the webinar, as a simplified version of more comprehensive tooling for that purpose. The virtual host configuration, as shown in the webinar, pertains to web server access and error logging, and directs it to a dedicated host location. This segregates web server logging for a dedicated web application and is best when hosting multiple sites on a given host. But, keep in mind, by directing the web server access and error logging to a dedicated host location, and creating a dedicated location for PHP error logging makes it much easier to parse and manage the types of log entries being made.
Why no bound parameter examples?
Assuming that the question is in reference to the logging part of the webinar, in a sense, there were bound parameters when simulating post and get payloads in the examples. If the intent is to use an input parameter in a log entry, that is easy to do just add it to the built log entry string.
If you have multiple websites on a virtual server can you setup different php.ini files per a website?
That's an interesting question and one I would be interested in understanding the use case. By default, a web server parses a given php.ini configuration on startup, and that configuration is then set for run time for the number of hosts registered with the web server. However, the Apache web server provides a custom configuration capability in a file called ".htaccess" that, on a directory by directory basis, is used to tailor the Apache behavior when parsing the directory code contents. The .htaccess file can also configure the PHP engine, to a limited degree, on a directory by directory basis. There's also a .user.ini file, also directory-specific, that tailors the PHP parser behavior based on the code found in that directory.
Why do we store the log in /var/www/rockets? The website is accessible from *:80. I think someone can access it via *:80/log.
Part of the effort of configuring a web site includes a restriction on path access to the source code, log, cache content, etc. As mentioned in another question, the web server has a configuration file ".htaccess", that is used to restrict and control web server access to public resources only, not source code and log content. Then, when properly configured, it is not possible to access restricted content.
You didn’t mention anything about altering the username, especially not using "admin". Would you agree this is a best practice?
Absolutely. As a security "defense in depth" measure, which is employing multiple measures to prevent attack penetration, doing so can help to thwart attacks targeting those names.
Can you use ctype_alnum method in the place of real escape string?
Using ctype_alnum() is only one way to validate input, there are multiple ways of doing that based on the type of input received. The real escape mechanism is but one way to "escape" input date before directing to output, and is the second prong approach to dealing with properly handling input. In the context of echo output, the htmlspecialchars() function provides an adequate escaping mechanism for most output. In the context of using the PDO library and executing read, write, update, and delete operations on a database (which is output) the PDO library provides that mechanism automatically.
What is Access Control List (ACL) as you mentioned in one of the code samples?
ACL is an acronym for describing a mechanism to control access to system resources. For example, if a get request for an image is made, should the user, by role, have access to that image? Or, should the user requesting a database operation, or any other type of state change, be able to do that? That's what an ACL provides. The ability to define roles and resources the roles have access to. This is one of those critically important security components missing in many web applications.
What is a PHP error level?
PHP has the capability of reporting many different types of errors, or error levels. The term "error" used in this context, is a generic reference to the grouping of error types, including non-terminal warnings and notices. Some examples are listed here. Some errors are thrown by the parser, some by the code as directed by the developer.
How is the E_USER_ERROR used?
This error is the same as the system E_ERROR, except thrown by a call to the trigger_error() function within code. E_USER* errors are a result of this trigger function.
Learn more about PHP training from the basics, through cutting edge topics, and on to certification by visiting our training center.
Ensure the security and support of your PHP by learning more about our PHP long-term support programs.