JOB: LAMP Artisan

Dan Egli ddavidegli at
Wed Feb 26 02:29:26 MST 2014

On February 24, 2014, Levi Pearson wrote:

> 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.

Nothing does, really. I've seen programs that are in use for years suddenly
get a flurry of bug reports because someone tried something no one else
tried and it caused problems, so they posted it and everyone did it. You
can never be 100% sure of bug-free status. But you can get reasonably sure.

> And the thing about bugs is that different ones show up at

> different usage scales.

I've seen that, too. That's one of the reasons I frequently use Apache
Bench and/or Siege. I can flood my page with requests, and have a log file
that is only enabled during testing that logs what output would have been
sent to the browser (since the output is actually discarded with ab and
siege). After sending in, say  25k requests, I can spend a few hours
looking over the log files and when I see a bug in the output or when php
reports an error either in it's own log files, or in apache's error log
file, then I know there's something to fix.

> 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.

Again, this is where siege and/or ab come in. I've siege'd my pages to look
at them. Then I'll have friends try all sorts of things, deliberately
trying to break things. I'll fix what they report, the re-siege or re-ab,
and try again. Is it guaranteed to become bug free? No. Of course not. But
it gets it as close to bug-free as I can reasonably make it before entering
production. Once something enters production you're almost guaranteed to
find more bugs because either there's a bug in a component or your code
that no one thought to try until now, or the simple fact is that you never
managed to get your system with a heavy enough load to see this bug which
only appears at certain load points.

--- Dan

On Mon, Feb 24, 2014 at 11:32 PM, Eric Wald <eswald at> wrote:

> On Mon, Feb 24, Michael Torrie wrote:
> > Dan's question is, what is it about PHP that causes it to have such a
> > horrible reputation for security?  What makes other languages better for
> > real-world web stuff?  What are the trade-offs?
> In PHP, the easy, obvious way to construct a webpage is to intermingle
> hard-coded bits with unsanitized user input.
> In PHP, the easy, obvious way to interact with a database is to stuff
> user input straight into a string and use that as your query.
> In PHP, the easy, obvious way to build a website is to make each page
> its own script, including a global configuration file if necessary.
> Some configurations of PHP and/or Apache make it possible to view the
> source of a PHP file from over the web, including the aforementioned
> global configuration file.
> In PHP, passing an array to a function makes a copy by default, making
> it easy to run out of memory, simplifying denial-of-service attacks.
> Other languages make it harder to build web stuff in the first place,
> making the easy, obvious way to use a framework.  Most such frameworks
> are more inclined to make security a high priority.  Django's template
> system, for example, escapes strings by default.  SQLAlchemy makes it
> easier to use parameterized queries than to build the query string.
> Then again, PHP doesn't have buffer overflow and null pointer problems,
> so it might not be the absolute worst language for the web.
> - Eric
> /*
> PLUG:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */

More information about the PLUG mailing list