PHP Security Consortium Launched 64
Chris Shiflett writes "We're happy to announce the official launch of the PHP Security Consortium (PHPSC). Our mission is 'to promote secure programming practices within the PHP community through education and exposition while maintaining high ethical standards.' You can read the official press release or visit us at phpsec.org."
Want to make PHP more secure? (Score:3, Insightful)
Use exception handling from top to bottom. Don't allow an error or return value to go unchecked.
Run code in some kind of sandbox by default. Example: fork and chroot each PHP script. Safe mode isn't good enough.
HTML ESCAPE BY DEFAULT. Use a separate set of tags for un-escaped output. Isn't it ridiculous that you have to remember to HTML escape output??? All you have to do is forget one spot, and congratulations, your app is on bugtraq.
Then I'll start to take PHP seriously.
As long as PHP caters to the bottom 95% ("but if we change that, people will get confused"). I'll look elsewhere.
Re:Want to make PHP more secure? (Score:2, Insightful)
This will fall on deaf ears here. This is a Perl Zone. Reason with respect to PHP does not work here, because people here fear php. And that's a shame because as you say, PHP is already taken very seriously by some of the web's largest and most heavily trafficked sites. Those who discount PHP may find themselves being passed over for some very good jobs on very tasty projects.
But what's funny is that many of the "problems" that people here have with PHP are present in their preferred language, Perl, C, C++, whatever. The solution is understanding the language you are working in, whatever it is, and using good programming habits.
Glad to see it... (Score:3, Insightful)
I realize that this is a huge generalization. Don't get me wrong; I don't reject a program outright if I find that it was created with PHP. PHP does, though, raise an eyebrow.
All things being equal, I do reject a PHP app quicker than a non-PHP app if it shows a similar number of questionable or just flat out poor security defaults or is designed with little attention to security. It's often harder to deal with and keep up to date as the original branch of the app is updated -- raising the frustration as time goes on.
Coding Standards In General (Score:2, Insightful)
Re:Good (Score:4, Insightful)
a) write crap code themselves, or
b) use tested and audited code, save themselves some time and get to see how it should be done in the process.
And while there is no 'magic widget' that will fix your whole app, it's definitely possible to create a widget which will handle the login properly (probably where most SQL injection attacks occur), perhaps force a sensible password policy and maybe some code to test for some common security flaws (whether in code or against a live server).
And - WHY can't you create a general purpose secure file streamer? I'm curious