[nycbug-talk] Searching for suspect PHP files...
bcully at gmail.com
Tue Mar 3 16:57:06 EST 2009
On 3-Mar-2009, at 16:26, Max Gribov wrote:
> Andy Kosela wrote:
>> I don't want to speak for Miles here, but I think he meant that PHP
>> flawed by design, and not asking "how to write secure code". It is
>> easy to exploit PHP bugs, that even Visual BASIC "idiots" can do it.
> it is equally easy to prevent them, just like in C you can count
> of bytes in a string to prevent buffer overflows.
Bullshit. It is much harder to prevent a million tiny errors than it
is to exploit a single one of them. One good reason higher level
languages are useful is that they cauterize this point of failure,
making entire modes of failure impossible. This is a good thing in an
insecure world - you're going to have enough issues dealing with the
things the language can't help you with.
>> has been increasingly harder to secure HTTP, as most of the
>> break-ins are done with the help of PHP.
> i would change that to "web upload forms", "url bars in browsers" and
> i bet you can find just as many vulnerable web apps written in other
> languages, and probably just as many backdoor apps in other
> languages as
something of a security hole. There are a number of efforts to close
those holes as well. There are very few people screaming that you
should leave it alone because the security holes are fine. Admittedly,
there are some important differences in their typical usage.
important to lock it down.
All that said, "mostly everything sucks anyway" is not much of an
excuse for your particular pet to suck, although it may be a decent
coping mechanism if you can't use anything better.
> php has frameworks which handle plenty of security for you (read:
> validation/sanitizing), and id argue that learning a framework from
> scratch is easier than a language from scratch..
Believe it or not, sometimes the language itself imposes limitations
on the amount of sanitization and validation you can do at the
framework level. PHP has some of these issues (eval, calling functions
by string reference, and so on). And please don't flaunt the red
herring of "don't do that then."
I know I've argued this before, and I'll probably be doing it until
I'm blue in the face, but just because two languages are Turing
Complete doesn't mean that they are equivalent. It is useful to
analyze and compare languages against each other in order to pick the
most appropriate one for a job. It is therefore useful, when
discussing web application security, to analyze languages and
frameworks in terms of their ease or difficulty in maintaining
security. Trying to drown out any critique of your favorite language
by pointing out that there are others with similar problems, or that
you can still accomplish your goals regardless of the feature set is
ridiculous when the entire point of the exercise is to compare and
contrast languages in a given context.
The question is not "can I do it?" but "how easy is it?"
 HTTP security got you down? Don't use HTTP! Problem solved!
More information about the talk