PHP Coding Guidelines Checklist
1. In general…
a. I’m assuming here that the programmer is not also the server administrator, and that the server admin more or less knows how to configure LAMP correctly and securely by default
i. Of course, if necessary, a programmer can override most PHP settings in a custom php.ini file located in the web root
b. Use an MVC framework
2. Incoming data…
i. I use CakePHP
. The framework itself goes a long way to ensure fundamentally sound and secure coding practices.
a. Sanitize and validate all data contained in $_GET, $_POST, $_COOKIE, and $_REQUEST before programmatically manipulating the data.
b. SQL Injection
i. Definition: Code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.
c. Cross Site Scripting (XSS)
3. Browser requests…
a. Cross Site Request Forgery (CSRF)
i. Definition: Type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
ii. Prevention: Generate a unique “token”, typically when a browser session starts. Pass the token in all POST and GET requests. Following the POST/GET action, check for the existence of the token in the session and then confirm the token sent by POST/GET is identical to the token stored in the session. (An MVC framework like CakePHP makes this relatively easy to implement uniformly throughout your application.)
a. Destroy session data when killing a session
i. After a session is complete (”logout”), destroy its data and don’t just clear the cookie (a malicious user could otherwise just re-instate the cookie and use the session again). Unset all indexes in $_SESSION by assigning it to an empty array.
b. Store sessions as files above the web root or in a database
i. The default path for saving sessions on the server can be hijacked -- especially in a shared hosting environment.
a. Enforce the selection of strong passwords
i. Require numbers, symbols, upper and lowercase letters in passwords
ii. Password length should be around 12 to 14 characters
b. Hash and Salt all passwords
6. In a custom php.ini located in web root…
i. Use at least sha1
() to hash your passwords (do not
()) The hash
() function provides some additional hash options including sha256. Add an “application-specific” salt to passwords before hashing them. Store the salt in a file above the web root.
i. Prevention: register_globals = Off
i. Prevention: magic_quotes_gpc = Off
i. Prevention: display_errors = Off
d. Enable error logging and save log file to a directory above web root
i. Prevention: log_errors = On; ignore_repeated_errors = On; html_errors = Off; error_log = /path/above/webroot/logs/php_error_log
e. Store session data inside a directory above web root
7. In a .htaccess file located in web root…
i. Prevention: session.save_path = /path/above/webroot/sessions
a. Disable directory listings site-wide
8. Valuable/Sensitive files…
i. Prevention: Options -Indexes
a. Prevent unauthorized access/downloads by storing such files above the web root
i. This includes site administration/members-only sections and site/database configuration files!!
b. Use an intermediary script to serve the files inline or as an attachment
c. Keep your scripts(WordPress, PHPMyAdmin, etc.) updated.
d.Only allow access to PHPMyAdmin when you are using it. This prevents people from being able to use zero-day exploits on your install.
9. Uploaded files…
a. Validate file name stored in $_FILES before using it for any kind of data manipulation
b. Be aware that the provided mime type can be spoofed or otherwise wrong
c. Move all user-uploaded files to a directory above web root!!!
d. Don’t execute/serve uploaded files with include()
e. Try to not serve files with content types of “application/octet-stream,” “application/unknown,” or “plain/text”10. Misc…
a. All “utility” files/programs in the web root created and used by the developer during the development of a site/application, that are not intended or required to be accessed by future site users, or otherwise pose some kind of security risk, should be removed when the site goes live.
i. For example, this includes a “phpinfo.php” file (a files that prints the results of phpinfo
()), database utility scripts, etc.