Re: [PHP] PHP Security: Best Practices

[Richard Quadling]

On 8 August 2011 15:08, Jen Rasmussen  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 defaults, session management & authentication, and prepared
> statements via PDO in addition to basic PHP.ini and .htaccess server
> settings  and properly escaping and validating input/output.

Best practise can change as new threats and forms of attack become prominent.

So. At the top of this list, I'd add "This is list is subject to change".

Anything you to today may well be circumvented tomorrow.

But the principle of Poka-Yoke does suggest that by only allowing
valid and appropriate data in to your code, you are drastically
reducing the attack vectors.


I work in a multi-database and multi-DB Server environment.

Nearly/almost always, I use stored procedures rather than building
complex queries in PHP.

I only allow me and users in the development team direct access to the tables.

So, for the application to alter the DB, a stored procedure is written
(my apps are accounting related so maybe some flexibility has been
sacrificed - but the security is very strong).

I use Views either to simple result sets or to XML results depending
upon the requirement - again - no access to the underlying tables.

The user credentials used for connecting to the DB is different to
other user details and it is forced to a specific machine.

All this sort of thing is setup once and done. It makes it very
difficult for anyone to be able to fake the credentials, gain access
to the DB tables or inject data outside of the constraints provided by
the stored procedures.




-- 
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security: Best Practices

[Fredric L. Rice]

> 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 who you are protecting it from,
and also entails your expenses and potential loses compared to what you
are willing to pay for protecting your assets.

If all you're protecting is a database from unauithorized access, improper
access, or accidental sabotage, the answers for what constitute best
practices are merely a matter of doing Google searches for what the
typical database threats are and avoiding the pitfalls.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security: Best Practices

[Jen Rasmussen]

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

On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen  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 workaround for
versions before that, I found this pretty quickly through Google:

http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security: Best Practices

[Andrew Ballard]

On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen  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 workaround for
versions before that, I found this pretty quickly through Google:

http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php

Andrew

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Grant Peel]

Thanks for the reply,

Dell R200, Xenon Quad Core 2.8 GHz,, 3GB RAM, 160GB SAS Drive,
FreeBSD 7.0, Developer package, no XWin, mod_security installed,
Apache 2.2.4, Suexec enabled, HTTPS enabled,
Proftp 1.3 (if memory serves),
Exim 4.6,
vm-pop3d, triggered from Inetd,
Spamassassin 3.2 (if memory serves),
MySQL 5.1,
PHP 5, with Sohosin patch,
BSD Firewall, (IPFW),
PERL 5.8.something,

All software installed from port,
INET 6 not enabled,

Server is setup as a virtual server, each domain has its own IP (apache3 
using virtual hosts), no Jails installed.


Each Domain owner has thier own ftp login, no SSH or Telnet access granted.

What I am looking for is to secure ftp from cross site scripting; disable 
any php.ini options that may be flakey (security wise); possibly setup php 
suexec. <- most of all, ensure any scripts installed cannot intrude on other 
sites or be used as rootkits


-Grant

- Original Message - 
From: "Phpster" 

To: "Grant Peel" 
Cc: 
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, at 17:26, "Grant Peel"  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.


Any one with knowledge and expierience please feel free to reply :-).

-Grant


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php







--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Kirk . Johnson]

 > On Jun 2, 2009, at 17:26, "Grant Peel"  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: 
http://www.php.net/manual/en/security.general.php

Kirk

Re: [PHP] PHP Security

[Phpster]

H, how about some details on OS, etc

Bastien

Sent from my iPod

On Jun 2, 2009, at 17:26, "Grant Peel"  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.


Any one with knowledge and expierience please feel free to reply :-).

-Grant


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security books

[jekillen]

On Jul 4, 2007, at 3:22 AM, Ross wrote:




http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350? 
initialSearch=1&url=search-alias%3Daps&field- 
keywords=php+security&Go.x=0&Go.y=0&Go=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

good solid understanding of PHP security?


Thanks,


Ross


Have you seen Pro Php Security by Snyder and Southwell; Apress ?
It appears to be as comprehensive and well written as the subject
can get.
JK

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security books

[tedd]

At 11:22 AM +0100 7/4/07, Ross wrote:

http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?initialSearch=1&url=search-alias%3Daps&field-keywords=php+security&Go.x=0&Go.y=0&Go=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
good solid understanding of PHP security?


Thanks,

Ross


1. Essential PHP Security by Chris Shiflett

Excellent

tedd
--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] php security

[Jim Moseby]

> 
> 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.

The code is the thing, right?  Regardless of how my server's
register_globals (for instance) is set, if I do not use the globals in my
code, it is not in and of itself insecure. Correct?  

Which brings the question, are there any php.ini settings that, in and of
themselves, create security problems?  I mean other than display_errors,
which is obvious.

JM

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security

[Dan McCullough]

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 4/6/06, Chris Shiflett <[EMAIL PROTECTED]> wrote:
> 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 vulnerabilities in PHP
> applications are a result of flaws in the PHP code. There are no magic
> php.ini configuration directives that can make your applications secure
> - not that you were suggesting this, but it's woth explicitly stating.
>
> A couple of years ago, I tried to summarize several good practices into
> a single mantra - filter input, escape output (FIEO). These practices
> don't eliminate everything, but they're a very good first step and can
> provide a solid foundation for secure PHP programming.
>
> I made a movie (webcast, screencast, or whatever you call them) about
> auditing PHP applications, and it also covers filtering input and
> escaping output:
>
> http://brainbulb.com/php-security-audit-howto.mov
>
> There's also the PHP Security Guide:
>
> http://phpsec.org/projects/guide/
>
> We're in the process of writing a second version of the guide, in order
> to address the following shortcomings:
>
> 1. The guide is several years old, so some techniques have been refined
> and/or simplified in the meantime.
> 2. The vocabulary is slightly inconsistent with the rest of the industry
> in some cases.
> 3. Not all major areas are covered, so it is incomplete.
> 4. Some explanations are ambiguous and can yield misinterpretations.
>
> Lastly, I want to point out two of the primary attacks that are not
> prevented with FIEO:
>
> 1. Cross-Site Request Forgeries (CSRF)
> 2. Session Fixation
>
> Hope that helps get you started.
>
> Chris
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security

[Dan McCullough]

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 Kinsey <[EMAIL PROTECTED]> wrote:
> 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 posts about magic quotes and
> >so on and so I was curious.
> >
> >
>
>
> Well, generally php comes with a "php.ini-dist" and a "php.ini-recommended";
> for tighter security, use the "recommended" version.  Examining a diff
> of the
> files could help shed some light, as well.
>
> Of course, some of us could be waiting for the day when they ship with a
> "php.ini-ironclad", "php.ini-stealthmode", or
> "php.ini-anal-retentive-paranoid",
> but I'm not sure those are slated, even for PHP6  ;-)
>
> HTH,
>
> Kevin Kinsey
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security

[Chris Shiflett]

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 vulnerabilities in PHP 
applications are a result of flaws in the PHP code. There are no magic 
php.ini configuration directives that can make your applications secure 
- not that you were suggesting this, but it's woth explicitly stating.


A couple of years ago, I tried to summarize several good practices into 
a single mantra - filter input, escape output (FIEO). These practices 
don't eliminate everything, but they're a very good first step and can 
provide a solid foundation for secure PHP programming.


I made a movie (webcast, screencast, or whatever you call them) about 
auditing PHP applications, and it also covers filtering input and 
escaping output:


http://brainbulb.com/php-security-audit-howto.mov

There's also the PHP Security Guide:

http://phpsec.org/projects/guide/

We're in the process of writing a second version of the guide, in order 
to address the following shortcomings:


1. The guide is several years old, so some techniques have been refined 
and/or simplified in the meantime.
2. The vocabulary is slightly inconsistent with the rest of the industry 
in some cases.

3. Not all major areas are covered, so it is incomplete.
4. Some explanations are ambiguous and can yield misinterpretations.

Lastly, I want to point out two of the primary attacks that are not 
prevented with FIEO:


1. Cross-Site Request Forgeries (CSRF)
2. Session Fixation

Hope that helps get you started.

Chris

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security

[Kevin Kinsey]

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 posts about magic quotes and
so on and so I was curious.
 




Well, generally php comes with a "php.ini-dist" and a "php.ini-recommended";
for tighter security, use the "recommended" version.  Examining a diff 
of the

files could help shed some light, as well.

Of course, some of us could be waiting for the day when they ship with a
"php.ini-ironclad", "php.ini-stealthmode", or 
"php.ini-anal-retentive-paranoid",

but I'm not sure those are slated, even for PHP6  ;-)

HTH,

Kevin Kinsey

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security

[Dan McCullough]

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 were developing.

On 4/6/06, Dallas Cahker <[EMAIL PROTECTED]> 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 posts about magic quotes and
> so on and so I was curious.
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Chris Shiflett]

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 for clarifying.

Chris

--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Richard Lynch]

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 mine]

The subject of the sentence is XMLRPC, and thus it does not
technically call PHP a "web service protocol" -- It labels XMLRPC as a
"web service protocol" which, in my limited understanding of RPC,
would not be considered inaccurate.

Granted, the article is plastered with PHP all over it, to garner
attention, when the Truth is that the flaw is in older versions of
XMLRPC.

Granted, the sentence construction throughout is very carefully
constructed to blame PHP while being technically correct in
assignation of blame on XMLRPC to the careful reader.

Granted the same bug would presumably manifest in XMLRPC for any other
language using that same code-base.

Still, it DOES seem to be technically correct, and has useful
information such as A) an upgrade to correct the issue B) credits to
the people who worked to find and fix the problem.

Seems like I've seen a LOT worse anti-PHP articles.

PS To the original poster:  Forget trying to convince your school
admin to install PHP.  Rent space on a decent PHP host, and put a
re-direct page in your school's computer to your REAL site. Make your
site infinitely better than everybody else in your school. The problem
will then solve itself.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Miles Thompson]

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 were 
misconstrued. I wasn't disappointed.


Miles

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Miles Thompson]

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 php mailing list.


