On Fri, Nov 7, 2008 at 3:39 PM, Christopher Jones <christopher.jones@xxxxxxxxxx> wrote: > > mignon hunter wrote: >> I'm am trying to find some definitive best practises on database >> connections with php on both mysql and oracle. Most security issues come back to a simple concept. Assume anything in your scripts that is not a constant or literal to be a threat. That means any and all user submitted data is a potential attack. Ideally you should also assume that any and all data read in from the database or files is a potential attack. Assume everything is "tainted". Your job then is to "clean" any and all input through inspection and filtering before you use it. I recommend the book "Essential PHP Security" by Chris Shiflett (ISBN 0-596-00656-X). It deals with database security and more. I would be happy to go into more detail on this or provide examples if it would be helpful. >> For example - what's the best usage - prepared statements? And does it >> have to be php 5? I need preferably a one stop shop as opposed to looking at >> dozens of different places. Can you advise a particular book? Website? Prepared statements will prevent SQL injection, but that is only one potential vector for attack. Keep in mind too that prepared statements are not necessary to prevent SQL injection and they aren't always the most appropriate way to do it. That said, they are the simplest way to protect your database. I'll outline a way that a database was used to attack an application. The attack wasn't particularly dangerous, but it was embarrassing for the company involved. In this case, the application took form input from a site visitor and saved it in the database. Then the site owner could retrieve the input and view it. Unfortunately, some visitors decided to put <script> tags in containing a Javascript redirect. Since the application trusted the data coming back from the database (not a best practice), it didn't attempt to filter it in anyway before sending it to the browser. The result was that when the site owner tried to retrieve the form submission data, he would find himself redirect to another website of the attacker's choosing. While no data was compromised in the attack, it did raise doubts about the security of that company's products. This kind of attack could easily be prevented by assuming that the data coming out of the database is tainted and then filtering it with htmlentities(). The result of that would have been that the script didn't run and didn't redirect the browser. This was the solution that the company implemented. I hope this example highlights why it's important to have a full understanding of security and related best practices. Just understanding methods to defeat SQL injection is not enough to ensure that your application is secure, and the aforementioned book will give you a "security mindset" that you can apply to all threat vectors. You also asked about PHP versions. I do recommend you use PHP 5. As mentioned, PHP 4.4.9 is the last release of PHP 4. There is no promise to address any further security issues in PHP 4 if they are discovered. PHP 5 also has other, non-security advantages over PHP 4. Most notable is a robust object model for we OOP types, but I also like decisions they made to bundle in certain modules missing from PHP 4. >> Thanks in advance. PS I would like to switch the current site from jsp to >> php. I was going to look into Zend IDE. Comments? Suggestions? Ugh. That's my comment. I assume we're discussion "Neon" here, the new Eclipse-based Zend Studio. The installation is huge and bloated, and I find it doesn't work very well at all for remote files over FTP. I really didn't care for it. If you love Eclipse, though, you will probably like it. I believe there's a free trial of the Studio, so you should try it rather than listening too much to opinions from the peanut gallery. I use UEStudio. It's not perfect, but it's a very robust, general programmers' editor. It's much faster and it makes difficult Eclipse tasks easy. It also has full Javascript scripting built into it, so it's very extensible. You can download a trial: http://www.ultraedit.com/downloads/uestudio_download.html > Depending on the site needs, consider a DB abstraction layer or a > framework. You can rely on frameworks to provide security to your application, but keep in mind that frameworks can contain vulnerabilities and bugs. They are made by people who can make mistakes. More significantly, if you are making an intensive application, you may find it reaches a point where the framework isn't scalable. I love and use abstraction, but abstraction does come with a performance price. For simple things, this cost is so slight you won't even notice it; but there is a point where the cost becomes significant. There's no simple way to evaluate that, though, because it depends on so many factors: traffic, server resources, specifics of the application, etc. I tend to stay away from frameworks myself, but I do think it's a good suggestion for small applications. I'm playing devil's advocate here. But I think all PHP developers should have a solid understanding of security before they release anything. Frameworks and prepared statements are not an alternative to understanding security issues. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
