JOB: LAMP Artisan
ddavidegli at gmail.com
Wed Feb 26 02:30:26 MST 2014
On February 24, 2014, Eric Wald wrote:
> In PHP, the easy, obvious way to construct a web page 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 web site is to make each page
> its own script, including a global configuration file if necessary.
All of which is doable to some extent by any language. I personally don't
do this, nor have I done so since I learned much about web security. When I
process user input, the input is processed in a script portion of the page.
The input is, as you put it, sanitized, and in the process, any obvious
exploits are filtered out. After that, after removing anything that could
obviously be damaging, then it actually does something with the input. If
it's going to be sent to a database engine, the first thing I do is watch
for the -- terminator that some people like to try and use, as well as
stripping out ' and " and `. After I've verified that only the
AlphaNumerics are present (and if the job must use them, a single - as well
as , and ; and :), and after I've verified that the input conforms to the
format presented, THEN I'll consider sending it to the database. I've seen
too many times when someone has goofed a C or a Pascal or similar program
with bunged input (deliberately goofed, too) to trust user input directly.
That's just good programming style.
As for the single script, I've only ever done that when there are two or
three script pages total and they share nothing that can't be passed
through the $_SESSION variable. Any time the project has enough complexity
that more than one page will use the same function, I always create a
common.php file (or similarly named) that contains my common functions and
data structures, then I will require_once that file in the main script
page, and go from there. Only functionality and/or content unique to THAT
FILE goes in that file. If the page needs to have a common look (95 out of
100 or so) I'll also include a template so that the user output is
formatted to the common desired look.
> 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.
Well, that would be a problem, yes. But that's due to poor configuration in
the apache config file, not due to any problems in the PHP language. The
same misconfiguration can result in dumping Perl, Python, Ruby, etc....
> 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.
Haven't run into this one myself, but then again, especially on large data
structures, I pass by reference all the time. I've always been designing
memory-conscious, since I started practicing my development on an 8086 with
640K of ram before MS DOS 5 loaded. That really gets tight, so I've gotten
used to doing things in the way that use the least amount of memory to get
the job done.
On Wed, Feb 26, 2014 at 2:59 PM, Dan Egli <ddavidegli at gmail.com> wrote:
> 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
> > 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 brainshell.org> 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.
More information about the PLUG