Jasper Bryant-Greene wrote:


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.
http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html 





You are spreading FUD about PHP. Stop it. If you actually *read* the 
article carefully you will find that not only is this not a PHP bug, but 
a bug with two XMLRPC libraries written *for* PHP. Not PHP itself. This 
is completely irrelevant to the original topic, as I didn't see the OP 
asking for XMLRPC security advice.


While you're at it, why not publish an article "PHP HIT BY ANOTHER 
CRITICAL FLAW" with the text "A new security flaw in my website, which is 
developed using PHP, surfaced today..."


Jasper




Santosh,

It's a good article, lousy and inaccurate headline, with an unfortunate 
mistake in describing a language as a protocol. Furthermore, if you look 
towards the bottom of the page, beneath the security blog and the links 
following, you will see that it was reprinted from TechWorld. So, alarmist 
filler with no fact-checking.


Nevertheless, there's a useful link to the probable source of the article 
at hardened-php; something many newspapers do not want to bother with.


So, for everyone unhappy about the headline and the "protocol" error",
mailto:[EMAIL PROTECTED](104214)

Or click on the feedback button to the right of the headline.

And as for someone else's comment that it's OK to write against PHP, as 
long as it's factual. Right on!!


Miles 


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Rory Browne]

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 would have been attacked if you simply refered to some
article said php was insecure, saying "This article says php is
insecure". You seemed to be saying yourself that "PHP was insecure",
and backing it up using that article.

I think at this stage a bit of background in computer security is in
order. There is  no computer that is 100% secure. Even a computer that
is buried 5 miles beneth a heavly guarded army base with no power or
communicaton cables can be penetrated by the right person/people.

In the same way nearly all software, including PHP has bugs. The
difference with free/libre/open source software, is that any security
critical bugs, are fixed within an extremely short timeframe, and so
long as you update your machine regularly with any security related
updates, you should be OK.

This applies to all software of course, but the difference between
PHP, and other other propriatory solutions is that security updates
are released very soon after they are found.

Ian:
The department is right. PHP is a security risk. So is every other
piece of software on your machine. What your department has to do is
manage that risk. The default way of installing PHP will allow users
on a shared server to execute commands under the web-servers UID. This
can be, to a certain extent prevented using safe-mode, or better
again, using something like suExec/suPHP (search google or apache
docs).

PHP is like any other server application. You need to decide what
compromise between usability and security you want to make. You
basicly want to make it as secure as possible, without sacrificing any
essencial usability.

As an example, disabling register_globals makes your script more
secure, but you have to use $_GET['varname'] instead of $varname. That
is IMO a usability sacrifice well worth making in the interest of
security.

You'll find plenty more security related articles on the net, as to
how you can minimise the insecurity caused by PHP.

On 8/25/05, Santosh Jambhlikar <[EMAIL PROTECTED]> 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.
> 
> 
> Jasper Bryant-Greene wrote:
> 
> > 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.
> >> http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html
> >
> >
> >
> > You are spreading FUD about PHP. Stop it. If you actually *read* the
> > article carefully you will find that not only is this not a PHP bug,
> > but a bug with two XMLRPC libraries written *for* PHP. Not PHP itself.
> > This is completely irrelevant to the original topic, as I didn't see
> > the OP asking for XMLRPC security advice.
> >
> > While you're at it, why not publish an article "PHP HIT BY ANOTHER
> > CRITICAL FLAW" with the text "A new security flaw in my website, which
> > is developed using PHP, surfaced today..."
> >
> > Jasper
> >
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Jasper Bryant-Greene]

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.


The problem is, it's not the truth. News isn't always true (gasp). 
You're welcome to write against PHP in this list, but only if what you 
write is true!


I am just saying, you should take what you read in the media with a 
grain of salt. The person that wrote this article obviously has no idea 
what PHP or XMLRPC are, as he thinks that a vulnerability in PEAR's 
XMLRPC package (*not* part of PHP, but simply a library built using PHP) 
is a vulnerability in PHP itself.


Jasper

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Chris Shiflett]

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 something wrong, i am new user in php mailing list.


I don't think you did anything wrong. However, you must realize how 
frustrating it is to see such misinformation being spread. Responsible 
members of the community should always speak out against such things. 
Don't take offense. :-)


Chris

--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Santosh Jambhlikar]

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:


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 




You are spreading FUD about PHP. Stop it. If you actually *read* the 
article carefully you will find that not only is this not a PHP bug, 
but a bug with two XMLRPC libraries written *for* PHP. Not PHP itself. 
This is completely irrelevant to the original topic, as I didn't see 
the OP asking for XMLRPC security advice.


While you're at it, why not publish an article "PHP HIT BY ANOTHER 
CRITICAL FLAW" with the text "A new security flaw in my website, which 
is developed using PHP, surfaced today..."


Jasper



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Chris Shiflett]

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
> security risk and that people at my school would try to hack into
> the server (what bull).

If you want to know why people have this perception, read the first 
response you received:


Santosh Jambhlikar wrote:

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.

This is what people read in the media. Developers write vulnerable code, 
and the "blame" gets shared by PHP itself. The end result is that people 
think PHP itself is insecure.


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/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Jasper Bryant-Greene]

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.
http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html 


You are spreading FUD about PHP. Stop it. If you actually *read* the 
article carefully you will find that not only is this not a PHP bug, but 
a bug with two XMLRPC libraries written *for* PHP. Not PHP itself. This 
is completely irrelevant to the original topic, as I didn't see the OP 
asking for XMLRPC security advice.


While you're at it, why not publish an article "PHP HIT BY ANOTHER 
CRITICAL FLAW" with the text "A new security flaw in my website, which 
is developed using PHP, surfaced today..."


