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 liście Andi Gutmans z d
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
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
this case is that shared hosters d
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
Tom Sommer wrote:
> On Fri, January 5, 2007 01:13, Ilia Alshanetsky wrote:
>
>> With this release we are nearing the final stretch is the release
>> cycle, so I'd like to ask all developers to refrain from making any commits
>> to the 5.2 tree that are not bug fixes. If all goes well the final RC
On Fri, January 5, 2007 01:13, Ilia Alshanetsky wrote:
> With this release we are nearing the final stretch is the release
> cycle, so I'd like to ask all developers to refrain from making any commits
> to the 5.2 tree that are not bug fixes. If all goes well the final RC
> (RC3) will be available
42 matches
Mail list logo
