On Mon, May 11, 2009 at 16:55, Mike Cunningham <mike.cunningham@xxxxxxx> wrote:
He remembers past stories about lots of security holes on PHP applications, and scripted attacks
against php web applications. He does not know if these flaws were due to just bad design/coding on the
part of the developer or something inherent in the way PHP works. Does anyone on this list have any
experience in this area?
There are two things you have to distinguish:
a) Security holes in PHP itself
PHP comes with many additional functionality like image processing
built-in. As PHP itself is written in C, and many of these extensions
are also written in C, there are several inherent issues with this,
especially image processing and other libraries are prone to errors.
Most of these issues are mitigated on modern platforms that use ASLR,
NX and other security technologies. I do not know if PASE does use
such security technologies.
b) Security holes in PHP applications
Most of these security holes come from the fact that improper
programming techniques are employed by inexperiences and naive
programmers, that do not work with a "security first" mindset. Most of
these issues are not PHP specific, though they are a lot more
prevalent in PHP because PHP seems to attract these people. There also
many howtos and posts on the web that incorrectly to tell people to
use those improper programming techniques.
Previous versions of PHP also used inserted variables from the user
directly into the global variable namespace - for example, calling
foo.php?foo=bar set the global variable $foo to bar. Almost every PHP
deployment now uses register_globals = off, where you had to use
$GET['foo'] instead to retrieve the same value.
The most common error is a so-called SQL-Injection. This happens when
content from the user is used as part of a concatenated SQL query.
(Code is for example purposes. I haven't tested this, they're supposed
to convey the general idea on how this works - PHP's Magic Quotes
tries to eleviate some of these problems, but they catch only the most
blatant attempts - like the one below).
For example:
mysql_query("DELETE FROM FOO WHERE ID=".$GET['id']");
Now, a malicious user might call foo.php?id=4;DROP TABLE FOO
And now table FOO will be gone.
The proper way to workaround this is NOT to haggle with magic quotes
or trying to do quoting manually - instead you should always use
prepared statements. This looks like this:
$statement = $db_connection->prepare("SELECT thing FROM stuff WHERE id = ?");
$statement->bind_param("i", $id);
$statement->execute();
Security depends on the programmers, the auditing process, the
testers, security methology, etc. Security by obscurity does not work
- using RLA and CGIDEV2 does not alleviate you from ensuring that your
code is secure and works.
I've seen a CGIDEV2/RLA web application that was secured by using
Javascript. Using a web browser without javascript allowed you to do
EVERYTHING. This does not indicate that CGIDEV2, RLA, RPG or the IBM i
is insecure - it just means that when programming, much care needs to
be taken for it to be secure - regardless of platform.
Also - use HTTPS. Many IBM i shops run unencrypted telnet - getting
access to an account with many privileges is easy as pie this way (arp
spoofing, MITM).
midrange.com