Jasper

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Santosh Jambhlikar]

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. 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 security risk 
and that people at my school would try to hack into the server (what 
bull). Anyway, can you give me some tips to make the server secure? 
Any help would be appreciated!




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[.....hG]

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 PROTECTED]
: 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 secure in reallity it is to place your UN and
: > Passwords on a PHP file.
: >
: > Thanks for your input
: >
:
: Well, what do you suggest we do? We could ask the code you write to
: guess the username and password?
:
: >From the web, if you do it right, there is no way to really find out
: what the user/pass is. Don't keep it in your webroot if you can help it
: is a good way to avoid any issues. The only people who should have
: access to the file are you and your webserver process.
:
: if you put a file in your directory called, db.inc.php and it looks like
: so:
:
: 
:
: .. if php is properly configured, this will never be displayed
: at /db.inc.php ... will just show a blank page
:
:
: -- 
: /***
: * Robby Russell | Owner.Developer.Geek
: * PLANET ARGON  | www.planetargon.com
: * Portland, OR  | [EMAIL PROTECTED]
: * 503.351.4730  | blog.planetargon.com
: * PHP/PostgreSQL Hosting & Development
: * --- Now hosting Ruby on Rails Apps ---
: / 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[AdamT]

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)
http://www.ioncube.com/ (Commercial - free eval available)
http://www.rssoftlab.com/phpenc.php (Commercial - free version available)


-- 
AdamT
"Justify my text?  I'm sorry, but it has no excuse."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[John Cage]

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

Re: [PHP] PHP security

[AdamT]

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 place it
someplace outside of the document root.

Eg: /users/~yourname/public_html/ might be where www.example.com maps
to on the local file system, so put your includes in
/users/~yourname/somewhere_else/

Also - do not name these files with a .inc extension.  If you need to
signify the fact that they are to be included in other pages, call
give them .inc.php extensions.  So if your webserver ever has a
vulnerability whereby people can read files outside the document root
(eg by typing http://www.example_site.com/../includes/dbpassword.inc.php)
- the file will be parsed by PHP before being sent to the browser,
thus hiding any mysql connect statements or $username variable
declarations.

The other type of exploit you might need to guard against is one where
people can trick the server into not parsing PHP files, but sending
them straight to the browser as plain text.  This might be done by
sending unicode chars, or by putting an extra . on the end of the
filename.  Eg: requesting
http://www.example_site.com/includes/dbpassword.inc.php.
This is more of a problem if you place such files within the document root.
If you don't have access to space outside of the document root, then
a) rattle your hosting provider's cage a little bit and b) protect
these files with .htaccess and .htpasswd files (google for it if you
haven't used .htaccess before).  At least this way, if somebody does
try to request the files directly with their web browser, they'll be
prompted for a username and password.  PHP, meanwhile will still be
able to read the contents.

If you're running some script which does have a load of files named
.inc, and you don't want to go grepping every file, and changing all
instances of .inc to .inc.php, and renaming all the files - then use
.htaccess files to add php as a handler for all .inc files - so any
file with a .inc extension will be treated exactly the same as if it
had a .php extension - ie - it will be parsed by PHP, rather than
being sent to the browser as plaintext.

If you're really, really, really paranoid, you can add a file to the
includes directory, called, say rootpassword_backdoor.php, which, when
accessed will add the remote IP address to a blacklist, which other
scripts consult, and if they find it matches any sites requesting
them, they ignore.

My 2 bits.

-- 
AdamT
"Justify my text?  I'm sorry, but it has no excuse."

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[Chris Shiflett]

--- ".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 risk.

My favorite method of handling this is described at the end of this
article:

http://shiflett.org/articles/security-corner-mar2004

Hope that helps.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly HTTP Developer's Handbook - Sams
Coming Soon http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[Robby Russell]

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 secure in reallity it is to place your UN and 
> Passwords on a PHP file.
> 
> Thanks for your input
> 

Well, what do you suggest we do? We could ask the code you write to
guess the username and password?

>From the web, if you do it right, there is no way to really find out
what the user/pass is. Don't keep it in your webroot if you can help it
is a good way to avoid any issues. The only people who should have
access to the file are you and your webserver process. 

if you put a file in your directory called, db.inc.php and it looks like
so:



.. if php is properly configured, this will never be displayed
at /db.inc.php ... will just show a blank page


-- 
/***
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON  | www.planetargon.com
* Portland, OR  | [EMAIL PROTECTED]
* 503.351.4730  | blog.planetargon.com
* PHP/PostgreSQL Hosting & Development
* --- Now hosting Ruby on Rails Apps ---
/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Consortium

[Chris W. Parker]

Chris Shiflett 
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 List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Richard Lynch]

> 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 turned out to be *different* for
some case involving rich media.

I cannot for the life of me find the references from my day job four times
removed to prove it, mind you, and maybe it was with PDF and not JPEG, but
at some point, I just don't want to give browsers (or search engines)
*ANY* realistic opportunity to spot ".php" and decide that my dynamic
image is inferior/invalid.

> Another one that I've seen referenced frequently (especially back when
> this was a larger and more common problem) is this:
>
> http://example.org/image.php?iesucks=foo.jpg

In the larger picture of rich media in general, this will fail miserable
for  dynamic PDFs.

If I have to dink around with PATH_INFO for PDFs to behave, I might as
well treat my JPEGs with the same code-base and use:
http://example.com/image/iesucks/foo.jpg
http://example.com/pdf/iesucks/foo.pdf

Too many browsers, too many bugs ==> I'm not letting them waste my time
any more on their stupidity.

I wouldn't recommend that users configure servers to parse *ALL* "*.jpg"
in a directory as PHP, of course.  Ditto for "*.pdf"

But to be sure the browser can't mess up, I'll cheerfully for "image" to
be a PHP script and foo.jpg is just in the PATH_INFO, or for a one-off,
force "progress_meter.jpg" to be a PHP script.

I can't begin to estimate the number of hours I've wasted on browser bugs
with rich media where they browser used the URL to do something incredibly
stupid instead of just taking the valid data being sent and doing the
right thing.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Chris Shiflett]

--- 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 URL to determine the MIME
> type will not correctly display a URL such as:
> 
> http://l-i-e.com/gd_example.php

IE still ignores Content-Type in most cases (way to go, Microsoft), but
this problem doesn't exist in recent versions, to my knowledge.

> Said browser will, however, correctly handle:
> http://l-i-e.com/gd_example.jpg
> 
> Note that both images are dynamic and, in fact, the two source
> files are Linux symbolic (hard) links, as is this PHP source code:
> http://l-i-e.com/gd_example.phps

There are better ways to do this than parsing .jpg files as PHP. One
obvious one is:

http://example.org/image.php/foo.jpg

Another one that I've seen referenced frequently (especially back when
this was a larger and more common problem) is this:

http://example.org/image.php?iesucks=foo.jpg

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly HTTP Developer's Handbook - Sams
Coming Soon http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Richard Lynch]

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:
>>
>> http://l-i-e.com/gd_example.php
>>
>> Said browser will, however, correctly handle:
>> http://l-i-e.com/gd_example.jpg
>
> You sure about that? AFAIK so long as the filename ends on .jpg as
> shown by the browser, then you're okay. Provided you use PATH_INFO,
> then, you can use http://example.com/make_image.php/dummy.jpg

Actually, I have generalized a whole plethora of Microsoft IE bugs in one
giant mess as the following truism:

Microsoft does not believe in dynamic rich media content.

Netscape doesn't always get it right either, btw.

It is *possible* that I am mistaken in the case of JPEGs, and
http://example.com/make_image.php/dummy.jpg will work on every MSIE
browser, and even on every browser that pretends to support JPEGs at all.

*HOWEVER* I can guarantee that:

http://example.com/make_pdf.php/whatever.pdf?input_to_pdf=42

will *BREAK* MSIE/Adobe launching of the Reader, even though:

http://example.com/make_pdf.php/whatever.pdf

works just fine.

And I can guarantee that Expiration headers with JPEG or PDF breaks some
browsers.

Now, I could sit here and try to remember every possible combination of
URL, mime type, file extension, and query string presence that may or may
not break one or more releases of MSIE and/or Netscape (or any other
browser) in some way...

Or, I could do what I have decided is the better solution:

Never give Microsoft the opportunity to screw this up.  Ever.

Always present MSIE with a URL that the browser *CANNOT*, by definition,
believe to be anything more than what I want the browser to believe it is.

If it's a JPEG, I'm going to give them a URL like:

http://example.com/scriptname/var1=value1/var2=value2/filename.jpg

where 'filename.jpg' is what I want MSIE to believe is the name of the JPEG.


They cannot even remotely stay close to HTTP spec and believe that that is
not a static JPEG on my server.  My directory names with = in them might
be a bit strange, but it's just a URL to them.

If it's a PDF, I'll do the same damn thing with .pdf on the end.

There will be no .php in the URL.

There will be no ? in the URL.

There will be no headers about content expiration for them to ignore, or
worse, to fail to deliver content because Microsoft doesn't understand
that rich media content *can* expire.

That last may be the one Netscapre screwed up.  Whatever.  I don't care
any more which browser screws what up.  I ain't gonna let any of them ever
mess with me again.

I simply refuse to give MSIE the opporunity to waste any more of my
valuable time figuring out which of their stupid browsers won't follow the
HTTP standard and do what it is supposed to do.

I *WILL* hand them a URL indistinguishable from a static URL to content.

If it's dynamic content, that URL *will* contain a random string that will
force them to re-load the content every page hit.  If that ruins their
caching system, that's their fault for not accepting expiration on rich
media in the first place.  Not my problem.

I've had it with MSIE (and Netscape too, for that matter) on this issue.

The browser makers have repeatedly *failed* to understand dynamic rich
media content.  I will simply not give them the opporunity, across the
board, to screw it up again, because they will not be able to (easily)
distinguish my dynamic rich media content from boring static rich media
content.

Can you tell I'm more than a little irked by browser handling of dynamic
rich media content, across the board?

This is a systemic browser problem that has remained unaddressed for
*YEARS* by the browser makers.  Instead, they've focused on
oh-so-important issues like the BLINK tag, and adding features no user
knows how to use, and adding platform-dependent tags and widgets out the
wazoo.  Gee, thanks.

Since they have repeatedly failed, I'm not willing to give them the
opportunity any more to fail.  They get a URL that looks just like the URL
they *can* handle, for all media types, and I'm done with all their flaky
browser inconsistencies in this arena.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Rory Browne]

> 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:
> 
> http://l-i-e.com/gd_example.php
> 
> Said browser will, however, correctly handle:
> http://l-i-e.com/gd_example.jpg

You sure about that? AFAIK so long as the filename ends on .jpg as
shown by the browser, then you're okay. Provided you use PATH_INFO,
then, you can use http://example.com/make_image.php/dummy.jpg


> 
> Note that both images are dynamic and, in fact, the two source files are
> Linux symbolic (hard) links, as is this PHP source code:
> http://l-i-e.com/gd_example.phps
> 
> The real problem in the describe scenario is that somebody was foolish
> enough to take an image supplied by the untrusted USER and then feed it to
> PHP to be executed.
> 
> Well, duh.
> 
> Don't do that.
> 
> :-)
> 
> You could do the exact same thing in Perl, C, or maybe even ASP.
> [You'd really have to work at it in ASP, though, since ASP is broken.]
> 
> > Needless to say this discussion quickly caught my attention and I
> > began to defend PHP explaining how the unsafe functions could be
> > disabled via the php.ini and so forth.  But then I began to wonder..
> > surely if an exploit were possible the PHP folks would have been
> > informed and the source would have been patched by now, right?
> 
> If an exploit is possible, but has nothing to do with PHP specifically,
> and has everything to do with a bad programmer, bad admin, or just plain
> user stupidity (PHP user, not end user) then why would the PHP Development
> Team change PHP?
> 
> > I guess my question is.. is PHP's file upload functionality really
> > safe?  I myself have a lot at stake if it's not.
> 
> Is your car really safe?  I have a lot at stake if it's not.  Should we
> outlaw cars because some people drive drunk?
> 
> > I don't know much about writing exploits, I just try to keep up to
> > date on security patches and bulletins and all.  But these security
> > guys really seem to think PHP is insecure as far as file uploading, so
> > now I'm wondering about it all.
> 
> The best way to learn more about security, other than poring over security
> lists with way too much information, plus lots and lots of misinformation
> from well-meaning people, is to role-play yourself as the bad guy and ask
> yourself:  "If I was mean, how would I mess with this to break this guy's
> site?"
> 
> I'm no security expert, but it amazes me the stupidity of some coding I
> see.  It's not *that* tricky to put yourself in the bad guy's shoes.
> 
> --
> Like Music?
> http://l-i-e.com/artists.htm
> 
> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Richard Lynch]

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 format,
> then proceeding in uploading the image to the target site that
> accepted image uploads.
> The code would be executed as PHP in spite of
> the file type detection.  I'd think there would be no need to parse a
> jpeg as PHP, right?

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:

http://l-i-e.com/gd_example.php

Said browser will, however, correctly handle:
http://l-i-e.com/gd_example.jpg

Note that both images are dynamic and, in fact, the two source files are
Linux symbolic (hard) links, as is this PHP source code:
http://l-i-e.com/gd_example.phps

The real problem in the describe scenario is that somebody was foolish
enough to take an image supplied by the untrusted USER and then feed it to
PHP to be executed.

Well, duh.

Don't do that.

:-)

You could do the exact same thing in Perl, C, or maybe even ASP.
[You'd really have to work at it in ASP, though, since ASP is broken.]

> Needless to say this discussion quickly caught my attention and I
> began to defend PHP explaining how the unsafe functions could be
> disabled via the php.ini and so forth.  But then I began to wonder..
> surely if an exploit were possible the PHP folks would have been
> informed and the source would have been patched by now, right?

If an exploit is possible, but has nothing to do with PHP specifically,
and has everything to do with a bad programmer, bad admin, or just plain
user stupidity (PHP user, not end user) then why would the PHP Development
Team change PHP?

> I guess my question is.. is PHP's file upload functionality really
> safe?  I myself have a lot at stake if it's not.

Is your car really safe?  I have a lot at stake if it's not.  Should we
outlaw cars because some people drive drunk?

> I don't know much about writing exploits, I just try to keep up to
> date on security patches and bulletins and all.  But these security
> guys really seem to think PHP is insecure as far as file uploading, so
> now I'm wondering about it all.

The best way to learn more about security, other than poring over security
lists with way too much information, plus lots and lots of misinformation
from well-meaning people, is to role-play yourself as the bad guy and ask
yourself:  "If I was mean, how would I mess with this to break this guy's
site?"

I'm no security expert, but it amazes me the stupidity of some coding I
see.  It's not *that* tricky to put yourself in the bad guy's shoes.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Chris Shiflett]

--- 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 or other image format,
> then proceeding in uploading the image to the target site that
> accepted image uploads. The code would be executed as PHP in spite
> of the file type detection.

I would challenge him to provide an example exploit. That will probably
end the debate, but just in case he actually knows what he's talking
about, it gives him an opportunity to clarify his point.

> I'd think there would be no need to parse a jpeg as PHP, right?

Apache (and I assume most any HTTP server) uses the file extension to
determine the content type, so anything named foo.jpg will not be parsed
by the PHP engine (unless, for some crazy reason, you specifically
configure Apache to do so, or you mistakenly use ForceType incorrectly).

If you let someone upload a file, and you let them choose the name, and
you put that file within document root, then yes, you have a pretty
serious vulnerability. But, that's just stupid. You can be stupid in any
language. :-)

> Needless to say this discussion quickly caught my attention and I
> began to defend PHP explaining how the unsafe functions could be
> disabled via the php.ini and so forth.  But then I began to wonder..
> surely if an exploit were possible the PHP folks would have been
> informed and the source would have been patched by now, right?

Most likely. It's unfortunate, but most people who raise concerns like
this have no idea what they're talking about. The reason I find it
unfortunate is that realistic concerns can be lost in the crowd. This
could be a realistic concern, but I'd need more details to determine that.

> I guess my question is.. is PHP's file upload functionality really
> safe? I myself have a lot at stake if it's not.

I would say it's no more or less safe than most mechanisms. PHP provides
you with information about an uploaded file in the $_FILES superglobal
array. What you do with it is up to you. You can certainly write code that
trusts information sent by the client, but you shouldn't.

My only complaint (it's minor) with PHP's implementation is that a
developer can't easily determine what data in $_FILES comes from the
client. Because some of the information therein is provided by PHP (and
therefore reliable), it's not like $_GET where you can safely assume that
everything comes from the client. This lack of distinction makes it a bit
more difficult to be a security-conscious developer.

> I don't know much about writing exploits, I just try to keep up to
> date on security patches and bulletins and all.  But these security
> guys really seem to think PHP is insecure as far as file uploading, so
> now I'm wondering about it all.

PHP gets a bad rap because of the multitude of insecure applications
written in the language, and (more importantly) the tendency to name
applications PHP something. This means that those who keep up with things
like Security Focus see PHP mentioned all the time, and they have a poor
opinion of it. Of course, in reality, what they see are names like phpBB
and PHP-Nuke, not PHP itself.

> Chris has excellent info on general PHP security
> (http://shiflett.org/php-security.pdf) and I re-read it today before
> posting. But how does one go about "filtering" a jpeg for exploit
> code? Seems the only winning move is to not play.

Thanks for the kind words. While I stand behind everything within that
PDF, I don't want anyone to think that it's anywhere near complete. It
began as a companion to my OSCON talk on PHP security (and it's changed
very little since), so it only covers the topics that I chose for a 3 hour
talk. File uploads were not part of that.

I did write a Security Corner (my column in php|architect) on file uploads
in the October issue, but that is not available for free yet (it won't be
until April). Sorry that I don't have a better resource for you - I've
always felt that file uploads weren't as common as most of the other
topics that I frequently write about.

Hope that helps.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly HTTP Developer's Handbook - Sams
Coming Soon http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] php security on shared hosts

[Tim Traver]

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 Gosse wrote:
[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
'virtual' in the site root, and it is readable by the web browser.
Inside /virtual there are three folders for every site, which I list
below.
--
site357
pablogosse.com
admin357
--
Browsing these for my site I see the following:
site357:
4096   ./
20480  ../
4096   fst/
4096   info/
pablogosse.com and admin357:
4096   ./
4096   ../
4096   bin/
4096   boot/
4096   dev/
4096   etc/
4096   home/
4096   initrd/
4096   lib/
4096   mnt/
4096   opt/
4096   proc/
4096   root/
4096   sbin/
4096   tmp/
4096   usr/
4096   var/
498subdomain
4096   mysql/
7392   dump.xml
Also, if I browse the fst/ folder inside site357, I get the same results
as pablogosse.com and admin357.
I'm then able to browse freely through all the above folders except
/home and /root.
I'm no security expert so I have to ask, is this indeed normal?
Cheers and TIA.
Pablo
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

SimpleNet's Back !
http://www.simplenet.com

Re: [PHP] php security on shared hosts

[Tim Traver]

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 mode + open_basedir + 
included directories + exec directories should be enough to prevent a PHP 
script from viewing the tree, and anyone else's data.

If you have a way, using PHP (not a perl or sh or tcl script), to get 
around those directives, then please let me know.

Personally, I never wanted to offer any CGI scripting to our customers, but 
in this day and age, a shared host has to, because the customers expect it, 
even though they have no idea how to use it. So I've created a jailed 
environment for perl to run as the user, and away from everyone else's 
directories. I am still wary of how safe that is, but its as close as I can 
get it...

Seriously, let me know if you've got any issues with PHP's security model.
Tim.
At 11:26 AM 9/26/2004, Chris Shiflett wrote:
--- 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 should prevent
> your script from being able to walk the tree.
We know what these directives do. I think you're missing the point. How
can a PHP directive offer any protection against someone writing a CGI
that reads a file somewhere? Think about it.
> I didn't think there was, and if there is, then we better post
> that to the security guys at php, cause that's not good.
We know that neither safe_mode nor open_basedir offer protection from
this. We also know that it's impossible to solve this problem at the PHP
level, because it is completely independent of PHP.
> I think it should be pretty safe though if implemented correctly.
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 account's password within a few minutes. But, I'm
just speculating. :-)
Chris
=
Chris Shiflett - http://shiflett.org/
PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

SimpleNet's Back !
http://www.simplenet.com

RE: [PHP] php security on shared hosts

[Pablo Gosse]

[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
'virtual' in the site root, and it is readable by the web browser.

Inside /virtual there are three folders for every site, which I list
below.

--
site357
pablogosse.com
admin357
--

Browsing these for my site I see the following:

site357:

4096   ./
20480  ../
4096   fst/
4096   info/

pablogosse.com and admin357:

4096   ./
4096   ../
4096   bin/
4096   boot/
4096   dev/
4096   etc/
4096   home/
4096   initrd/
4096   lib/
4096   mnt/
4096   opt/
4096   proc/
4096   root/
4096   sbin/
4096   tmp/
4096   usr/
4096   var/
498subdomain
4096   mysql/
7392   dump.xml

Also, if I browse the fst/ folder inside site357, I get the same results
as pablogosse.com and admin357.

I'm then able to browse freely through all the above folders except
/home and /root.

I'm no security expert so I have to ask, is this indeed normal?

Cheers and TIA.

Pablo

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] php security on shared hosts

[Chris Shiflett]

--- 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' webroots and all other
> directories and files readable by nobody:nobody, including
> database passwords, .htaccess files (which contained paths to
> password and group files), etc.

Right, and this isn't unusual. What I should probably do is write one of
these simple filesystem browsers in various shells, Perl, and any other
type of interpreter commonly available on shared hosts. This might better
illustrate that things like safe_mode are no solution.

> I guess it is an inevitable fact that if you are on a shared
> host, any script executed from the browser is capable of
> reading any other script on the server which is set to be
> readable by the web server.

Yep, it sounds like you understand the problem quite well. What some
people miss is the fact that the contents of a file have nothing to do
with filesystem privileges and such. The fact that one file has PHP code
in it is irrelevant.

> I usually store all my files with sensitive information and
> class files outside the webroot, but under this setup, anyone
> could simply read the contents of the files in the webroot and
> use the information in those files to then read the files which
> are store outside of the webroot.

This is still a very good practice, and I hope you continue to use it.

> Unfortunately I don't have access to my server config file (a
> 'find' command for httpd.conf returned no results), so is this
> something a host would usually change for individual users?

It should be, and you can always point them to my article if they don't
understand why you want this. Is your host running Apache?

> Also, safe_mode is not enabled on this host so I while I assume
> that I could enable it using .htaccess for my site, that still
> would not prevent anyone else from reading my scripts since their
> scripts would not be running in safe mode, right?

That's exactly right. Also, the bad guys might be Perl programmers. :-)

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] php security on shared hosts

[Pablo Gosse]

[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, there are some things you can do as a
developer,
and I give some specific examples.
[/snip]

Hi, Chris.  Thanks for that link.  It was incredibly informative.

I just took your code for the file browser and it was able to read the
information in all users' webroots and all other directories and files
readable by nobody:nobody, including database passwords, .htaccess files
(which contained paths to password and group files), etc.

There was no /etc/passwd file, but this is irrelevant as I was simply
able to browse the /virtual directory to see a list of all users home
directories, and from there their webroots, etc.

I guess it is an inevitable fact that if you are on a shared host, any
script executed from the browser is capable of reading any other script
on the server which is set to be readable by the web server.

I usually store all my files with sensitive information and class files
outside the webroot, but under this setup, anyone could simply read the
contents of the files in the webroot and use the information in those
files to then read the files which are store outside of the webroot.

Unfortunately I don't have access to my server config file (a 'find'
command for httpd.conf returned no results), so is this something a host
would usually change for individual users?

Also, safe_mode is not enabled on this host so I while I assume that I
could enable it using .htaccess for my site, that still would not
prevent anyone else from reading my scripts since their scripts would
not be running in safe mode, right?

Thoughts?

Cheers and TIA,

Pablo.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Jason Wong]

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 account's password within a few minutes. But, I'm
> just speculating. :-)

Stop it! You're scaring away his customers ;-)

-- 
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
Whatever women do they must do twice as well as men to be thought half
as good.  Luckily this is not difficult.
-- Charlotte Whitton
*/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Chris Shiflett]

