PHP and filepro - login lesson

[Fairlight]

On Thu, Apr 12, 2018 at 05:07:57PM -0400, Jose Lerebours via Filepro-list thus spoke:
> lol, simple but probably functional.  There are so many login
> templates out there and yet, I do not think I ever wrote two exactly
> the same.

Lack of consistency (when not intentionally adopting a better methodology)
is problematic.  That's one of the fastest ways to oversights which can
have consequences.

> (c) In lieu of sending stdin as parameters, write to a file and send
> the file as source for filePro to import

Usually, yes.  However, if you're disk-bound instead of CPU-bound,
sometimes it actually makes more sense to skip the extra performance hit.
Sometimes.  I wouldn't normally advocate for doing so, but I have seen
instances where it would be sensible and increase performance on busy
systems.

> ~/bin/phpLogin [file source] [file out]
> 
> Writing to a file eliminates your need to worry about escaping and
> decoding 

It does -not-, however, eliminate your need to sanitise your data in
general.  You may not need to do so immediately for the first SYSTEM call
out, but if that data is stored in an unsanitised format, then later
introduced by another programmer (or someone who can't be bothered to do
something the same way twice and forgets what was done how because they're
not methodical), then you introduce a security and/or stability problem
farther down the road.

... Since file_put_contents() will not open a shell should
> the user attempt to inject/attack your site.

Writing to file doesn't protect you in all instances; only the immediate
one you're bypassing.

> This is exactly why I wrote fp2php.com but gave up on it since no
> one thought the community needed PHP at all  :-(

There is nothing PHP can do which can't be done in Perl or mod_perl more
securely (and just as efficiently, in the case of mod_perl), by a better
class of programmer.

The number of actual serious security flaws in Perl in the last fifteen
years numbers around three.  Two of those revolved around strftime(), for
some reason.

The number of PHP vulnerabilities is incalculable.  Back when SANS @RISK
used to be more than just a regurgitation of the same seven exploits for
three months running, surrounded by ads for their 'training', they -used-
to list all the known PHP exploits, and known exploits for software written
in PHP.  PHP-based holes were through the chart every single week.  It used
to take up 3/4 of the newsletter.

ZEND is to blame for the horrible engine and horrible practises (like
dropping a -completely- new PCRE library into a third-pointlevel re-patch
of a security patch they screwed up the FIRST time, a day earlier...because
they're just -that- good).  And the 'programmers' of today are too stupid
to know any better.

PHP is the AOL of programming languages:  Anyone idiot can use it, and too
many do.

m->
-- 
Audio panton, cogito singularis.