[nycbug-talk] Searching for suspect PHP files...

[Brian Cully]

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  
>> is
>> flawed by design, and not asking "how to write secure code".  It is  
>> so
>> 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  
> number
> 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.

>> It
>> has been increasingly harder to secure HTTP, as most of the  
>> successful
>> break-ins are done with the help of PHP.
> i would change that to "web upload forms", "url bars in browsers" and
> "javascript injection"
> 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
> well.

	Indeed. There are some strong cases to be made for Javascript being  
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.  
Javascript lives in a much harsher landscape than PHP, so it's more  
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:  
> input
> 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."[1]

	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?"

-bjc

[1] HTTP security got you down? Don't use HTTP! Problem solved!