--- 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 should prevent
> your script from being able to walk the tree.

We know what these directives do. I think you're missing the point. How
can a PHP directive offer any protection against someone writing a CGI
that reads a file somewhere? Think about it. 

> I didn't think there was, and if there is, then we better post
> that to the security guys at php, cause that's not good.

We know that neither safe_mode nor open_basedir offer protection from
this. We also know that it's impossible to solve this problem at the PHP
level, because it is completely independent of PHP.

> I think it should be pretty safe though if implemented correctly.

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 account's password within a few minutes. But, I'm
just speculating. :-)

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Marek Kilimajer]

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 
script from being able to walk the tree.

Is there some way to get around open_basedir ?
Only if you are able to execute commands outside of php, what Pablo is.
I didn't think there was, and if there is, then we better post that to 
the security guys at php, cause that's not good.

Yes, there are many scripts that assume no safe_mode, and therefor do 
not work. It usually means they are trying to do something a little more 
powerful with the filesystem, or system commands, and shared hosts don't 
want random system commands being run on the machines...;)

Am I saying its perfect ? No. I think it should be pretty safe though if 
implemented correctly.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Tim Traver]

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 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
> happen.
The safe_mode and open_basedir directives are certainly no protection. I'm
curious what sort of permissions you are using that prevents this
scenario, since it seems impossible to me. If the legitimate developer can
include code using include or require, it means the Web server must be
able to read those files. The exception would be if you're running each
user in a chroot jail or something, mimicking a dedicated environment.
> So, I'd say that your shared host is doing a poor job of
> implementing PHP.
I used to think the same, but I've changed my mind, because:
1. safe_mode is no protection.
2. Many prepackaged PHP applications don't work with safe_mode enabled.
Hope that helps.
Chris
=
Chris Shiflett - http://shiflett.org/
PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

