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.
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).
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 leastsha1() 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.
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.
__________________
Regards, R.J.
Last edited by chump2877; 12-07-2011 at 11:10 AM..
Reason: Updating some things -- added some links
Thanks Zangeel, that security "checklist" is OK, but it is very basic and doesn't include everything that I'm looking for (from memory -- of course, if I remembered everything, I would just make my own list!)...and, also, I was a little unclear in what I was looking for: I'm looking for "advanced" security guidelines as well as "advanced" coding guidelines in general ("advanced" including basic as well as more sophisticated measures)...and the list need not expound on every technique -- just list them (makes it easier to audit my applications in true checklist fashion), and include everything. You might almost describe the checklist as a coding guidelines (including security guidelines) "cheat sheet"...
Again, I wish I had made a copy of what I was using earlier, but alas it appears to be gone forever. It was a tool that I used to audit my work against a loooong list of general coding and security guidelines, covering the gamut of proper coding, site/app deployment, and security techniques. I'd even be willing to pay for something like this if I could find what I was looking for...
You're not going to find the "ultimate" guide unfortunately because as technology improves so does the methods to get by security. But you've already got the most important ones down, sanitization of database inputs, cross site scripting. A few others i'd note are things like using "includes" for example if you include pages based on $_GET, make sure to have "safe" words in an array, or scan your directories to make sure what theyre requesting in the $_GET variable is OK and not harmful.
Making sure directories and files are safe and secure (i.e. not all CHMOD'd to 777) if you're proficient at php, then you'll also know the weakspots of your codes.
Security is a question that can be added to infinity. Maybe others can post what they think is the most secure way of doing things, and what they've learned is good practice. Those were just a few off the top of my head.
Security can be added to inifinity, but it behooves programmers to be very thorough (anal, even) about the security of their apps -- especially for those who do it for a living. If a customer's web site or app is breached, your customer loses money and you know who they are going to blame.
Ideally, you shouldn't be using GET to collect and manipulate user data at all. POST only. Especially in administrative sections of web sites.
The link you provided looks promising for php.ini configuration. I'll read through it later. I also found this, but haven't read through it yet. I need something really thorough, that is recent, and then I can add to the list as new coding practices evolve.
The company I worked for "had" an "ultimate guide" for general coding practices, as a part of their intranet wiki, and unbelievably they did not back up the wiki content. It was a valuable resource for me that may be hard to replace.
As an aside: It might be a good idea for a coding forum such as this one to create a sticky post in the PHP board dedicated to documenting good coding practices, in list format. Then the post can be continually updated over time to accomodate new techniques. That would be a great resource, and similar to the company wiki I was referring to at my old job.
I disagree, $_GET is a powerful tool in the PHP aresenal, I'm a big fan of the MVC framework, with basically pulls all pages through one central index.php file, then using mod rewrite we can wok in different looking URLs, the method can be very safe if you know what you're doing with it, maybe using $_REQUEST is a bad idea because of variable overriding, since it also reads POST and COOKIE data. I wouldn't be quick to knock off a major way of doing things.
I disagree, $_GET is a powerful tool in the PHP aresenal, I'm a big fan of the MVC framework, with basically pulls all pages through one central index.php file, then using mod rewrite we can wok in different looking URLs, the method can be very safe if you know what you're doing with it, maybe using $_REQUEST is a bad idea because of variable overriding, since it also reads POST and COOKIE data. I wouldn't be quick to knock off a major way of doing things.
Definitely do not discredit the $_GET statement. That is one of the best ways to make your website user friendly and get you ranked higher in search engines. Just be sure to validate every little piece of data you take from there. I think what Chump maybe suggesting is that you do not post any highly secure data in the $_GET statement. Ex. usernames and passwords
But take a search page for instance. If you only use a $_POST statement the user will have to resubmit the form every time they want to search for the same thing. Say a person needs to check once a day to see if any new products match his search.
Instead of resubmitting $_POST data every time, if the $_GET statement was used he could retrieve them by just bookmarking the url.
Regarding GET, sorry for the confusion: I guess I was just warning against using GET to alter stored data. Shouldn't be done. For example, a text link used to add, update, or delete data in a database is not a good idea. For retrieving data (i.e., serving web pages, search functions), GET is often more or less necessary and sufficient as long as its contents are sanitized.
Regarding the security guidelines I was seeking: What I might end up doing here is taking it upon myself to amass an "ultimate" coding checklist, since I can't seem to find everything I need in one place. After I put it all together, or as I put it together, I can incorporate the list into this post. Then I can email a forum admin and request that this post (or a derivation of this post) be made into a sticky. In the future, as new coding techniques emerge (or if I just missed something), any members of this forum can add to the list to keep the list current. Sound like a good idea?
__________________
Regards, R.J.
Last edited by chump2877; 09-11-2009 at 09:05 PM..
Well I spent a couple of hours and tried to regurgitate and research the concepts that I had in my previous list of PHP coding guidelines. The following is what I came up with. If there are any glaring ommissions, please let me know, and I'll add them to the list. If I goofed something up, I'd like to hear about that, too. I'd like you guys to help me make this list near bulletproof, but practical at the same time (if that makes sense), for developers.
When we get to the point that this thing is "sticky" material, I'll contact a forum admin and see if we can make this a permanent sticky thread for the PHP forum here. So your input regarding the following list is invaluable in helping create a great resource for PHP coders visiting this fourm!
Thanks for the help!!
Edit:Moved the list to the first post -Inigoesdr
__________________
Regards, R.J.
Last edited by Inigoesdr; 07-11-2011 at 01:33 AM..
The Following 5 Users Say Thank You to chump2877 For This Useful Post:
1. Using a framework. This is less of a guideline and more of a recommendation. I think frameworks are bloated and unnecessary and I certainly never plan on using one - but I can still organize my code and implement strong security techniques.
2. Password length. Most users would have trouble remembering a password 12-14 characters long. Yes, it is good to have long passwords, but 8 characters minimum is a little more reasonable.
1. Using a framework. This is less of a guideline and more of a recommendation. I think frameworks are bloated and unnecessary and I certainly never plan on using one - but I can still organize my code and implement strong security techniques.
2. Password length. Most users would have trouble remembering a password 12-14 characters long. Yes, it is good to have long passwords, but 8 characters minimum is a little more reasonable.
1. I acknowledge that using a framework is my recommendation. Still, the fact remains that most professional programmers use some kind of framework to work on their projects. So there must be some merit to them. Rather than expound on the advantages of programming frameworks here myself, I'll provide you with a few links that I quickly found:
Rapid Application Development framework
I would Google these keywords and research what all of the fuss is about. In terms of code organization and security, the level of code abstraction in frameworks facilitates more organized and concise code, and effectively automates secure coding techniques (a high degree of security is already assured just by implementing and building on top of the framework's core code).
2. The strength of a password will vary depending on the application and the security required. For example, sites that protect access to sensitive data (i.e., bank/merchant account info, credit card numbers, social security numbers, etc.) obviously warrant stronger passwords than a WordPress blog. In any event, hackers are becoming more and more adept at cracking "weak" passwords. A few links on password strength:
I would recommend not just moving the location of the sessions, but rather storing them in a database and not in a file. No matter where you tell php to store the session in a file it can easily be read if an attacker can place a script on the server and access it through the web. Also make sure to encode all session data so that it cannot easily be read.
Thanks for the great input so far, guys and gals...
As soon as I talk to a forum admin and figure out how to edit the list inside this sticky post (currently I can't), I'll start integrating your ideas into the list...so keep the ideas coming, and eventually I'll get them in there...
Before you post, read our: 
PHP Coding/Security Guidelines Checklist
