On Fri, Nov 7, 2008 at 3:39 PM, Christopher Jones
<[EMAIL PROTECTED]> 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
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
>> 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
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
it's very extensible. You can download a trial:
> Depending on the site needs, consider a DB abstraction layer or a
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