Hi SEP,
I haven't done much in PHP (saw no need to move from Perl), so I haven't given too much attention to PHP perils.
I think to have heard that a common source of evil in PHP scripts was the auto import of (referring to) global variables (e.g. CGI parameter parsing).
There was a unique setting in php.ini to disable this "feature", but at the cost of rendering many poorly written PHP scripts unexecutable, and forcing coders to rewrite them (probably it's this laziness that makes so many websites susceptible to such worm attacks)
But I think for any "bullet proof" server side scripting/programming, no matter in what language, the same common sense guidelines apply.
As for Perl I can easily repeat them here.
- NEVER trust any client input
(which leads directly to the next premise)
- ALWAYS enforce taint checking
(i.e. treating any client input before further processing, especially stripping off shell meta chars, sql injection, best restricting an allowable char set)
- DISABLE autogeneration of globally scoped vars (in Perl terms this means "use strict"),
in fact there is almost never any need for global vars
- AVOID invocation of external commands
(e.g usage of system(), backticks)
Instead use the language's built-in
system commands (this is also more efficient)
If you cannot avoid them, do use exec() after a complete fork() and prior cleansing of the child's environment and other possibly tainted storage.
- DO use well established and tested modules/toolkits,
so don't write your own CGI parser
(in Perl do use CGI.pm)
These are just a few rules that came immediately to my mind.
Because there was so much widespread usage of rotten Perl code the advocators of Perl felt real concern for the language's reputation that they started this project to substitute this "idiotic Perl" code:
http://www.mag-sol.com/talks/idiotic/ The bugtraq you cited addresses XML-RPC.
XML-RPC or SOAP code has to be treated with the same sort of precautions as any CGI code.
In fact XMLRPC or SOAP can even cause greater harm to your system if your SOAP server runs with higher privileges than the webservers' startup scripts automatically take care to restrict.
Also note that SOAP and XMLRPC is plain XML (mostly) over HTTP (though even FTP or SMTP could be used as for SOAP) which most firewalls let pass unhindered.
Perl toolkits such as SOAP::Light (which also contains as a subset XMLRPC) let the coders subclass its methods to implement strong authentication and encryption.
The same must be true for PHP.
But of course this demands more labour from the web service programmer.
Madness, thy name is system administration