SimpleNet's Back !
http://www.simplenet.com

Re: [PHP] php security on shared hosts

[Tim Traver]

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 able to walk the tree.

Is there some way to get around open_basedir ?
I didn't think there was, and if there is, then we better post that to the 
security guys at php, cause that's not good.

Yes, there are many scripts that assume no safe_mode, and therefor do not 
work. It usually means they are trying to do something a little more 
powerful with the filesystem, or system commands, and shared hosts don't 
want random system commands being run on the machines...;)

Am I saying its perfect ? No. I think it should be pretty safe though if 
implemented correctly.

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 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
> happen.
The safe_mode and open_basedir directives are certainly no protection. I'm
curious what sort of permissions you are using that prevents this
scenario, since it seems impossible to me. If the legitimate developer can
include code using include or require, it means the Web server must be
able to read those files. The exception would be if you're running each
user in a chroot jail or something, mimicking a dedicated environment.
> So, I'd say that your shared host is doing a poor job of
> implementing PHP.
I used to think the same, but I've changed my mind, because:
1. safe_mode is no protection.
2. Many prepackaged PHP applications don't work with safe_mode enabled.
Hope that helps.
Chris
=
Chris Shiflett - http://shiflett.org/
PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

SimpleNet's Back !
http://www.simplenet.com

Re: [PHP] php security on shared hosts

[raditha dissanayake]

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 administrators code of conduct to look into 
other user's files, you cannot rule out the possibility of someone 
taking a peek.

As chris has pointed out safe mode is no protection. On some servers 
(not all) you can try changing your home directory permissions to remove 
others' read and others' execute to get an additional measure of protection.

--
Raditha Dissanayake.

http://www.radinks.com/sftp/ | http://www.raditha.com/megaupload
Lean and mean Secure FTP applet with | Mega Upload - PHP file uploader
Graphical User Inteface. Just 128 KB | with progress bar.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Chris Shiflett]

--- 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
> happen.

The safe_mode and open_basedir directives are certainly no protection. I'm
curious what sort of permissions you are using that prevents this
scenario, since it seems impossible to me. If the legitimate developer can
include code using include or require, it means the Web server must be
able to read those files. The exception would be if you're running each
user in a chroot jail or something, mimicking a dedicated environment.

> So, I'd say that your shared host is doing a poor job of
> implementing PHP.

I used to think the same, but I've changed my mind, because:

1. safe_mode is no protection.
2. Many prepackaged PHP applications don't work with safe_mode enabled.

Hope that helps.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Chris Shiflett]

--- 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 -la commands to see what I did and did not have
> access to. Eventually I was able to read the directory which
> holds the root folders for all sites on the server, and from
> there I was able to read files (revealing the php source) from
> the webroot of another site.
> 
> This to me is a huge security issue since if anyone has any
> sensitive information there, it could easily be accessed by
> anyone else hosting on the same server. And because I can't seem
> to include files from outside my webroot, if I stay with this
> company I'll be forced to include information such as database
> passwords inside my webroot, therefore exposing the information
> to every other user on the server, and that's just not acceptable.

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, there are some things you can do as a developer,
and I give some specific examples.

Hope that helps.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming December 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security on shared hosts

[Tim Traver]

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 situation 
you described cannot happen.

So, I'd say that your shared host is doing a poor job of implementing PHP.
Tim.

At 08:31 PM 9/25/2004, Pablo Gosse 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 -la commands to see what I did and did not have access to. Eventually
I was able to read the directory which holds the root folders for all
sites on the server, and from there I was able to read files (revealing
the php source) from the webroot of another site.
This to me is a huge security issue since if anyone has any sensitive
information there, it could easily be accessed by anyone else hosting on
the same server. And because I can't seem to include files from outside
my webroot, if I stay with this company I'll be forced to include
information such as database passwords inside my webroot, therefore
exposing the information to every other user on the server, and that's
just not acceptable.
All of my experience until now has been in situations where the sites
I've worked on have been hosted on dedicated servers, so this has never
been a problem.
Is this a common set up for shared hosting? Is there any way around
this?
Cheers and TIA.
Pablo
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

SimpleNet's Back !
http://www.simplenet.com

Re: [PHP] PHP Security Workbook

[Chris Ditty]

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

Re: [PHP] PHP Security Workbook

[Chris Shiflett]

--- 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) about some of the more important security topics.
> > 
> > I hope you find it helpful.
> > 
> > Chris
> 
> I printed this out the day you sent it, but it had been sitting
> on my desk, unread, until today. Just got finished with it.
> Very helpful methods. I thank you sir.

No problem - thanks for the kind feedback. :-) I'm glad you find it
helpful.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming Fall 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[John Nichel]

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 find it helpful.
Chris
I printed this out the day you sent it, but it had been sitting on my 
desk, unread, until today.  Just got finished with it.  Very helpful 
methods.  I thank you sir.

--
John C. Nichel
ÜberGeek
KegWorks.com
716.856.9675
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[Octavian Rasnita]

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
> VirtualHost block of httpd.conf, so that it only applies to a single
> virtual host.
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[Chris Shiflett]

--- 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 root, then include a call to that file in
> httpd.conf in order to let the web server to have access to those
> variables.

I can't take credit for thinking of this approach. This comes from David
Sklar and Adam Trachtenberg, authors of PHP Cookbook (and others).

> Well, I don't really understand why this is so secure.
> 
> I understand that the web server is run by root, which sees that file
> and exports the variables, then another user without many
> priviledges runs the child process of the web server, but if there are
> more than one user that run PHP files or files made in other
> languages on that server, they will also be able to see those
> environment variables.
> 
> Did I understand correctly?

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
VirtualHost block of httpd.conf, so that it only applies to a single
virtual host.

Also, each unprivileged child process that handles requests for this
virtual host has this sensitive information in memory. So, while the data
is safer, it is not completely safe (nothing is). If a user can exploit a
vulnerability in your application that lets them execute arbitrary code,
they can access this data. Of course, they can do a lot of bad things in
this case. :-)

Hope that clarifies. Thanks for the feedback.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming Fall 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[Octavian Rasnita]

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 root, then include a call to that file in httpd.conf in order to
let the web server to have access to those variables.

Well, I don't really understand why this is so secure.

I understand that the web server is run by root, which sees that file and
exports the variables, then another user without many priviledges runs the
child process of the web server, but if there are more than one user that
run PHP files or files made in other languages on that server, they will
also be able to see those environment variables.

Did I understand correctly?
Teddy

- Original Message -
From: "Chris Shiflett" <[EMAIL PROTECTED]>
To: "Burhan Khalid" <[EMAIL 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 that have heard me give this talk (which is a few
> hundred now) have realized several vulnerabilities in their current
> applications, bad development habits, etc. I actually get tired of giving
> the same (or very similar) talks, but I'll keep giving this one as long as
> it keeps surprising a lot of the audience. The fewer excuses we give
> people to equate PHP with poor security, the better off we'll all be.
>
> >  However, I do have issue with one paragraph:
> >
> > Page 29,
> >

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[Chris Shiflett]

--- 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 current
applications, bad development habits, etc. I actually get tired of giving
the same (or very similar) talks, but I'll keep giving this one as long as
it keeps surprising a lot of the audience. The fewer excuses we give
people to equate PHP with poor security, the better off we'll all be.

>  However, I do have issue with one paragraph:
> 
> Page 29,
> 
> * Using POST rather than GET in forms.
> 
> "Specify POST in the method attribute of your forms.  Of course, this 
> isn't appropriate fot all your forms, but it is appropriate when a form 
> is performing an action, such as buying stocks. In fact, the HTTP 
> specification requires that GET be considered safe."
> 
> Don't you mean "In fact, the HTTP specification requires that POST be 
> considered safe?" Didn't make sense to me when I read it last night.

Nope, it's correct as written. Perhaps it just needs to be rephrased, or
maybe I need to elaborate about what "safe" means in this context.

The piece of the HTTP specification I'm referring to is within section
9.1.1 of RFC 2616, entitled "Safe Methods," and it has the following to
say:

   "In particular, the convention has been established that the GET and
   HEAD methods SHOULD NOT have the significance of taking an action
   other than retrieval. These methods ought to be considered "safe".
   This allows user agents to represent other methods, such as POST, PUT
   and DELETE, in a special way, so that the user is made aware of the
   fact that a possibly unsafe action is being requested."

Thus, as developers, we should never perform an action when the request
method is GET. This means that forms intended to perform actions such as
buying stocks should specify the POST method, and we should also not rely
on register_globals or $_REQUEST, because both of these hide whether the
data we are using was sent in a GET request or a POST request. Specify
POST, and use $_POST.

Hope that clarifies what I mean a bit. Of course, I elaborate more in the
actual talk; this was just the workbook for people to reference and take
home to help remember the points. I just decided to give it away, since I
had put so much work into it. :-)

