On Mon, Feb 24, 2014 at 2:55 AM, Dan Egli <ddavide...@gmail.com> wrote:
> I hope you don't mean that seriously. I've developed many applications
> using PHP and have yet to have any of my projects exploited. The logs on
> some of my test projects indicate several people trying to break in (after
> I invited friends and other programmers to try and break in so I could test
> the security of the code), but the only times they got in were when I
> forgot to be careful and took shortcuts I shouldn't have taken in the first
> place. Once I fixed those shortcuts, the attempts all failed. I'll grant
> that this was with Pgsql and not MySQL, but I'm not convinced the separate
> DBMS was entirely responsible (partially, sure, because people did try
> things known to work through MySQL, but they failed naturally enough on
> Pgsql). And please don't ask for any details of exactly what was tried or
> how I got around it. It's actually been quite a few years since I did much
> of any web coding and I don't recall all the details of what I did.
This is a reasonable thing to do, and certainly better than nothing,
but this sort of testing never offers any sort of proof of absence of
bugs. And the thing about bugs is that different ones show up at
different usage scales.
I have a co-worker that likes to tell this story about some code for
products he wrote. The code ran inside telecom switches and handled
call routing, so it was pretty critical that it worked correctly.
They'd build it and test it in-house, and get it to where it seemed
pretty bug-free, and then they'd release it to dedicated testers.
Suddenly, the bug reports streamed in! After a few rounds of this,
they'd fix the bugs and things seemed really stable; then it'd get
released to early customers. Again, mountains of bug reports! And
again, they fixed the bugs, and the product became reliable. At least
until another order of magnitude of growth in the user base, which
suddenly led to mountains of bug reports again!
So, relying on the absence of bug reports or successful break-ins
during any scenario other than full-scale production usage by real
customers (and real, dedicated hackers) is only giving you a false
sense of security. In truth, there are enough components out of your
control that no system that you program will ever be completely secure
or bug-free, but there are certainly approaches that can be taken that
will be far more effective than simply asking a few friends to hammer
on it, or even a few hundred friends.
Unfortunately, few of the tools in use today for building software are
designed with real security and reliability in mind. They're designed
with quick prototyping in mind. Real security and reliability are
expensive in terms of up-front work, the complexity of the tools
involved (both mental tools and software tools), and the procedures
required to ensure that the tools work effectively. It tends to be
cheaper, for a lot of things, to write buggy, insecure software and
just pay to fix any trouble caused later. Alas!
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
