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 <[email protected]> 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: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