But, I'm always looking for improvements. I'll try to add a bit of
clarification in there somehow.

Thanks for the feedback.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming Fall 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Workbook

[Burhan Khalid]

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 article. Most of the stuff was common sense to me (and I was glad I 
was doing those things unconsciously).  However, I do have issue with 
one paragraph:

Page 29,
* Using POST rather than GET in forms.
"Specify POST in the method attribute of your forms.  Of course, this 
isn't appropriate fot all your forms, but it is appropriate when a form 
is performin an action, such as buying stocks. In fact, the HTTP 
specification requires that GET be considered safe."

Don't you mean "In fact, the HTTP specification requires that POST be 
considered safe?" Didn't make sense to me when I read it last night.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security in a hosting environment

[Chris Shiflett]

--- 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 not write CGI scripts,
PHP, or anything like that now? So, only static content?

> My concerns are that the client *could* use a php script to access
> parts of the file system, registry (this is a Win32 environment), or
> other such things.

Not to be cute, but Windows isn't fundamentally a multi-user operating
system. I doubt offering PHP services is going to affect your server
security more than your choice of operating system already has.

You can restrict what PHP can do with things like safe_mode, but it is
very important to realize that this only affects scripts written in PHP.
It doesn't protect your environment; it only takes PHP out of the picture.

Security Corner is the latest issue of php|architect
(http://www.phparch.com/issue.php?mid=26) discusses the issue of shared
hosting in more detail.

Hope that helps.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
 Coming Fall 2004
HTTP Developer's Handbook - Sams
 http://httphandbook.org/
PHP Community Site
 http://phpcommunity.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security in a hosting environment

[John W. Holmes]

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 script to access parts
of
> the file system, registry (this is a Win32 environment), or other such
> things.

What web server are you going to use? Either way, PHP runs as a specific
user (IUSR_ with IIS, for example). This user shouldn't be
able to access anything in the filesystem except what's in the webroot
(ensure this is true for your machine). This assumes an NTFS filesystem,
btw. In order to protect things under the webroot, that's where safe_mode,
openbasedir, etc, come into play as explained in the article you linked to.

You're right to be concerned, but it can be done safely. In addition to all
of the above, get something IN WRITING stipulating what the user is allowed
to do, terms of service, etc. That way if you catch them doing something,
you'll be safe legally to go after them. IANAL

---John Holmes...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security in a hosting environment

[Raditha Dissanayake]

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 parts of
the file system, registry (this is a Win32 environment), or other such
things.
 

If you are really concerned about security you should not be in a shared 
hosting enviorenment. Seconly you may want to switch to a more secure 
operating system.

--
Raditha Dissanayake.
-
http://www.radinks.com/print/upload.php
SFTP, FTP and HTTP File Upload solutions 

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP security in a hosting environment

[Hawkes, Richard]

My suggestion would be to run the PHP Web Server on a different server to
where you are retrieving your files. The file server can then define its own
polices of what you can read/write to etc. Your web server can then map a
drive to the file server, and anybody writing PHP scripts won't be able 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 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 system, registry (this is a Win32 environment), or other such
things.

I found a good article at http://www.securityfocus.com/infocus/1706 - it
details some of the settings in the php config that can be used to prevent
malicious scripting.

Does anyone here have experience of securing a php server, and might have
any advice on what else to watch out for?

Any help appreciated.

Thanks.

Ben

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[Martin Nicholls]

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 otherwise
well coded site, or that sort of thing...

I don't know really, I was just wondering what people thought of it.. :P

"Jason Davidson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 '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 risks on PHP sites. You can download it
from
> > my site at http://www.streakyland.co.uk/ccisecurity.zip
> >
> > More info, an extract from the readme ->
> >
> > [What is the CCI Website Security Script?]
> >
> > The CCI Website Security Script is a drop-in PHP script designed to take
on
> > the burdon of dealing with certain common security problems in PHP
scripts.
> > It is made to be added to an existing script to provide immediate,
> > transparent security of varying types.
> >
> > Far, far too often you hear about free scripts having some common
> > vulnerability that has been seen a thousand times in other scripts -
people
> > just aren't careful enough when writing scripts.  This script is desiged
to
> > try to compensate for some of this carelessness.
> >
> > Some of the things it (supposedly) attempts to prevent / do ->
> >
> > HTTP REQUEST FLOODS, SCRIPT DISPLAY VULNERABILITIES, GENERAL FLOOD
> > PROTECTION, IP BANNING VIA .HTACCESS, HTML Source Viewing/Stealing
> >
> > Thanks for your time
> >
> > Streaky
> >
> > -- 
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP security

[Jason Davidson]

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 '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 risks on PHP sites. You can download it from
> my site at http://www.streakyland.co.uk/ccisecurity.zip
> 
> More info, an extract from the readme ->
> 
> [What is the CCI Website Security Script?]
> 
> The CCI Website Security Script is a drop-in PHP script designed to take on
> the burdon of dealing with certain common security problems in PHP scripts.
> It is made to be added to an existing script to provide immediate,
> transparent security of varying types.
> 
> Far, far too often you hear about free scripts having some common
> vulnerability that has been seen a thousand times in other scripts - people
> just aren't careful enough when writing scripts.  This script is desiged to
> try to compensate for some of this carelessness.
> 
> Some of the things it (supposedly) attempts to prevent / do ->
> 
> HTTP REQUEST FLOODS, SCRIPT DISPLAY VULNERABILITIES, GENERAL FLOOD
> PROTECTION, IP BANNING VIA .HTACCESS, HTML Source Viewing/Stealing
> 
> Thanks for your time
> 
> Streaky
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Php security

[Chris Shiflett]

--- 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 Encoder, then a person could not see your
script. If they opened it in an editor, they would just see
garbage (as I understand it; I have never used it).

I should note (just in case) that this has nothing to do
with whether a remote user can view your source via a URL.
If your question is about something else, please restate
it.

Chris

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0and 4.2.1

[Miguel Cruz]

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 
hope for (definitely not your typical tech support script readers), but 
the product is so hopelessly complex that it's still easy to stump them.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Richard Lynch]

>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 Oracle enough money for Support Contracts, they have pretty good
support, from what I hear... :-)

-- 
Like Music?  http://l-i-e.com/artists.htm
I'm looking for a PRO QUALITY two-input sound card supported by Linux (any
major distro).  Need to record live events (mixed already) to stereo
CD-quality.  Soundcard Recommendations?
Software to handle the recording? Don't need fancy mixer stuff.  Zero (0)
post-production time.  Just raw PCM/WAV/AIFF 16+ bit, 44.1KHz, Stereo
audio-to-disk.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Peter]

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 about the amount of money you are
> probably charging hosting clients, or charging in web or programming
> services, or making in site revenue, or whatever way you 'commercially
> function' through PHP.
>
> The register globals 'imposition' IS more secure and encourages better
> coding practices... would you prefer they made the change now, or in 5
years
> when you have 100's more sites to fix.  Better late than later.
>
>
> If you want something that will never have a bug, never have a security
> hole, performs perfectly from day 1, never has an upgrade/change, and will
> never change for the better, you are utterly dreaming!
>
> The difference in this case is that the PHP Group aren't emptying your
> wallet.
>
>
> Sorry to hear that you'll have to do some more upgrading, but I'd keep the
> complaining to yourself -- "you get what you pay for" springs to mind, but
> in the case of PHP, we get a whole lot more.
>
>
> Justin French
>
>
>
>
>
>
>
>
>
> on 23/07/02 2:55 AM, Greg Donald ([EMAIL PROTECTED]) wrote:
>
> > 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 install once a month or so cause of new
> > security holes..  Yay!
> >
> > Wasn't this new register_globals setting supposed to enhance security?
> >
> > How would you like to be a sys admin with dozens of machines to upgrade
> > before you can proceed with anythign else?
> >
> > Can anyone say Ruby?
> >
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1

[Dan Hardiker]

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 on to test
for security.

3. You dont have to upgrade! You should, but you dont have to... its down
to the system administrator to assess the need.

4. If your software requires register_globals to be set "On" in the
php.ini then your software is badly coded and quite possiblty insecure in
its own nature.

5. At the end of the day, we arent choosing YOU to use PHP... you chose
PHP for your own reasons. If you dont like it - Microsoft will be happy to
take chunks of money off your hands for a Win2k Server with IIS and ASP on
it.

The grass it always greener huh.

- Dan

>> 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
>> download?  There is not a shread of text saying do not use in
>> production,  no unsafe warnings whatsoever.  How am I supposed to
>> magically find the  'do not use' warnings?
>
> You have to magically find this by reading the messages on this list,
> not more then a month ago, someone asked was it considered stable for
> production use, and the answer was no. I was going to type a long rant
> about how you should test software or atleast wait a while for the kinks
> to be worked out of new versions instead of running cutting edge, but
> screw it, I'm not wasting any more time on this.
>
>> 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.
>
> I know, there such bastards for releasing security patches to fix the
> holes they know about instead of burrying the evidence and denying a
> hole exists.
>
>> If it doesn't bother you the hassles 'the php group' is putting me,
>> you,  and alot of others through then I guess that's just you.  I
>> can't  help but get pissed about it.  I did not have the time to do
>> these  upgrades, but now I have to make time.
>
> You know your right, the PHP group (god bless them) is out to get you,
> individually, they intentionally put security holes into the software,
> so they can go back later and make you patch your "dozens of systems"
> and make your life a living hell. And it's not just me who doesn't mind
> upgrading, it's just you who can't handle it.
>
> Adam Voigt
> [EMAIL PROTECTED]
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Adam Voigt]

