[PHP] PHP Security: Best Practices
Hello all, I am currently researching security best practices/methods. Can anyone offer any current resources/recommendations? My research thus far has included password hashing with salting/stretching, session hash defaults, session management authentication, and prepared statements via PDO in addition to basic PHP.ini and .htaccess server settings and properly escaping and validating input/output. On a side note, PHP versions prior to 5.3+ do not allow to set the httponly flag as a cookie parameter, is there any acceptable alternative for this? Thanks in advance, Jen Rasmussen | Web Development Manager Cetacea Sound Corp P: 763-225-8465 P Before printing this message, make sure that it's necessary. The environment is in your hands
Re: [PHP] PHP Security: Best Practices
On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen j...@cetaceasound.com wrote: [snip] On a side note, PHP versions prior to 5.3+ do not allow to set the httponly flag as a cookie parameter, is there any acceptable alternative for this? I believe that has been supported since 5.2.0. As for a workaround for versions before that, I found this pretty quickly through Google: http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security: Best Practices
Thanks, Andrew! I am unfortunately not even running 5.2..so that helps. Jen -Original Message- From: Andrew Ballard [mailto:aball...@gmail.com] Sent: Monday, August 08, 2011 9:57 AM To: j...@cetaceasound.com Cc: php-general@lists.php.net Subject: Re: [PHP] PHP Security: Best Practices On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen j...@cetaceasound.com wrote: [snip] On a side note, PHP versions prior to 5.3+ do not allow to set the httponly flag as a cookie parameter, is there any acceptable alternative for this? I believe that has been supported since 5.2.0. As for a workaround for versions before that, I found this pretty quickly through Google: http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security: Best Practices
I am currently researching security best practices/methods. Can anyone offer any current resources/recommendations? That is a huge arena and the question can not be answered very well without describing what you are needing to protect. Security in debth depends upon what you are protecting and who you are protecting it from, and also entails your expenses and potential loses compared to what you are willing to pay for protecting your assets. If all you're protecting is a database from unauithorized access, improper access, or accidental sabotage, the answers for what constitute best practices are merely a matter of doing Google searches for what the typical database threats are and avoiding the pitfalls. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Security: Best Practices
On 8 August 2011 15:08, Jen Rasmussen j...@cetaceasound.com wrote: Hello all, I am currently researching security best practices/methods. Can anyone offer any current resources/recommendations? My research thus far has included password hashing with salting/stretching, session hash defaults, session management authentication, and prepared statements via PDO in addition to basic PHP.ini and .htaccess server settings and properly escaping and validating input/output. Best practise can change as new threats and forms of attack become prominent. So. At the top of this list, I'd add This is list is subject to change. Anything you to today may well be circumvented tomorrow. But the principle of Poka-Yoke does suggest that by only allowing valid and appropriate data in to your code, you are drastically reducing the attack vectors. I work in a multi-database and multi-DB Server environment. Nearly/almost always, I use stored procedures rather than building complex queries in PHP. I only allow me and users in the development team direct access to the tables. So, for the application to alter the DB, a stored procedure is written (my apps are accounting related so maybe some flexibility has been sacrificed - but the security is very strong). I use Views either to simple result sets or to XML results depending upon the requirement - again - no access to the underlying tables. The user credentials used for connecting to the DB is different to other user details and it is forced to a specific machine. All this sort of thing is setup once and done. It makes it very difficult for anyone to be able to fake the credentials, gain access to the DB tables or inject data outside of the constraints provided by the stored procedures. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
