PHP Coding/Security Guidelines Checklist

[fionaer]

I'm looking for a complete list of security guidelines for programming and deploying PHP web sites and applications on an Apache (Linux) server. Basically, a "security check list" to run through before finishing a project. I.e.,

1. Cross Site Scripting
2. Cross Site Request Forgery
3. Upload files below web root
4. Disable register globals and error reporting in custom php.ini
5. Sanitize form data that goes into database
etc., etc. (the list goes on)

I used to have something like this with a former employer, but their server died and their security guidelines died along with it (apparently, they made no backup -- sigh)...

I did some searching on the internet and in this forum, but couldn't find a comprehensive, succinct, and complete list of guidelines.
Thanks in advance.
my page

[dianna]

n 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

i. I use CakePHP. The framework itself goes a long way to ensure fundamentally sound and secure coding practices.

[netshet]

This forum is primarily for HTML / XHTML / CSS questions. Some basic PHP is covered, but your question is pretty advanced. I suggest you search the About.com PHP area http://php.about.com/ and ask your question on its forum http://forums.about.com/n/pfx/forum.aspx...hp&lgnF=y.

[daipham]

I do not have much knowledge of the programmer. I think their work is complicated.

[hairtransplant]

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

i. I use CakePHP. The framework itself goes a long way to ensure fundamentally sound and secure coding practices.

2. Incoming data…

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.

ii. Prevention: mysql_real_escape_string($string)

c. Cross Site Scripting (XSS)

i. Definition: Security vulnerability typically found in web applications that allows code injection by malicious web users into the web pages viewed by other users. Examples of such code include client-side scripts (i.e., JavaScript).

ii. Prevention: htmlentities(strip_tags($string))

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.)

4. Sessions…

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.

5. Passwords…

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

i. Use at least sha1() to hash your passwords (do not use md5()) 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.

6. In a custom php.ini located in web root…

a. Disable register_globals

i. Prevention: register_globals = Off

b. Disable magic quotes

i. Prevention: magic_quotes_gpc = Off

c. Disable error reporting

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

i. Prevention: session.save_path = /path/above/webroot/sessions

7. In a .htaccess file located in web root…

a. Disable directory listings site-wide

i. Prevention: Options -Indexes

8. Valuable/Sensitive files…

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.

__________________

[kireanmodie]

Really Very nice information’s you are sharing. It was very useful for me.
______________________________
Kunstige øjenvipper