> 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 
> download?  There is not a shread of text saying do not use in production, 
> no unsafe warnings whatsoever.  How am I supposed to magically find the 
> 'do not use' warnings?

You have to magically find this by reading the messages on this list,
not more then a month ago, someone asked was it considered stable for
production use, and the answer was no. I was going to type a long rant
about how you should test software or atleast wait a while for the kinks
to be worked out of new versions instead of running cutting edge, but
screw it, I'm not wasting any more time on this.

> 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.

I know, there such bastards for releasing security patches to fix the
holes they know about instead of burrying the evidence and denying a
hole exists.
 
> If it doesn't bother you the hassles 'the php group' is putting me, you, 
> and alot of others through then I guess that's just you.  I can't 
> help but get pissed about it.  I did not have the time to do these 
> upgrades, but now I have to make time.

You know your right, the PHP group (god bless them) is out to get you,
individually, they intentionally put security holes into the software,
so they can go back later and make you patch your "dozens of systems"
and make your life a living hell. And it's not just me who doesn't mind
upgrading, it's just you who can't handle it.

Adam Voigt
[EMAIL PROTECTED]



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Jay Blanchard]

[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, almost for sure your installation of the "new" PHP binary is not
happening correctly.

Watch carefully when you do "make install" to see where your new copies go.
Use "locate modphp.so" or whatever it is to find out where your old copies
are.
[/snip]

We finally got this right yesterday afternoon, it ended up being, as Richard
said, a directories problem. Ah well, live and learn :) The FreeBSD boxes
went off without a hitch.

Jay



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP security bug and patch

[Peter]

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
> 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 Prague 7, Czech Republic
> tel.: ++420 2 3337 1117, fax:  ++420 2 3337 1112
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Justin French]

Greg,

Your attitude stinks.

PHP is a FREE scripting language.  Think about the amount of money you are
probably charging hosting clients, or charging in web or programming
services, or making in site revenue, or whatever way you 'commercially
function' through PHP.

The register globals 'imposition' IS more secure and encourages better
coding practices... would you prefer they made the change now, or in 5 years
when you have 100's more sites to fix.  Better late than later.


If you want something that will never have a bug, never have a security
hole, performs perfectly from day 1, never has an upgrade/change, and will
never change for the better, you are utterly dreaming!

The difference in this case is that the PHP Group aren't emptying your
wallet.


Sorry to hear that you'll have to do some more upgrading, but I'd keep the
complaining to yourself -- "you get what you pay for" springs to mind, but
in the case of PHP, we get a whole lot more.


Justin French









on 23/07/02 2:55 AM, Greg Donald ([EMAIL PROTECTED]) wrote:

> 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 install once a month or so cause of new
> security holes..  Yay!
> 
> Wasn't this new register_globals setting supposed to enhance security?
> 
> How would you like to be a sys admin with dozens of machines to upgrade
> before you can proceed with anythign else?
> 
> Can anyone say Ruby?
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0and 4.2.1

[Miguel Cruz]

On Mon, 22 Jul 2002, Greg Donald wrote:
> 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`...

You didn't have to. The choice was given to you, for your own good. If you 
have very disciplined programmers and a solid auditing process, you can 
still do just fine with register_globals on.

> Now I get to upgrade my PHP install once a month or so cause of new 
> security holes..  Yay!

Vastly preferable to the alternative: Brand X, where security holes go 
unpatched. The PHP group fixed the problem immediately.

> Wasn't this new register_globals setting supposed to enhance security?

Now there's a non-sequitur if ever I saw one. "What do you mean I have to
stop running across the freeway? I thought giving up smoking was supposed
to enhance my health."

> How would you like to be a sys admin with dozens of machines to upgrade 
> before you can proceed with anythign else?

I upgraded dozens of machines. It took about 10 minutes total.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1

[Richard Lynch]

>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`...

You could have just *CHANGED* the setting in php.ini if it was that big a
friggin' deal.  I did.

>Now I get to upgrade my PHP install once a month or so cause of new 
>security holes..  Yay!

If you want to examine PHP's Security history *OBJECTIVELY* it will go
toe-to-toe against anything else in the same market.

>Wasn't this new register_globals setting supposed to enhance security?

Yes, and it does.

>How would you like to be a sys admin with dozens of machines to upgrade 
>before you can proceed with anythign else?

Ooooh, *dozens* of machines.  Why, that should take you at least an hour to
take care of, unless you want to sit there and twiddle your thumbs while the
text scrolls by.  Get a life!

>Can anyone say Ruby?

Can anyone say "No better"?

But, hey, we don't care.  Go use Ruby if that will make you happy.

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Richard Lynch]

>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;
>
>phpinfo() does not show new build times for each compile, not seemingly a
>caching problem (we have shut down browsers and then re-opened them to no
>avail as far as updated information).
>
>The configure command portion of phpinfo() does not show items we configured
>with PHP.
>
>GD throws errors; imageCreate() as an undefined function.


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, almost for sure your installation of the "new" PHP binary is not
happening correctly.

Watch carefully when you do "make install" to see where your new copies go.
Use "locate modphp.so" or whatever it is to find out where your old copies
are.

I'm betting they don't match up.

-- 
Like Music?  http://l-i-e.com/artists.htm


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security mailing list ...

[Evan Nemerson]

Well, you could always try bugtraq- i got an eMail there three hours before 
php-announce- although i slept through both and read them within about two 
mins. of one another...


On Monday 22 July 2002 15:55 pm, Jason Reid wrote:
> Some of the time.
>
> Release announcments have been skipped a few times, but you'll notice
> people asking on every other list about what the changes are.
>
> - Original Message -
> From: "Evan Nemerson" <[EMAIL PROTECTED]>
> To: "Dario Bahena Tapia" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Monday, July 22, 2002 9:19 AM
> Subject: Re: [PHP] php security mailing list ...
>
> > php-announce sends out notices.
> >
> > On Monday 22 July 2002 16:07 pm, Dario Bahena Tapia wrote:
> > > Hi ...
> > >
> > > I want to be warned about php security issues, I couldn't find
> > > an exact match in the mailing list names ... which one do you
> > > recommend me?
> > >
> > > Thanks in advance.
> > >
> > > saludos
> > > dario estepario ...
> >
> > --
> > Knowledge is power. Information is liberating. Education is the premise
> > of progress, in every society, in every family.
> >
> > Kofi Annan
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Take from the church the miraculous, the supernatural, the incomprehensible, 
the unreasonable, the impossible, the unknowable, the absurd, and nothing but 
a vacuum remains.

Robert G. Ingersoll


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security mailing list ...

[Jason Reid]

Some of the time.

Release announcments have been skipped a few times, but you'll notice people
asking on every other list about what the changes are.

- Original Message -
From: "Evan Nemerson" <[EMAIL PROTECTED]>
To: "Dario Bahena Tapia" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, July 22, 2002 9:19 AM
Subject: Re: [PHP] php security mailing list ...


> php-announce sends out notices.
>
>
>
> On Monday 22 July 2002 16:07 pm, Dario Bahena Tapia wrote:
> > Hi ...
> >
> > I want to be warned about php security issues, I couldn't find
> > an exact match in the mailing list names ... which one do you
> > recommend me?
> >
> > Thanks in advance.
> >
> > saludos
> > dario estepario ...
>
> --
> Knowledge is power. Information is liberating. Education is the premise of
> progress, in every society, in every family.
>
> Kofi Annan
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php security mailing list ...

[Evan Nemerson]

php-announce sends out notices.



On Monday 22 July 2002 16:07 pm, Dario Bahena Tapia wrote:
> Hi ...
>
> I want to be warned about php security issues, I couldn't find
> an exact match in the mailing list names ... which one do you
> recommend me?
>
> Thanks in advance.
>
> saludos
> dario estepario ...

-- 
Knowledge is power. Information is liberating. Education is the premise of 
progress, in every society, in every family.

Kofi Annan


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0and 4.2.1

[Rodolfo Gonzalez]

On Mon, 22 Jul 2002, 1LT John W. Holmes wrote:
> This other guy needs to quit his freakin whining and just do his job. Or go
> use ASP...the choice is yours.

Or JSP, for that matter. I've just discussing with a friend about this 
security issue, and he was trying to convince me to move to Java... :)




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0and 4.2.1

[Peter]

The superglobals have been a round for a bit so it's not as if everything's
got to be updated overnight.

I run PHP on windows and upgrading is just a matter of unzipping the archive
to my PHP folder and overwriting all the older files - dead simple. Don't
even have to change php.ini if I don't want to!


"Greg Donald" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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 install once a month or so cause of new
> security holes..  Yay!
>
> Wasn't this new register_globals setting supposed to enhance security?
>
> How would you like to be a sys admin with dozens of machines to upgrade
> before you can proceed with anythign else?
>
> Can anyone say Ruby?
>
>
> --
> Greg Donald
> http://destiney.com
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Jay Blanchard]

[snip]
Can anyone that has done it comment on the complexities of the upgrade?
[/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;

phpinfo() does not show new build times for each compile, not seemingly a
caching problem (we have shut down browsers and then re-opened them to no
avail as far as updated information).

The configure command portion of phpinfo() does not show items we configured
with PHP.

GD throws errors; imageCreate() as an undefined function.


We haven't moved on to our FreeBSD boxes yet.

Jay



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Matt Babineau]

Heh

ASP.

Hehehehehe

Matt Babineau
MCWD / CCFD
-
e: [EMAIL PROTECTED]
p: 603.943.4237
w: http://www.criticalcode.com
PO BOX 601
Manchester, NH 03105


-Original Message-
From: 1LT John W. Holmes [mailto:[EMAIL PROTECTED]] 
Sent: Monday, July 22, 2002 1:52 PM
To: Richard Baskett; PHP General
Subject: Re: [PHP] PHP Security Advisory: Vulnerability in PHP
versions4.2.0 and 4.2.1


