Slashdot Mirror
PHP Security Consortium Launched
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."
I guess you missed the PHP Security Guide?
:-)
They must have offices next door to the MySQL Data Integrity Consortium and the Internet Explorer Web Standards Consortium.
Nice. It'd be good to see an audited set of widgets made available for say, secure database logins and file dissemination which we know to be approved by expert eyes.
---- death to all fanatics
Drop all insecure legacy features like "register globals".
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.
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.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
(I also posted this on the CAPATCHA topic, but I think it's relevant here too).
.jpg file, so two people requesting the page at the same time will see the same image (the last generated one).
Too bad that that example on that site of 'an international group of PHP experts dedicated to promoting secure programming practices within the PHP community.' is flawed.
It always writes to the same
If these are the PHP experts on secure programming, I am now really worried.
--
If code was hard to write, it should be hard to read
The code says:
and:
$image = $captcha->getCAPTCHAAsJPEG();
$handle = fopen('captcha.jpg', 'w');
fwrite($handle, $image);
fclose($handle);
So, assume this happens:
- Client A requests the site
- Client B requests the site
- PHP engine process request for A: generates a random string 'abcde' and creates the captcha.jpg for this 'abcde'
- PHP engine process request for B: generates a random string 'fghij' and creates the captcha.jpg for this 'fghij'
- Due to some network lag (200ms), A will now request 'captcha.jpg'
A will see 'fghij', but the session for A will have 'abcde' set. This means that A cannot validate himself.
The problem here is ofcourse that the file is always the same: if you would use a PHP file that generates the images for a request (based on the sessionid from a cookie), you would be safe.
--
If code was hard to write, it should be hard to read
It is so refreshing to see these issue being dealt with head-on. The larger issue to me, however, is that PHP more than any other language these days is begging for coding standards and "best practices" -- of which security is an important part. As I mentioned in my blog, I am considering writing an article about this for the next issue of IPM.
This attitude is in no small part responsible for the generally terrible security of web-based applications. Security is *not* a set of "audited widgets". You have to know what to do and what not to do - there's no magic widget that is going to secure your application. You *can't* write a general purpose, secure widget for exposing files over the internet without the end developer knowing what they're doing.
So what do you want? People who don't know how to write secure code are writing *insecure* code with PHP. Should they
... seems to me if you have configuration options for the private folder and a callout to a user defined function to check credentials (ok, so they might need to sorta understand this), it wouldn't be too hard ..
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
---- death to all fanatics