NYCPHP Meetup

NYPHP.org

[nycphp-talk] "The Web is broken and it's all your fault."

Kenneth Downs ken at secdat.com
Fri Sep 15 21:34:30 EDT 2006


Jon Baer wrote:
> I partly blame the language ... I know of alot of people who complain  
> about Java's strict typing/sandboxing + find it cumbersome and have  
> to explain its there for a good reason.
>   
Good programming is in the programmer, not the language. 

If you want a lot of rules, go for Java, you get twice the code, slower 
execution, and just as many blunders, bad interfaces, clumsy db 
strategies, etc. etc.

But good programming can be done in any language.  PHP gives 
flexibility, which in the hands of a master craftsman becomes power.

In the hands of a bad programmer you get bugs -- which he would give you 
anyway no matter what language he was using.
> First, get rid of this stuff ... $_GET['badstuff'] and all incoming  
> defined variables period. 
Hard to imagine if there is a meaningful statement here.  A web request 
is defined by its parameters.


> Second, there needs to be a way to keep your shared libs and  
> extensions up to date programatically w/ some type of scanner or  
> method.  PHP is way too flexible and dependent on the system it sits  
> on ... first you have PEAR libs, PECL C libs, --and-whatever-else-you- 
> compiled-in.
>   
Again, attacking flexibility as a liability.  Very odd.  Live and let live.
> in to PHP (or $_SANITIZE['badstuff'])... 
>   
Won't work.  Sanitizing for return to the browser is different from 
sanitizing for database commands, not to mention other exports you may 
need to execute with their accompanying sanitation.  Some sanitation can 
be reversed, but it is bad form to unconditionally perform an operation 
that you do not always need and may sometimes reverse.

The wise programmer prefers to hold in his hands the raw data as 
delivered by the user, so that it can be handled as such for whatever 
reasons may come, and then sanitizes it for a particular destination 
when sending it there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060915/4d1fa902/attachment.vcf>


More information about the talk mailing list