+1. I think Greg's suggestion would be a very good solution, combined with the
existing 'allow_url_fopen' feature to protect 1st level calls:
1. User stream wrappers are not an 'exotic' feature reserved to some exotic
hackers as some
seem to think. It is not because you never used them that it
ew and might be completely wrong...
> -Original Message-
> From: Arnold Daniels [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 18, 2007 6:16 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Comments on PHP security
>
> I vote 1 as well.
>
> The p
I vote 1 as well.
The problem only occurs if the function is used insecurely by the
developer. There are a few functions which are implemented insecurely a
lot. Since these holes are always the same, hackers will try to use
this. So fixing 90% of the problems would not leave the hacker with
enough
On Thu, Jan 18, 2007 at 01:13:51AM -0800, Stanislav Malyshev wrote:
> >I am with Arnold on this one. Implement a patch that fixes the source of
> >most of
> >the problems, tidy the rest at leisure. Better to get an effective fix
> >quickly
> >than wait forever for perfection.
>
> Security soluti
I am with Arnold on this one. Implement a patch that fixes the source of most of
the problems, tidy the rest at leisure. Better to get an effective fix quickly
than wait forever for perfection.
Security solution can't plug 90% of holes and then leave the rest for
leisure... Effective fix means
On Wed, Jan 17, 2007 at 11:18:50AM -0800, Stanislav Malyshev wrote:
> >Which functions am I forgetting?
>
> All using php_stream_open*. I see 38 files in the php source tree using
> this function. You probably would have to go to each of them and change
> each instance to support your flag. That
Which functions am I forgetting?
All using php_stream_open*. I see 38 files in the php source tree using
this function. You probably would have to go to each of them and change
each instance to support your flag. That's the safe mode story again -
you plug 90% quickly and then spend forever t
Stanislav Malyshev schreef:
fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output',
'ru').
What about all other function using streams that do not have fopen
arguments? The whole idea of streams was for the things to work
transparently with all functions, if it were only about fop
fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 'ru').
What about all other function using streams that do not have fopen
arguments? The whole idea of streams was for the things to work
transparently with all functions, if it were only about fopen there were
no reason to do
Sudo starts a new process under another user. Currently it isn't
possible to switch the user of the running process. This patch allows to
switch the user of the running process and also allows to switch back to
the original user. Only specific users may switch to other specific
users (the same
On Wed, Jan 17, 2007 at 01:38:57PM +0100, Arnold Daniels wrote:
> Hi again,
>
> Yes we can share it with the world, but first it should be reviewed by
> others to see if we haven't missed anything which makes the system less
> secure instead of more. Also the source code is currently really dirt
Hi again,
Yes we can share it with the world, but first it should be reviewed by
others to see if we haven't missed anything which makes the system less
secure instead of more. Also the source code is currently really dirty
and specified on our situation (to little to config, mod_diffpriv also
Hi Arnold, Alain,
- Original Message -
From: "Alain Williams"
Sent: Wednesday, January 17, 2007
> On Wed, Jan 17, 2007 at 12:45:37AM +0100, Arnold Daniels wrote:
> > Hi,
> > [...]
> > Last, I'm a software developer at a shared hosting company. To my
> > opinion, making sure that users don
On Wed, Jan 17, 2007 at 12:45:37AM +0100, Arnold Daniels wrote:
> Hi,
>
> First of all I admit I'm no PHP security expert or PHP internals expert
> or anything, so please don't flame me if I say something stupid.
>
> Wouldn't simply adding a flag to allow url's (which includes all '*://'
> stream
Actually, the solution I was envisioning would not allow any access to
fsockopen() or other remote streams access things inside a user stream
wrapper.
Are you sure you can evaluate ALL engine functions that allow accessing
remote data? Looks dangerously like safe mode...
--
Stanislav Malyshev,
Stanislav Malyshev wrote:
>> In my opinion, it would be a pity to lose the design benefits of stream
>> wrappers in the effort to gain more security when security can be gained
>> without losing the benefits. I think it would be good to allow
>> disabling all urls as Stefan suggested, but if there
Hi,
First of all I admit I'm no PHP security expert or PHP internals expert
or anything, so please don't flame me if I say something stupid.
Wouldn't simply adding a flag to allow url's (which includes all '*://'
streams), in functions that opens streams be enough? For example:
fopen($file, 'r')
In my opinion, it would be a pity to lose the design benefits of stream
wrappers in the effort to gain more security when security can be gained
without losing the benefits. I think it would be good to allow
disabling all urls as Stefan suggested, but if there is a way to
restrict to truly local
Stefan Esser wrote:
> Greg,
>
> i was not talking about providing all the different versions of include.
Ah, was this include_url some kind of ini setting you were talking about?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
> SE>>And If I am not completely mistaken here unlike php://filter a
> SE>>userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream
> SE>>itself opens.
>
> I think I see what you mean now - i.e. that the user implementation might
> be tricked into opening UR
SE>>And If I am not completely mistaken here unlike php://filter a
SE>>userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream
SE>>itself opens.
I think I see what you mean now - i.e. that the user implementation might
be tricked into opening URL for include even though direct openi
MB>> I always have control of what I program. I alwayshavecontrol of
MB>>whichfiles I load. Ergo there is no security issue - WOW.
I'm afraid you lost me. Could you please explain why you considering user
streams to be security threat without resorting to sarcasm?
--
Stanislav Malyshev, Zend P
Greg,
i was not talking about providing all the different versions of include.
For me it is a broken application design to include anything out of an
URL wrapper.
However it would also be fine to just have allow_url_include affect all
URLs and to be
setable by ini_set() and be turned off by defau
Stanislav,
you obviously did not get the point...
It is not about including URL stream wrappers that youself provide.
It is about URL Include vulnerabilities in the application that allow
remote attackers to issue attacks against Userstreams of the application.
I would not be suprised to see so
Hello Stanislav,
I always have control of what I program. I alwayshavecontrol of whichfiles
I load. Ergo there is no security issue - WOW.
best regards
marcus
Sunday, January 14, 2007, 12:03:04 PM, you wrote:
MB>>> i also think something should be done here. The is_url flag does not
MB>>>re
MB>> i also think something should be done here. The is_url flag does not
MB>>really help. What we imho need is an ini setting that allows
MB>>specifying which stream handlers to allow. And that should not include
MB>>user streams.
I don't see how user streams have anything to do with it - if
Wez Furlong wrote:
On 1/13/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
SQLite does not natively support prepared statements anyways.
Yes it does :)
Ah, I got thrown off by the use of the word "precompile" which they also
used to describe dumps of the byte code generated by the SQL comp
On 1/13/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
SQLite does not natively support prepared statements anyways.
Yes it does :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stefan Esser wrote:
> My 2cents,
>
> the actually best would be to completely forbid the usage of URLs inside
> include/require and
> introduce a new keyword: include_url that works like the current include
> would work and
> rename allow_url_include into allow_dangerous_urls (for include_url only
Stefan Esser wrote:
> It is very good that bugs in PHP Applications are bad for PHP's image.
> The majority of servers get hacked because of Remote URL Includes (and
> not by XSS/SQL Injection). The existance of Remote URL Includes is fully
> to blame on the PHP engine and is UNIQUE. After years th
My 2cents,
the actually best would be to completely forbid the usage of URLs inside
include/require and
introduce a new keyword: include_url that works like the current include
would work and
rename allow_url_include into allow_dangerous_urls (for include_url only).
Basically this would protect e
Hello Ilia,
what i wanted it a SYSTEM INI setting that allows which streams work
exactly. As opposedto being able to select between all and none while
hoping that the switch works (for the reasons you specified).
best regards
marcus
Saturday, January 13, 2007, 6:22:33 PM, you wrote:
> Marcus,
I thought we also decided to default user streams to be marked as
insecure with some mechanism for overriding it.
-Rasmus
Ilia Alshanetsky wrote:
> Marcus,
>
> You want to use an INI setting to specify which streams are local and
> which are remote? That seems like a recipe for disaster to me, p
Marcus,
You want to use an INI setting to specify which streams are local and
which are remote? That seems like a recipe for disaster to me, people
adjusting this setting many not consider some streams that are remote
etc... leading to security holes. There is really no reason why PHP
cou
Hello Stefan,
i also think something should be done here. The is_url flag does not
really help. What we imho need is an ini setting that allows specifying
which stream handlers to allow. And that should not include user streams.
best regards
marcus
Saturday, January 13, 2007, 5:59:45 PM, you w
> I am not sure I would call it a blacklist. It is a flag in the streams
> layer that marks stream handlers that could possibly make a network
> connection as such and there are only a finite set of stream handlers.
>
Unfortunately there is not a finite set of stream handlers. First of all
the
Stefan Esser wrote:
> It is very good that bugs in PHP Applications are bad for PHP's image.
> The majority of servers get hacked because of Remote URL Includes (and
> not by XSS/SQL Injection). The existance of Remote URL Includes is fully
> to blame on the PHP engine and is UNIQUE. After years th
Stefan Esser wrote:
SELECT xyz FROM abc WHERE product_id IN ( 1,2,3,4,5) <- the list having
dynamic lenght
They have worked in PEAR::DB and some other DBAL's, as a result a lot of
people have come to think of prepared statements as a sprintf() replacement.
By the nature of prepared stateme
Stefan Esser wrote:
Hello Lukas,
Maybe I am missing something. If you are talking about dynamic query
generation in stored routines, then I would think that people who read
the advice over dynamic query generation for PHP, that they would
hopefully also apply those practices to when they are wr
Hello Lukas,
> Maybe I am missing something. If you are talking about dynamic query
> generation in stored routines, then I would think that people who read
> the advice over dynamic query generation for PHP, that they would
> hopefully also apply those practices to when they are writing/using
> s
Stefan Esser wrote:
While it is true that the PHP script is not subject to SQL injection
when the application does not build parts of the query based on
untrusted userinput it is not true that you are not at risk.
Ever heard of stored procedures? And precisely of SQL injection in
stored procedur
Mathieu CARBONNEAUX schrieb:
>> http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements
>>
> Sorry for my buz...
> This piece of manual say the same i've said...
>
Yeah and it is wrong. The manual claims the following:
> The parameters to prepared statements don't need to be quote
> I don't think you've read the section on prepared statements in the
> PDO documentation, because it does mention it there, although it
> doesn't beat you over the head with the seriousness of the problem.
>
> http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements
Sorry for my buz...
> A quick google search for 'sql injection prepared statements' found
> those 2 statements (1 is a security article) very quickly.
> ...And frankly, its not the manual's job to tell you how to
> write secure code. So, this has to be coming from people.
>
Yes but a php security portal that referen
>Limits, table names, and several other query parts are protected by
>MediaWiki's query builder. A complex select query might look like this:
>
>$result = $db->select(
># Tables
>array( 'user', 'revision' ),
># Fields
>array( 'user_name', 'rev_timestamp' ),
># Conditions (WHERE)
On 1/12/07, Brian Moon <[EMAIL PROTECTED]> wrote:
The PHP manual nor
the MySQL manual mentions sql injection when talking about prepared
statements.
I don't think you've read the section on prepared statements in the
PDO documentation, because it does mention it there, although it
doesn't beat
On 1/12/07, Michael B Allen <[EMAIL PROTECTED]> wrote:
On Fri, 12 Jan 2007 11:40:32 -0500
Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
> >
> > Limits, table names, and several other query parts are protected by
> > MediaWiki's query builder.
On Fri, 12 Jan 2007 11:40:32 -0500
Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
> >
> > Limits, table names, and several other query parts are protected by
> > MediaWiki's query builder. A complex select query might look like this:
> >
> > $r
> And using prepare statement to pass variable by binding variable
> is simple good programming (and must be used with many other good
> practice...input check...)
> And effectively is the variable binding and not the prepare
> statement that add real security again sql injection...
> but actualy
Robert Cummings wrote:
> Wow, that's hideous!
Only because I chose a complex example, to demonstrate its capabilities.
It's a great deal easier than the equivalent string wrangling. SQL is
meant to be human readable. It's not particularly well-suited to
construction from PHP data types, or to pars
On Fri, 2007-01-12 at 15:57 +, Tim Starling wrote:
>
> Limits, table names, and several other query parts are protected by
> MediaWiki's query builder. A complex select query might look like this:
>
> $result = $db->select(
> # Tables
> array( 'user', 'revision' ),
> # Fields
>
Brian Moon wrote:
> Mathieu CARBONNEAUX wrote:
>> but i think some good security idea have been said, for exemple using
>> "prepare statement" to avoid sql injection...
>
> We really need to stop spreading this myth that prepared statements are
> a security measure. Prepared statements only allow
Hello Andi,
On 1/11/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Do we need to provide better tools for our developers? Definitely! This is why
we are working on ext/filter (I agree the first pass
wasn't very successful), a filter extension in Zend Framework, and other best
practices.
What d
_
From: Vlad Bosinceanu [mailto:[EMAIL PROTECTED]
What might help is pushing (via the manual) for the adoption of tools
that prevent common problems, with pdo's prepared statements being one
such tool.ok, documenting is what i say...
but not all use php5 pdo... not all use php5... many
_
From: Brian Moon [mailto:[EMAIL PROTECTED]
We really need to stop spreading this myth that prepared statements are
a security measure. Prepared statements only allow passing of the value
parts of where clauses and a couple of other parts of the query. Limit
values would be the most c
On 1/11/07, Pierre <[EMAIL PROTECTED]> wrote:
Hi Stefan,
On 1/11/07, Stefan Esser <[EMAIL PROTECTED]> wrote:
>
> > For your information, zip is not enabled by default. If you have a
> > bug/issue about the specific zip:// URL, please let me know. Ilia and
> > Tony already fixed some paths fixes
It's better than having to deal with sql at a lower level, while not as
good as proper training. Which is more likely we will see happening? I
really doubt it's the latter.
Should PHP babysit the programmer to ensure he dosen't screw up? Not
really, IMO. There's good docs available, but what b
Mathieu CARBONNEAUX wrote:
but i think some good security idea have been said, for exemple using "prepare
statement" to avoid sql injection...
We really need to stop spreading this myth that prepared statements are
a security measure. Prepared statements only allow passing of the value
part
i'm not very java fan... but i think majority of java application not
use any JNI module... because of this risk and because in majority
situation all necesary can be coded and are coded in full java...
Well, here's the difference - PHP uses it's "JNI" a lot. Thus we can't
use same model as Ja
>I'm pretty sure these things are not covering, for example, JNI modules.
>Extensions are basically JNI of PHP.
i'm not very java fan... but i think majority of java application not use any
JNI module... because of this risk and because in majority situation all
necesary can be coded and are c
At 23:51 11-01-07, Stefan Esser wrote:
Zeev,
I don't know why you believe that I reported crash bugs. Yes of course
the local exploits I sent to [EMAIL PROTECTED] were only crashing PHP,
because they were 1-2-3 line Proof Of Concept Codes.
Except for one DOS only bug all the bugs can be exploite
Zeev,
I don't know why you believe that I reported crash bugs. Yes of course
the local exploits I sent to [EMAIL PROTECTED] were only crashing PHP,
because they were 1-2-3 line Proof Of Concept Codes.
Except for one DOS only bug all the bugs can be exploited to execute
arbitrary code or access mem
Stefan,
I'll concentrate on the technology aspect.
The situation in other languages has everything to do with PHP. It's
fine that you decided to concentrate in PHP, but the fact exactly the
same problem exists in other languages suggests it's an inherent
problem, and not something unique to
It wasn't me who's been asked, but at least for Java, the answer is yes. You
can declare privileges for the code based on where it is located (in the
filesystem tree). That should be sufficient, if used properly.
I'm pretty sure these things are not covering, for example, JNI modules.
Extensio
First of all PHP group is doing nothing. Neither do they improve PHP's
security nor do they stop well known PHP license abusers (because they
are friends).
OK, that's just not true and it is obvious to anybody with access to the
commit logs (namely, everybody) - bugs are getting fixed and
impr
W liście Andi Gutmans z dnia czwartek, 11 stycznia 2007 21:48:
> How familiar are you with Java in shared hosting environments?
Been hacking one mayor Java app to make it work with JSM. Not much, but I
believe Sun took much care to make sure JSM works as advertised.
--
Paweł Stradomski
--
PHP
How familiar are you with Java in shared hosting environments?
> -Original Message-
> From: Paweł Stradomski [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2007 12:12 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Comments on PHP security
>
> W
Andi,
> Stefan, do you truly believe that other languages allow for secure shared
> hosting without using a setuid or chroot solution? I mean
> take Ruby, Python, Java, C/C++. Can you point out one of them which would not
> have the issues that PHP has? I think the problem in
>
How it the fitn
Ilia Alshanetsky wrote:
>
> On 11-Jan-07, at 9:41 AM, Alain Williams wrote:
>
>> This has just appeared:
>>
>> http://www.theregister.co.uk/2007/01/11/php_apps_security/
>
> Of many people who use PHP not many have strong programming background
> and even fewer experience with security. The
W liście Andi Gutmans z dnia czwartek, 11 stycznia 2007 20:53:
> Stefan, do you truly believe that other languages allow for secure shared
> hosting without using a setuid or chroot solution? I mean take Ruby,
> Python, Java, C/C++.
It wasn't me who's been asked, but at least for Java, the answer
Esser [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2007 8:05 AM
> To: Rasmus Lerdorf
> Cc: Alain Williams; internals@lists.php.net; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Comments on PHP security
>
> Hello Rasmus,
> > There are some concrete suggestions in th
That was my intent when I joined the list. I wanted to get a feel for
the community and the development process. This is the first
open-source project that I've considered contributing to, so it's all
new to me. I still plan to dive into it, but it's disheartening to see
some of these petty argume
Rather then commenting on what other people should and should not do,
do something productive like fix bugs or help to extend the PHP test
suit.
On 11-Jan-07, at 2:23 PM, Jordan Moore wrote:
This is pathetic. I thought most of you were adults, but I really
can't tell sometimes.
Why can't t
This is pathetic. I thought most of you were adults, but I really
can't tell sometimes.
Why can't this be discussed without everyone getting upset and
snapping at each other? The biggest problem with PHP right now is how
thick-headed and cocky some of the posters to this list are. Grow up,
and th
> I wonder what do you mean by that - that PHP group should publish
> press release "PHP is not secure, please do not use it anymore" or
> what? I see PHP group is working quite well eliminating the security
> issues. As far as I know, last year there was 7 remotely exploitable
> issues in PHP (wh
PS: Stop the "We are secure" marketing and face reality
I wonder what do you mean by that - that PHP group should publish press
release "PHP is not secure, please do not use it anymore" or what? I see
PHP group is working quite well eliminating the security issues. As far
as I know, last year
On 11-Jan-07, at 12:53 PM, Alain Williams wrote:
On Thu, Jan 11, 2007 at 06:44:35PM +0100, Derick Rethans wrote:
That is why there is a concept called "testing" [1] and code coverage
[2].
[1]. http://phpunit.de/
[2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-
Reports-with-PHPU
On Thu, Jan 11, 2007 at 06:44:35PM +0100, Derick Rethans wrote:
> That is why there is a concept called "testing" [1] and code coverage
> [2].
>
> [1]. http://phpunit.de/
> [2].
> http://sebastian-bergmann.de/archives/578-Code-Coverage-Reports-with-PHPUnit-3.html
You are an experienced and car
On Thu, 11 Jan 2007, Alain Williams wrote:
> On Thu, Jan 11, 2007 at 12:26:17PM -0500, Ilia Alshanetsky wrote:
> >
> > On 11-Jan-07, at 12:11 PM, Alain Williams wrote:
> > >The discussion is how PHP can help them to discover problems in their
> > >scripts. This is what led to Wietse Venema's sugg
On Thu, Jan 11, 2007 at 12:26:17PM -0500, Ilia Alshanetsky wrote:
>
> On 11-Jan-07, at 12:11 PM, Alain Williams wrote:
> >The discussion is how PHP can help them to discover problems in their
> >scripts. This is what led to Wietse Venema's suggestion about tainting
> >a few weeks ago. These may be
On 11-Jan-07, at 12:11 PM, Alain Williams wrote:
The discussion is how PHP can help them to discover problems in their
scripts. This is what led to Wietse Venema's suggestion about tainting
a few weeks ago. These may be things that members of this forum do not
feel that they need, but the ''qual
On Thu, Jan 11, 2007 at 12:05:45PM -0500, Ilia Alshanetsky wrote:
>
> On 11-Jan-07, at 9:41 AM, Alain Williams wrote:
>
> >This has just appeared:
> >
> > http://www.theregister.co.uk/2007/01/11/php_apps_security/
>
> Of many people who use PHP not many have strong programming
> background
On 11-Jan-07, at 9:41 AM, Alain Williams wrote:
This has just appeared:
http://www.theregister.co.uk/2007/01/11/php_apps_security/
Of many people who use PHP not many have strong programming
background and even fewer experience with security. The use PHP
because it makes it easy
Safe mode does suck, and it utterly useless anyone who knows PHP
internals will happily tell you that.
On 11-Jan-07, at 11:25 AM, Mark Krenz wrote:
On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams
[EMAIL PROTECTED] said the following:
On Thu, Jan 11, 2007 at 05:04:30PM +0100, Stefan
On Thu, Jan 11, 2007 at 05:38:58PM +0100, Christian Schneider wrote:
> Alain Williams wrote:
> > One problem that I see persistently have is forgetting to declare variable
> > 'global'
> > in a function ... you only find out that something is wrong when the program
> > misbehaves. Forcing variable
Alain Williams wrote:
> One problem that I see persistently have is forgetting to declare variable
> 'global'
> in a function ... you only find out that something is wrong when the program
> misbehaves. Forcing variable declaration would help here.
a) You should never use 'global' under normal ci
Hi Stefan,
On 1/11/07, Stefan Esser <[EMAIL PROTECTED]> wrote:
> For your information, zip is not enabled by default. If you have a
> bug/issue about the specific zip:// URL, please let me know. Ilia and
> Tony already fixed some paths fixes and the fixes are available in
> zip-1.8.4. They will
On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams [EMAIL PROTECTED] said
the following:
> On Thu, Jan 11, 2007 at 05:04:30PM +0100, Stefan Esser wrote:
>
> > PS: Stop the "We are secure" marketing and face reality
>
> More to the point: ''We might be secure because we are careful experience
> For your information, zip is not enabled by default. If you have a
> bug/issue about the specific zip:// URL, please let me know. Ilia and
> Tony already fixed some paths fixes and the fixes are available in
> zip-1.8.4. They will be in 5.2.1.
For your information Pierre: Security Bugs in PHP ar
On Thu, Jan 11, 2007 at 05:04:30PM +0100, Stefan Esser wrote:
> PS: Stop the "We are secure" marketing and face reality
More to the point: ''We might be secure because we are careful experienced
programmers'',
however many of those who write in PHP are not careful and/or experienced, we
should
Hello Stefan,
On 1/11/07, Stefan Esser <[EMAIL PROTECTED]> wrote:
Hello Rasmus,
> There are some concrete suggestions in the article that we addressed a
> while ago. Things like:
>
> "I'd like to see new defaults that limit include() and require() to
>only allow local files, thereby avoid
Stefan Esser wrote:
> Hello Rasmus,
>> There are some concrete suggestions in the article that we addressed a
>> while ago. Things like:
>>
>> "I'd like to see new defaults that limit include() and require() to
>>only allow local files, thereby avoiding remote file injection."
>>
>> That's t
On Thu, Jan 11, 2007 at 08:06:16AM -0800, Rasmus Lerdorf wrote:
> Alain Williams wrote:
> > On Thu, Jan 11, 2007 at 07:43:21AM -0800, Rasmus Lerdorf wrote:
> >> Alain Williams wrote:
> >>> This has just appeared:
> >>>
> >>> http://www.theregister.co.uk/2007/01/11/php_apps_security/
> >> There ar
Hello Rasmus,
> There are some concrete suggestions in the article that we addressed a
> while ago. Things like:
>
> "I'd like to see new defaults that limit include() and require() to
>only allow local files, thereby avoiding remote file injection."
>
> That's the default in PHP 5.2.0 which
Alain Williams wrote:
> This has just appeared:
>
> http://www.theregister.co.uk/2007/01/11/php_apps_security/
There are some concrete suggestions in the article that we addressed a
while ago. Things like:
"I'd like to see new defaults that limit include() and require() to
only allow
This has just appeared:
http://www.theregister.co.uk/2007/01/11/php_apps_security/
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
h
96 matches
Mail list logo
