Hello all,
I am currently researching security best practices/methods. Can anyone offer
any current resources/recommendations?
My research thus far has included password hashing with salting/stretching,
session hash defaults, session management authentication, and prepared
statements via PDO
On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen j...@cetaceasound.com wrote:
[snip]
On a side note, PHP versions prior to 5.3+ do not allow to set the httponly
flag as a cookie parameter, is there any acceptable alternative for this?
I believe that has been supported since 5.2.0. As for a
Thanks, Andrew! I am unfortunately not even running 5.2..so that helps.
Jen
-Original Message-
From: Andrew Ballard [mailto:aball...@gmail.com]
Sent: Monday, August 08, 2011 9:57 AM
To: j...@cetaceasound.com
Cc: php-general@lists.php.net
Subject: Re: [PHP] PHP Security: Best Practices
I am currently researching security best
practices/methods. Can anyone offer
any current resources/recommendations?
That is a huge arena and the question can not be answered very well
without describing what you are needing to protect. Security in debth
depends upon what you are protecting and
On 8 August 2011 15:08, Jen Rasmussen j...@cetaceasound.com wrote:
Hello all,
I am currently researching security best practices/methods. Can anyone offer
any current resources/recommendations?
My research thus far has included password hashing with salting/stretching,
session hash
Hi all,
I am currently setting up the next generation web server for our company and am
in need of general consulting/advice on php set up security issues.
Any one with knowledge and expierience please feel free to reply :-).
-Grant
H, how about some details on OS, etc
Bastien
Sent from my iPod
On Jun 2, 2009, at 17:26, Grant Peel gp...@thenetnow.com wrote:
Hi all,
I am currently setting up the next generation web server for our
company and am in need of general consulting/advice on php set up
security issues.
On Jun 2, 2009, at 17:26, Grant Peel gp...@thenetnow.com wrote:
I am currently setting up the next generation web server for our
company and am in need of general consulting/advice on php set up
security issues.
For general considerations, start here:
-Grant
- Original Message -
From: Phpster phps...@gmail.com
To: Grant Peel gp...@thenetnow.com
Cc: php-general@lists.php.net
Sent: Tuesday, June 02, 2009 5:53 PM
Subject: Re: [PHP] PHP Security
H, how about some details on OS, etc
Bastien
Sent from my iPod
On Jun 2, 2009
http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?initialSearch=1url=search-alias%3Dapsfield-keywords=php+securityGo.x=0Go.y=0Go=Go
looking at the top 3 on the list here, personally I quite like the O'Reilly
books. Can someone recommend one of these or any other that will give me a
At 11:22 AM +0100 7/4/07, Ross wrote:
http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?initialSearch=1url=search-alias%3Dapsfield-keywords=php+securityGo.x=0Go.y=0Go=Go
looking at the top 3 on the list here, personally I quite like the O'Reilly
books. Can someone recommend one of these
On Jul 4, 2007, at 3:22 AM, Ross wrote:
http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?
initialSearch=1url=search-alias%3Dapsfield-
keywords=php+securityGo.x=0Go.y=0Go=Go
looking at the top 3 on the list here, personally I quite like the
O'Reilly
books. Can someone recommend
Hi,
I would like to introduce a new tool for verifying your PHP application's
security. Our product uses the most advanced static source code analysis for
identifying vulnerabilities in PHP code. Right now we are working with our
version 1.17 which has improved functionality, speed and
I was looking to see if there was a quick checklist of settings for php to
be disabled/enabled in the ini file to make the application more secure.
I'm making sure the apps we come out with dont allow sql injections, or form
injections and so forth, I have just seen some posts about magic quotes
I would look here for an idea. http://phpsec.org/projects/guide/
I think you'll find many opinions on the matter. One thing to
remember is that once the app goes live your job doesnt stop there
you'll need to be just as stringent about security and checking logs
and errors as you were when you
Dallas Cahker wrote:
I was looking to see if there was a quick checklist of settings for php to
be disabled/enabled in the ini file to make the application more secure.
I'm making sure the apps we come out with dont allow sql injections, or form
injections and so forth, I have just seen some
Dallas Cahker wrote:
I was looking to see if there was a quick checklist of settings
for php to be disabled/enabled in the ini file to make the
application more secure.
Although there are some directives worth disabling (register_globals,
magic_quotes_gpc, allow_url_fopen), most
php.ini-anal-retentive-paranoid.
I'm editing mine for that right now, everything is off, the sever has
a keyboard, mouse, monitor no cd/dvd, no floppy, no usb and is
unplugged from the network, there are 6 security guards that surround
you and they give you 5 minutes on a timer.
On 4/6/06, Kevin
Cool Chris I'm going to take a look at that movie. Dallas there is a
section at the top of the ini file that lists some directives and
their status to address security or performance issues, but as Chris
mentioned your code could be as big of a risk as anything so pay
attention to that.
On
Cool Chris I'm going to take a look at that movie. Dallas there is a
section at the top of the ini file that lists some directives and
their status to address security or performance issues, but as Chris
mentioned your code could be as big of a risk as anything so pay
attention to that.
Richard Lynch wrote:
The actual text is:
...in a Web service protocol FOR PHP
Good catch. The summary sent to the list was:
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
Thanks
Santosh:
Personally what I think you did wrong, was to simply paste the header
of that news article into your email. You simply said that PHP was hit
by another security hole, that allowed crackers(sometimes incorrectly
refered to as hackers), to gain access to any php service. I don't
think you
At 02:37 AM 8/26/2005, Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by me)
that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in
snip
Of course, if you ever see a news story that describes PHP as a web
service protocol, you probably want to stop reading immediately. :-)
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
Actually, I wanted to read more, just to find out how badly things
On Fri, August 26, 2005 12:32 am, Chris Shiflett wrote:
Of course, if you ever see a news story that describes PHP as a web
service protocol, you probably want to stop reading immediately. :-)
The actual text is:
...in a Web service protocol FOR PHP
^^^
[emphasis
I have been studying PHP all summer because I wanted to put some PHP
code on my schools web site. I got to school and went to the web design
teacher. I asked him if they had installed PHP on their server. He said
that the district thinks that it would be a HUGE security risk and that
people at
also
PHP HIT BY ANOTHER CRITICAL FLAW
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html
Ian C.
Santosh Jambhlikar wrote:
also
PHP HIT BY ANOTHER CRITICAL FLAW
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
Ian C. McGarvey wrote:
I have been studying PHP all summer because I wanted to put some
PHP code on my schools web site. I got to school and went to the
web design teacher. I asked him if they had installed PHP on their
server. He said that the district thinks that it would be a HUGE
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by
me) that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in php mailing list.
Jasper Bryant-Greene wrote:
Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth.
Jasper is trying to make sure people know the truth. Articles like the
one you mentioned are doing quite the opposite.
I am sorry if i did
Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by
me) that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in php mailing list.
On Thu, 17 Feb 2005 20:47:28 -0600, .hG [EMAIL PROTECTED] wrote:
It makes me wonder how secure in reallity it is to place your UN and
Passwords on a PHP file.
Best idea is to place such information in an include file, which you
can call using the include() or require() statements - and
you could also encrypt the file using one of the encoders that are out
there. Some are free and some are paid for
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 18 Feb 2005 11:42:36 +, John Cage [EMAIL PROTECTED] wrote:
you could also encrypt the file using one of the encoders that are out
there. Some are free and some are paid for
Never thought of that ;-)
http://www.zend.com/store/products/zend-encoder.php?home (Commercial)
Thanks everyone for your input. I was just curios since everyone is so
concern about security, yet some messageboards/CMS use passwords for their
databases on the index page or an include.
--
...hG
http://www.helmutgranda.com
Robby Russell [EMAIL PROTECTED] wrote in message
news:[EMAIL
While back I read in an article that placing UN and PASSwords in a PHP was
not secure. couple of open source programs that I have seen they have for
example
$database = ;
$username = ;
$password = ;
It makes me wonder how secure in reallity it is to place your UN and
Passwords on
On Thu, 2005-02-17 at 20:47 -0600, .hG wrote:
While back I read in an article that placing UN and PASSwords in a PHP was
not secure. couple of open source programs that I have seen they have for
example
$database = ;
$username = ;
$password = ;
It makes me wonder how
--- .hG [EMAIL PROTECTED] wrote:
While back I read in an article that placing UN and PASSwords in a PHP
was not secure.
Well, that's very subjective. In a shared hosting environment, it
certainly does pose a risk. If you place it within document root (don't do
that), it poses a significant
Chris Shiflett mailto:[EMAIL PROTECTED]
on Sunday, January 30, 2005 10:19 PM said:
The PHP Security Consortium has officially launched. The following is
the press release:
Oooh cool! This looks to be a great resource. Keep up the good work
Chris.
Another,
Chris.
--
PHP General Mailing
The PHP Security Consortium has officially launched. The following is the
press release:
--
Leading PHP Experts Join Forces to Establish the PHP Security Consortium
NEW YORK, NY - January 31, 2005 - An international group of PHP experts
today announced the official launch of the PHP Security
http://www.hardened-php.net/advisories/012004.txt
--
Greg Donald
Zend Certified Engineer
http://gdconsultants.com/
http://destiney.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
There are better ways to do this than parsing .jpg files as PHP. One
obvious one is:
http://example.org/image.php/foo.jpg
I believe this broke on a very very very obscure version of IE -- Maybe
even the re-branded IE I ran into one time [shudder].
In theory, it was just IE X.xx.yy, but it
Greg Donald wrote:
The other day a post came across one of those mailing lists discussing
PHP security. One of the posters was describing how insecure PHP's
file upload functionality is and went on to explain a simple method of
attaching exploit code to the end of a jpeg or other image
There are times when one needs to parse a file that ends in .jpg (or
.jpeg) as PHP.
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the URL to determine the MIME type will not
correctly display a URL such as:
Rory Browne wrote:
There are times when one needs to parse a file that ends in .jpg (or
.jpeg) as PHP.
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the URL to determine the MIME type will
not
correctly display a URL such as:
--- Richard Lynch [EMAIL PROTECTED] wrote:
There are times when one needs to parse a file that ends in .jpg
(or .jpeg) as PHP.
I can't think of any, unless it's prove that you can do it. :-)
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the
I subscribe to a number of security mailing lists as I suspect many of
you do, being developers and all.
The other day a post came across one of those mailing lists discussing
PHP security. One of the posters was describing how insecure PHP's
file upload functionality is and went on to explain a
--- Greg Donald [EMAIL PROTECTED] wrote:
The other day a post came across one of those mailing lists discussing
PHP security. One of the posters was describing how insecure PHP's
file upload functionality is and went on to explain a simple method of
attaching exploit code to the end of a jpeg
Pablo Gosse wrote:
Hi folks. I recently set up hosting for my site and have noticed
something which is making me nervous.
If you are really nervous you cannot use shared hosting. Simple as that.
Even if other users don't access your stuff, the root user can. While
it's against the system
Chris,
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher than a
particular directory tree using PHP.
So, a combination of safe_mode and open_basedir should prevent your script
from being
Oh, and I forgot, you can also specify specific include directories to be
allowed for a particular user...
Tim.
At 09:47 PM 9/25/2004, Chris Shiflett wrote:
--- Tim Traver [EMAIL PROTECTED] wrote:
I can guarantee that is not the way it is supposed to be. We
make sure that can't happen by
Tim Traver wrote:
Chris,
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher than a
particular directory tree using PHP.
So, a combination of safe_mode and open_basedir should prevent your
--- Tim Traver [EMAIL PROTECTED] wrote:
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher
than a particular directory tree using PHP.
So, a combination of safe_mode and open_basedir
On Monday 27 September 2004 02:26, Chris Shiflett wrote:
If you do not offer CGI access or any interpreter besides PHP, then I
suppose it's better than nothing, but I wouldn't characterize this as
safe. I suspect that if I were a user on this host, I could give you a URL
that displays another
[snip]
I just published a free article on my Web site about shared hosting:
http://shiflett.org/articles/security-corner-mar2004
In short, what you've found is typical for most shared hosts, and
safe_mode (a directive created to help mitigate this problem a bit) does
little to help. However,
--- Pablo Gosse [EMAIL PROTECTED] wrote:
http://shiflett.org/articles/security-corner-mar2004
[snip]
Hi, Chris. Thanks for that link. It was incredibly informative.
I'm glad you thought so. :-)
I just took your code for the file browser and it was able to
read the information in all users'
[snip]
In short, what you've found is typical for most shared hosts
[/snip]
I've just been reviewing the way sites are housed on my host, and what
directories are readable by the web server and I'm curious to get
opinions on this.
When I use Chris' file browser script, there is a folder called
Ahhh...ok, now you're talking about something else.
I thought we were just talking about the security model of PHP only. Yes,
if a host has decided to offer another means for CGI that isn't safe, then
that is another issue all together...;)
I was just talking about PHP's security model. Safe
Pablo,
I tested Chris's script on our systems, and couldn't browse anywhere other
than my own directories, so it is possible to set php up on shared hosts
that is a lot more secure than what your host has done.
May I ask what host this is ? Is it a major one ?
Tim.
At 02:09 PM 9/26/2004, Pablo
Hi folks. I recently set up hosting for my site and have noticed
something which is making me nervous.
I can't seem to include files outside of my webroot, so I wrote a script
to test permissions using passthru to output the results of a bunch of
ls -la commands to see what I did and did not have
Pablo,
As a shared hosting company myself (http://www.simplenet.com/), I can
guarantee that is not the way it is supposed to be. We make sure that can't
happen by running in Safe mode, using the open_basedir directive, and
making sure the directory tree has the correct permissions so the
--- Pablo Gosse [EMAIL PROTECTED] wrote:
Hi folks. I recently set up hosting for my site and have noticed
something which is making me nervous.
I can't seem to include files outside of my webroot, so I wrote
a script to test permissions using passthru to output the results
of a bunch of ls
--- Tim Traver [EMAIL PROTECTED] wrote:
I can guarantee that is not the way it is supposed to be. We
make sure that can't happen by running in Safe mode, using the
open_basedir directive, and making sure the directory tree has
the correct permissions so the situation you described cannot
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my OSCON tutorial
freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than the slides)
about some of the more important security topics.
I hope you
--- John Nichel [EMAIL PROTECTED] wrote:
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my
OSCON tutorial freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than
the slides)
Thanks for the article Chris. Printing it out now and will read it later.
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my OSCON tutorial
freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than the slides)
about some of the more important security topics.
Nice
--- Burhan Khalid [EMAIL PROTECTED] wrote:
Most of the stuff was common sense to me (and I was glad I
was doing those things unconsciously).
That's good to hear. :-)
Most of the people that have heard me give this talk (which is a few
hundred now) have realized several vulnerabilities in their
PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, August 15, 2004 4:05 PM
Subject: Re: [PHP] PHP Security Workbook
--- Burhan Khalid [EMAIL PROTECTED] wrote:
Most of the stuff was common sense to me (and I was glad I
was doing those things unconsciously).
That's good to hear. :-)
Most of the people
--- Octavian Rasnita [EMAIL PROTECTED] wrote:
I have also read that pdf document and I have found another
interesting advice.
The author says that a good way of hiding the username/password
is to put a file that exports 2 environment variables in a directory
that can be read only by the
Oh thank you for this information. This is very important for me to know.
Yes, this is another thing that I mention in the talk but failed to
include in the workbook. When this approach is being applied to a shared
hosting environment, you want to put the Include directive within a
This news is a bit old, but I have made the workbook for my OSCON tutorial
freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than the slides)
about some of the more important security topics.
I hope you find it helpful.
hi.
one of my clients whom we host a website for has expressed interest in
writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this service.
My concerns are that the client *could* use a php script to access parts of
the file
to
modify read-only scripts.
Hope that's clear!
Richard
-Original Message-
From: Ben Joyce [mailto:[EMAIL PROTECTED]
Sent: 07 April 2004 11:30
To: [EMAIL PROTECTED]
Subject: [PHP] PHP security in a hosting environment
hi.
one of my clients whom we host a website for has expressed
Ben Joyce wrote:
hi.
one of my clients whom we host a website for has expressed interest in
writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this service.
My concerns are that the client *could* use a php script to access
From: Ben Joyce [EMAIL PROTECTED]
one of my clients whom we host a website for has expressed interest in
writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this
service.
My concerns are that the client *could* use a php
--- Ben Joyce [EMAIL PROTECTED] wrote:
one of my clients whom we host a website for has expressed interest
in writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this
service.
How are you not offering it now? Can the client
I know somebody who coded a PHP script that attempts to prevent post
flooding and some other potential security 'flaws'.
I know quite alot about PHP, some things are still beyond my knowledge. I
was wondering if some people could have a look at it to see if it is a
viable way of reducing secrity
request floods and such are not the responsability of the programmer is
it? Sounds more like a sys admin problem? i could be wrong.
Jason
Martin Nicholls [EMAIL PROTECTED] wrote:
I know somebody who coded a PHP script that attempts to prevent post
flooding and some other potential security
no, but i suppose you have options available to prevent them, and it may be
a sysadmins problem, but there is a good chance that it may be your fault, I
can see how if you are a freelance devloper, it may look bad if the client
wants to hire for another job, and your code was the flaw in an
Hi Everyone,
Oddball error randomly shows up when accessing pages on my web hosting
provider. The error message is below.
My account is obb4wine. PHP behaves as if I'm the account budguy when
the script error occurs. A page refresh usually makes the error go
away. The error happens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
PHP Security Advisory: CGI vulnerability in PHP version 4.3.0
Issued on: February 17, 2003
Software: PHP/CGI version 4.3.0
Platforms: All
The PHP Group has learned of a serious security vulnerability in
the CGI SAPI of PHP version
Hi all
i wanted to check with if it is possible to see the contents of a .php
file.
I have heard of the Zend Encoder, but I was wondering how could a
person see my php script ?
Any information in this direction would be useful?
TIA
--Pushpinder Singh Garcha
_
--- Pushpinder Singh Garcha [EMAIL PROTECTED] wrote:
i wanted to check with if it is possible to see the
contents of a .php file.
You can open any normal PHP script in a text editor.
I have heard of the Zend Encoder, but I was wondering
how could a person see my php script?
If you use Zend
On Tue, 23 Jul 2002, Richard Lynch wrote:
This is excluding support contracts for software you paid for -- Once you
pay Oracle enough money for Support Contracts, they have pretty good
support, from what I hear... :-)
They're attentive and responsive and about as knowledgeable as you could
Hello,
when applying patch on version 4.2.1 then in phpinfo(); is still PHP
Version 4.2.1 but SERVER_SOFTWARE: Apache/1.3.26 (Unix) PHP/4.2.2
mod_ssl/2.8.9 OpenSSL/0.9.6d-beta1
Regards,
Michal Dvoracek [EMAIL PROTECTED]
Capitol Internet Publisher, Korunovacni 6, 170 00
restart apache
-Original Message-
From: Michal Dvoracek [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 23 July 2002 4:34 PM
To: Jason Soza
Cc: [EMAIL PROTECTED]
Subject: [PHP] PHP security bug and patch
Hello,
when applying patch on version 4.2.1 then in phpinfo(); is still PHP
[snip]
Well, trying to updrade on Slackware Linux 8.0 and compiling with the GD
(1.8.4) libraries are giving us some headaches. Some of what seems to be
wrong;
...
You're simply looking at the old PHP.
You did stop/start Apache, right?... Cuz the new PHP won't kick in until
you do.
If so,
Who said anything about M$? I don't use their crappy products so I
don't have to deal with their security issues.
I'm the one who brought up Microsoft, I'm saying it's a whole lot better
then the alternatives.
If PHP 4.2 is unsafe then why is it listed at the top of the page for
Hi,
1. Every peice of software has bugs - PHP still bugs - it always will
have. Deal with it.
2. It is no-one's responsibility other than your own to *test the
software*. Anyone using any form of software in a production environment
has at least one test bed to install new versions of software
Well, I'm not sure about the 'you get what you pay for'. Some paid for
software has less support and documentation than PHP!
Justin French [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Greg,
Your attitude stinks.
PHP is a FREE scripting language. Think
Well, I'm not sure about the 'you get what you pay for'. Some paid for
software has less support and documentation than PHP!
In my experience, *ALL* paid-for software has less support and documentation
than PHP.
This is excluding support contracts for software you paid for -- Once you
pay
On July 22, 2002 10:12 am, 1LT John W. Holmes wrote:
[snip]
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
[/snip]
Looks like everyone will be using the new super globals, now... :)
Well, I guess I'm still assuming that in a perfect world, people will
upgrade
IIRC, just about every upgrae has security fixes, you may be hard
pressed to find an older version that doesn't have any big holes in it.
On Mon, 2002-07-22 at 10:55, Ilia A. wrote:
On July 22, 2002 10:12 am, 1LT John W. Holmes wrote:
[snip]
PHP Security Advisory: Vulnerability in PHP
On Mon, 22 Jul 2002, Marko Karppinen wrote:
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Not only did I get to re-write all my apps the past few months because of
the new register_globals default that was imposed by `the php group`...
Now I get to upgrade my PHP
Hey man, if you can't stand the heat, get out of the freakin sun.
Atleast PHP tells you about holes, not like Microsoft who will fix it
six months down the line (if they even admit a hole exists). Plus, if
your running anything past 4.1.2 on production systems, it's your own
damn fault because
)
To: [EMAIL PROTECTED]
Subject: Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0
and 4.2.1
On 22 Jul 2002, Adam Voigt wrote:
Hey man, if you can't stand the heat, get out of the freakin sun.
Atleast PHP tells you about holes, not like Microsoft who will fix it
six months
I actually enjoy all the security releases. They give me something to
do at work!
tyler
On Mon, 22 Jul 2002 11:55:31 -0500 (CDT)
Greg Donald [EMAIL PROTECTED] wrote:
On Mon, 22 Jul 2002, Marko Karppinen wrote:
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and
4.2.1
Quoting Greg Donald [EMAIL PROTECTED]:
It's not about that.. It's about the hell I've already been
through with the new register_globals setting. Then two huge ass
security holes following in the next couple of months after that.
If it doesn't bother you the hassles 'the php group' is
1 - 100 of 164 matches
Mail list logo