> Well from the sound of it, it's a quick painless process to upgrade 
> php to the newest version using the patch.  Can anyone that has done 
> it comment
on
> the complexities of the upgrade?  Im just going on what it says on the

> php homepage...

Nice and easy for me, I'm running it on windows, though. Just delete the
old PHP folder, unzip and copy the new one, and restart IIS. (php.ini is
elsewhere).

This other guy needs to quit his freakin whining and just do his job. Or
go use ASP...the choice is yours.

---John Holmes...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[1LT John W. Holmes]

> Well from the sound of it, it's a quick painless process to upgrade php to
> the newest version using the patch.  Can anyone that has done it comment
on
> the complexities of the upgrade?  Im just going on what it says on the php
> homepage...

Nice and easy for me, I'm running it on windows, though. Just delete the old
PHP folder, unzip and copy the new one, and restart IIS. (php.ini is
elsewhere).

This other guy needs to quit his freakin whining and just do his job. Or go
use ASP...the choice is yours.

---John Holmes...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1

[Michael Geier]

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 putting me,
> you, and alot of others through then I guess that's just you.  I 
> can't help but get pissed about it.  I did not have the time to do 
> these upgrades, but now I have to make time.

php.ini: register_globals = on;

this would have allowed you to upgrade and keep your projects running 
until you converted them to $_ arrays.

And I think you seem to be taking things a little to personally.  

...hassles the php group is putting YOU through?

Let's see...does Andi, Zeev and Rasmus get paid to produce new 
versions of PHP?  Do you pay licensing fees for the product?  Maybe 
if there were fees, the Holy Trinity (grin) could create an update 
app that made your life easier for you.

The night CERT released the security alert, I upgraded 23 servers in 
less than an hour.  It is not hard work running three commands.  You 
are not going to get alot of sympathy from the 'group'.

-- 
Michael Geier
CDM Sports, Inc. - Systems Administrator
email: [EMAIL PROTECTED]
phone: 314.991.1511 x 6505
pager: 314.318.9414 || [EMAIL PROTECTED]




-
 This email sent using CDM Sports Webmail v2
[ http://webmail.cdmsports.com ]


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1

[Tyler Longren]

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
> 
> 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 install once a month or so cause of new 
> security holes..  Yay!
> 
> Wasn't this new register_globals setting supposed to enhance security?
> 
> How would you like to be a sys admin with dozens of machines to
> upgrade before you can proceed with anythign else?
> 
> Can anyone say Ruby?
> 
> 
> -- 
> Greg Donald
> http://destiney.com
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Richard Baskett]

Well from the sound of it, it's a quick painless process to upgrade php to
the newest version using the patch.  Can anyone that has done it comment on
the complexities of the upgrade?  Im just going on what it says on the php
homepage...

Rick

"When you walk to the edge of all the light you have and take that first
step into the darkness of the unknown you must believe that one of two
things will happen:
There will be something solid for you to stand upon or, you will be taught
how to fly." - Patrick Overton

> From: Greg Donald <[EMAIL PROTECTED]>
> Date: Mon, 22 Jul 2002 12:30:50 -0500 (CDT)
> 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 down the line (if they even admit a hole exists). Plus, if
> 
> Who said anything about M$?  I don't use their crappy products so I
> don't have to deal with their security issues.
> 
>> your running anything past 4.1.2 on production systems, it's your own
>> damn fault because several times it has been said that the 4.2 series
>> wasn't considered safe for production use. And by the way, don't want to
> 
> If PHP 4.2 is unsafe then why is it listed at the top of the page for
> download?  There is not a shread of text saying do not use in production,
> no unsafe warnings whatsoever.  How am I supposed to magically find the
> 'do not use' warnings?
> 
>> use PHP anymore because of this? Then don't. PHP doesn't need you, the
>> rest of the people who can handle an update without whining will be
>> fine.
> 
> 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 putting me, you,
> and alot of others through then I guess that's just you.  I can't
> help but get pissed about it.  I did not have the time to do these
> upgrades, but now I have to make time.
> 
> 
> -- 
> Greg Donald
> http://destiney.com
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0and 4.2.1

[Greg Donald]

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 down the line (if they even admit a hole exists). Plus, if

Who said anything about M$?  I don't use their crappy products so I 
don't have to deal with their security issues.

>your running anything past 4.1.2 on production systems, it's your own
>damn fault because several times it has been said that the 4.2 series
>wasn't considered safe for production use. And by the way, don't want to

If PHP 4.2 is unsafe then why is it listed at the top of the page for 
download?  There is not a shread of text saying do not use in production, 
no unsafe warnings whatsoever.  How am I supposed to magically find the 
'do not use' warnings?

>use PHP anymore because of this? Then don't. PHP doesn't need you, the
>rest of the people who can handle an update without whining will be
>fine.

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 putting me, you, 
and alot of others through then I guess that's just you.  I can't 
help but get pissed about it.  I did not have the time to do these 
upgrades, but now I have to make time.


-- 
Greg Donald
http://destiney.com


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and 4.2.1

[Adam Voigt]

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 several times it has been said that the 4.2 series
wasn't considered safe for production use. And by the way, don't want to
use PHP anymore because of this? Then don't. PHP doesn't need you, the
rest of the people who can handle an update without whining will be
fine.

Adam Voigt
[EMAIL PROTECTED]

On Mon, 2002-07-22 at 12:55, Greg Donald wrote:
> 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 install once a month or so cause of new 
> security holes..  Yay!
> 
> Wasn't this new register_globals setting supposed to enhance security?
> 
> How would you like to be a sys admin with dozens of machines to upgrade 
> before you can proceed with anythign else?
> 
> Can anyone say Ruby?
> 
> 
> -- 
> Greg Donald
> http://destiney.com
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0and 4.2.1

[Greg Donald]

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 install once a month or so cause of new 
security holes..  Yay!

Wasn't this new register_globals setting supposed to enhance security?

How would you like to be a sys admin with dozens of machines to upgrade 
before you can proceed with anythign else?

Can anyone say Ruby?


-- 
Greg Donald
http://destiney.com


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions4.2.0 and4.2.1

[Jeff Bearer]

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 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 because of security issues...
> >
> > ---John Holmes...
> 
> As the Advisory suggests, the security fault affects only the 2 latest 
> versions of PHP, all the people running older PHPs are not affected, so 
> unless you've had the very latest stuff running this won't affect you and 
> there will be no need to upgrade.  
> If anything this will only convince people looking for 'stable' PHP to wait 
> even longer before upgrading their releases because of potential bugs such as 
> this one creeping up in 'new' releases.
> 
> Ilia
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jeff Bearer, RHCE
Webmaster, PittsburghLIVE.com
2002 EPpy Award Winner, Best Newspaper Website


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and4.2.1

[Ilia A.]

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 because of security issues...
>
> ---John Holmes...

As the Advisory suggests, the security fault affects only the 2 latest 
versions of PHP, all the people running older PHPs are not affected, so 
unless you've had the very latest stuff running this won't affect you and 
there will be no need to upgrade.  
If anything this will only convince people looking for 'stable' PHP to wait 
even longer before upgrading their releases because of potential bugs such as 
this one creeping up in 'new' releases.

Ilia

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and4.2.1

[1LT John W. Holmes]

[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 because of security issues...

---John Holmes...


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Security

[Miguel Cruz]

On Mon, 29 Apr 2002, Jay Fitzgerald wrote:
> Can someone point me in the right direction in determining just how secure 
> PHP really is?

What are you actually trying to find out?

As far as actual security problems in PHP, where the interpreter behaves
contrary to documentation when provided with extraordinary inputs, the
team has been very responsive with fixes (in contrast with, say,
Microsoft).

If you are wondering about the security of any given application developed 
in PHP, well, that's up to the developers of that application.

miguel


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Leak (plaintext)

[John Holmes]

> $my_val_a = addslashes($HTTP_POST_VARS["val_a"]);
> $my_val_b = addslashes($HTTP_POST_VARS["val_b"]);
> $query = "INSERT INTO foo (a,b) VALUES ($my_val_a,$my_val_b)";
> 
> Or if you have magic_quotes_gpc turned on (the default) all vars
passed
> in from forms/cookies are quoted and SQL injection is not possible.

Actually, this way you are not doing anything. By the format of your
INSERT statement, you are assuming that $my_val_a and $my_val_b are
numbers, since there are no quotes around them. Therefore addslashes()
does nothing to prevent the user from putting a value like --> 12,'bad
value')# <-- into $my_val_a and putting a bad value into the second
column. 

Now if you validate that the two are numbers, then you won't have this
problem. And if you are validating a string, yes then use addslashes(),
and the # won't be able to act as a comment, then.

---John Holmes... 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Leak (plaintext)

[Richard Archer]

At 4:00 PM -0500 25/4/02, Joshua b. Jore wrote:

>"INSERT INTO foo (a,b) VALUES (?,?)"

$my_val_a = addslashes($HTTP_POST_VARS["val_a"]);
$my_val_b = addslashes($HTTP_POST_VARS["val_b"]);
$query = "INSERT INTO foo (a,b) VALUES ($my_val_a,$my_val_b)";

Or if you have magic_quotes_gpc turned on (the default) all vars passed
in from forms/cookies are quoted and SQL injection is not possible.

 ...R.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP Security Leak (plaintext)

[John Holmes]

> I think you misunderstood me. I already have a
AuthenticateUser(TEXT,TEXT)
> function that works great. What I don't understand is how to get PHP
to
> use place holders for data binding. This is more generic database
issue. I
> could have also written:
> 
> "INSERT INTO foo (a,b) VALUES (?,?)"
> 
> where again, the values are passed separately and are *not*
interpolated
> into the query. That's the point - not interpolating your values to
> protect against insertion attack.

I'm sure you are already doing this, but enough can't be said for
validation. Make sure what you think is a number really is, and that a
string is properly quoted...then this won't be a problem.

---John Holmes... 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php