Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

Hi Joe,


The sense in native support for AST is questionable.


On one hand this allows syntax verification.


On the other hand simple string may be parsed into AST with just one additional 
call to ast\compile_string().


Thanks. Dmitry.



From: Joe Watkins 
Sent: Wednesday, May 11, 2016 7:46:09 AM
To: Björn Larsson
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support for 
AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may be counted as a 
vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes without AST, and there 
is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson 
> wrote:
Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:


On 05/11/2016 12:29 AM, Björn Larsson wrote:
Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
it's not going to be the end of the world, if we decided to live with 
doc-comments only.


Thanks. Dmitry.

Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

The more I listen to arguments of adepts of existing PHP annotation systems, 
the more I think, that "PHP attributes" is the right name for this proposal.
This feature is not just for PHP annotation systems.

Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Pierre,

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye  wrote:
> The current session code and designs is old, very old. It does not match
> today ways to do things. Every time we fix it, I see a band aid fix.

Let's rewrite session module someday.
In the meantime, I would like to add features to make session
management like TCP.

We don't have to care about authenticity (CSRF) with TLS/TCP, but web
developers must care with TLS/HTTP :(

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Pierre Joye]

On May 11, 2016 11:46 AM, "Yasuo Ohgaki"  wrote:

> Thank you for your comments. I've updated the RFC. You might like this
version.
>

I still think we should not have that in core. If we do, it should be
controlled by the application implementation and not ini settings (some
routes may have it, other not, some route may have different ttl etc). I am
not even sure it should be part of the session module.

Sessions are per definiton easy. Implement them correctly (whatever that
means) is hard. Adding csrf to ext/session feels like adding auth methods
as well. Both csrf ans auth may need sessions but they are not part of the
session features.

Cheers,
Pierre

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Joe Watkins]

Morning,

> In this case, it is currently impossible to write a single configuration
file that will work in both environments, forcing developers to manually
maintain two separate versions of the file.

I'm aware this has been mentioned in this thread, and I've read the open
issue disclaimer.

The RFC does not solve the problem it is trying to solve.

It's still going to be impossible to have a single configuration file. The
only win seems to be when using php from the command line, or in
documentation.

Since the mechanism for loading extensions has been the same for so long,
and since that knowledge is well dispersed among those who require it, I'm
not really seeing the point in changing anything.

The idea that we could one day have a configuration file for both platforms
seems like a pipe dream, so this can't really be considered a "step closer"
to that; It's never going to happen.

Cheers
Joe

On Tue, May 10, 2016 at 11:27 PM, François Laupretre 
wrote:

> Hi,
>
>
> Le 10/05/2016 à 22:07, Lester Caine a écrit :
>
>> Windows did not worry about which extension was used
>> in the past, but nowadays the problem is ensuring the correct build of
>> extension is accessed and while 32bit is still the safer base, it's all
>> too easy to get them mixed up with 64bit builds. All of MY recent
>> windows installs have had to be 32bit so this creates a conflict with
>> PHP7's assumption that modern target will be 64bit ;) TODAY the windows
>> php.ini needs to be managed to ensure that the correct paths are used to
>> the correct build, and personally I'd rather not 'simplify' something
>> which has a much bigger impact - and adding a build identifier to the
>> file name may be a better fix than trying to rely on the path to ensure
>> the correct build is accessed.
>>
>
> Right. We could include a build ID in file names. And adapt the way we
> compute file names from extension names. But I don't see how this concern
> conflicts with the RFC.
>
> Regards
>
> François
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Niklas,

On Wed, May 11, 2016 at 1:40 PM, Niklas Keller  wrote:
> Yasuo Ohgaki  schrieb am Mi., 11. Mai 2016 00:05:
>>
>> Hi Stas,
>>
>> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
>>  wrote:
>> >> What happens with applications that do not produce HTML at all, such as
>> >> REST,
>> >>  - These apps may add SESSCSRF value manually.
>> >
>> > Add where? And where that value would come from? RFC says nothing about
>> > that.
>>
>> As usual. Query parameter when GET is used. Additional input when POST
>> is used. All users have to do is adding CSRF token to JS program.
>
>
> Again: GET doesn't need any protection, it must be idempotent.
>
> Query parameter is a very bad idea, just like session IDs in the query
> parameter are a bad idea. Maybe we should think about removing support for
> it.

I agree users should use POST rather than GET.
However, there many codes use GET and it could be used safely.
e.g. Many web API uses AUTH key in query strings. It's not security
issue because of its usage.

So I didn't ignore GET usage.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] run-tests.php improvement for PHP 7.0+

[Joe Watkins]

Morning,

I would prefer adding a zend extensions section, there might not be
that many in zend extensions in the wild, but there are behind closed doors.

Cheers
Joe

On Tue, May 10, 2016 at 7:13 AM, Benjamin Eberlei 
wrote:

> On Tue, May 10, 2016 at 6:36 AM, Matt Ficken 
> wrote:
>
> > An INI section wouldn't have the extension directory path AND wouldn't
> > have the name of the SO to load. On Windows, its
> > zend_extension=php_opcache.DLL. Typically the same opcache, etc...
> > feature/test should work across os platforms.
> >
>
> ah yes of course, sorry for the noise :)
>
> >
> > OpCache tests can just use a SKIPIF section to be skipped unless the user
> > has configured OpCache to be loaded. Forcing OpCache to be loaded makes
> > sure that test gets run during a casual test run (somebody just running
> > `make test`). That's what a ZEND_EXTENSION section would do. There are
> > several new section types already.
> >
> > If you really want to add a ZEND_EXTENSIONS section, that's fine.
> >
> > It is important though to have SKIPIF code that checks for such zend
> > extensions being loaded:
> >
> > That allows for backwards compatibility.
> >
> > Also, that will avoid a mismatch with PFTT... PFTT has scenarios that can
> > load/configure extensions for all tests to be run, fe: run all tests with
> > opcache enabled or run all tests with opcache disabled. SKIPIF code would
> > allow such PHPTs to be skipped or not for those scenarios, otherwise
> there
> > is a mismatch in features between PFTT and run-test.php.
> >
> >
> > Regards
> > -M
> >
> > On Mon, May 9, 2016 at 9:07 PM, Benjamin Eberlei 
> > wrote:
> >
> >> On Tue, May 10, 2016 at 2:51 AM, François Laupretre 
> >> wrote:
> >>
> >> > Hi Derick,
> >> >
> >> >
> >> > Le 09/05/2016 à 20:36, Derick Rethans a écrit :
> >> >
> >> >> Hi!
> >> >>
> >> >> I've recently been having some looks at issues between xdebug and
> >> >> opcache, and this meant that I need to write a test case for it.
> >> >>
> >> >> Ages ago I added support for the "--EXTENSIONS--" section in .phpt
> >> >> files, to load extensions that the test 'depends' on. Each item would
> >> be
> >> >> added to the php invocation as a "-dextension=name.so". For opcache
> >> >> however, that needs to be "-dzend_extension=opcache.so".
> >> >>
> >> >> The attached patch checks for opcache in the list of extensions and
> >> then
> >> >> uses zend_extension=. I'd like to have this in PHP 7.0 and trunk -
> any
> >> >> objections?
> >> >>
> >> >> cheers,
> >> >> Derick
> >> >>
> >> >
> >> > I know there are not so many Zend extensions around, but I would
> >> > definitely prefer a 'ZEND_EXTENSIONS' section.
> >> >
> >>
> >> Wouldn't this work by just using --INI-- instead?
> >>
> >> --INI--
> >> zend_extension=opcache.so
> >>
> >> greetings
> >> Benjamin
> >>
> >>
> >> >
> >> > Regards
> >> >
> >> > François
> >> >
> >> >
> >> >
> >> > --
> >> > PHP Internals - PHP Runtime Development Mailing List
> >> > To unsubscribe, visit: http://www.php.net/unsub.php
> >> >
> >> >
> >>
> >
> >
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye  wrote:
> On May 10, 2016 10:25 AM, "Yasuo Ohgaki"  wrote:
>>
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch for this.
>> https://wiki.php.net/rfc/automatic_csrf_protection
>>
>> Thank you for your comments.
>
> I will try to explain a bit my view on all the current efforts (welcome) to
> secure session managements and related areas.
>
> For the last one, I do not think php should take of it. If we still want to
> do it, I won't do it all using what it is proposed. It should provide APIs,
> easy to use and being used on demand (think of the password APIs for csrf
> protection). INI settings are unflexible, hard to custom or fix later. The
> pléthore of packages (and some very good ones like in slim fe) lead the way.
>
> This RFC also makes many assumptions about erroneous  common cases as many
> other said in this thread.
>
> About all other RFCs to secure or improve sessions. My feeling is simple:
>
> The current session code and designs is old, very old. It does not match
> today ways to do things. Every time we fix it, I see a band aid fix.

I agree partly.
The way session ID is managed is obsolete and insecure. Therefore, I proposed
precise session management.

> In other words, rewrite the damned thing. Make clear, simple APIs, enable
> secure behavior by default and limit the ini options to the very strict
> minimum.

I have different point of view.
Current session manager is like UDP. Users has to do lot of work to
maintain state properly. Session manager should be like TCP. IMO.
Users shouldn't have to care about details how session/state is
maintained.

Thank you for your comments. I've updated the RFC. You might like this version.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Joe Watkins]

Morning Dmitry,

I'm not really happy with the voting options here.

I would not vote in favour of a patch that does not include support for
AST, that's a completely different feature.

As it is, I have to vote yes in favour of AST, but it may be counted as
a vote in favour of attributes without AST ...

This doesn't seem right ... I don't want attributes without AST, and
there is no voting option to reflect that.

Cheers
Joe

On Tue, May 10, 2016 at 11:09 PM, Björn Larsson 
wrote:

> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:
>
>>
>>
>> On 05/11/2016 12:29 AM, Björn Larsson wrote:
>>
>>> Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:
>>>
>>> Hi internals,


 I've started voting on "PHP Attributes" RFC.


 https://wiki.php.net/rfc/attributes


 In my opinion, "PHP Attributes" might be a smart tool for PHP
 extension, but it's not going to be the end of the world, if we decided to
 live with doc-comments only.


 Thanks. Dmitry.

 Thanks for the good work. Regarding naming, I googled
>>> "PHP attributes" vs "PHP annotations" and looking at the
>>> result, my view is that that Annotation is a better naming
>>> then Attributes. Any hope in changing it?
>>>
>>
>> The more I listen to arguments of adepts of existing PHP annotation
>> systems, the more I think, that "PHP attributes" is the right name for this
>> proposal.
>> This feature is not just for PHP annotation systems.
>>
>
> Thats a fair point, so Annotation it's not. Still, when I hear PHP
> attributes I associate it with class / function attributes. Maybe
> just a question getting used to the naming. Hm, wonder if PHP
> directives could have been an option?
>
> Regards //Björn
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Niklas Keller]

Yasuo Ohgaki  schrieb am Mi., 11. Mai 2016 00:05:

> Hi Stas,
>
> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
>  wrote:
> >> What happens with applications that do not produce HTML at all, such as
> REST,
> >>  - These apps may add SESSCSRF value manually.
> >
> > Add where? And where that value would come from? RFC says nothing about
> > that.
>
> As usual. Query parameter when GET is used. Additional input when POST
> is used. All users have to do is adding CSRF token to JS program.
>

Again: GET doesn't need any protection, it must be idempotent.

Query parameter is a very bad idea, just like session IDs in the query
parameter are a bad idea. Maybe we should think about removing support for
it.

Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Kinn,

On Wed, May 11, 2016 at 11:56 AM, Kinn Julião  wrote:
> The point with your example is:
> The cross site can request the "get_csrf_token.php", store on its session
> (even curl can save the session id cookie or whatever), get the token and
> request the endpoint with the retrieved token and session id.
>
> Got it?

Wrong assumption.
How would you set attacker's session ID to victim?

BTW, session hijack/adoption is not scope of this RFC, but precise
session management RFC.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Niklas Keller]

Yasuo Ohgaki  schrieb am Mi., 11. Mai 2016 03:11:

> Hi Stas,
>
> On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev 
> wrote:
> >>> Add where? And where that value would come from? RFC says nothing about
> >>> that.
> >>
> >> As usual. Query parameter when GET is used. Additional input when POST
> >> is used. All users have to do is adding CSRF token to JS program.
> >
> > GET and POST aren't the only HTTP methods. And where JS program would
> > get the correct token from? As far as I can see, there's no function in
> > the RFC that produces it.
>
> PHP doesn't have other method support yet.
>

You can use whatever method you like. It's the browsers that don't support
other methods in forms. And JS needs a preflight request for other methods,
so that shouldn't be an issue.

If users have their implementation PUT/etc, they may validate CSRF
> token manually.
>
> I intended this feature for simple applications that lacks CSRF
> protection at first, but it seems I'm better to change objective. I'll
> change target to semi automatic/manual CSRF protection.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Pierre Joye]

Hi,

On May 10, 2016 10:25 AM, "Yasuo Ohgaki"  wrote:
>
> Hi all,
>
> It's not nice to work on the same code (i.e. session module) for
> multiple RFCs, but time is limited.
>
> I would like to hear from ideas/comments before I write patch for this.
> https://wiki.php.net/rfc/automatic_csrf_protection
>
> Thank you for your comments.

I will try to explain a bit my view on all the current efforts (welcome) to
secure session managements and related areas.

For the last one, I do not think php should take of it. If we still want to
do it, I won't do it all using what it is proposed. It should provide APIs,
easy to use and being used on demand (think of the password APIs for csrf
protection). INI settings are unflexible, hard to custom or fix later. The
pléthore of packages (and some very good ones like in slim fe) lead the
way.

This RFC also makes many assumptions about erroneous  common cases as many
other said in this thread.

About all other RFCs to secure or improve sessions. My feeling is simple:

The current session code and designs is old, very old. It does not match
today ways to do things. Every time we fix it, I see a band aid fix.

In other words, rewrite the damned thing. Make clear, simple APIs, enable
secure behavior by default and limit the ini options to the very strict
minimum.

We all already used custom extensions for management anyway (serialization,
different backends, etc). It may not help shared hosting but these are kind
of hopeless in many regards.

> Regards,
>
> P.S. Precise session ID management is important, but this one is also
> important. I'll finish and start voting 2 active session RFCs soon. I
> may finish all of them hopefully.

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Kinn Julião]

The point with your example is:
The cross site can request the "get_csrf_token.php", store on its session
(even curl can save the session id cookie or whatever), get the token and
request the endpoint with the retrieved token and session id.

Got it?
On May 10, 2016 10:53 PM, "Kinn Julião"  wrote:

> You seemed to misunderstood your own "get_csrf_token.php" and how
> attackers would benefit from that.
>
> Anyway, you're trying to transfer an application behaviour to the core...
> Stick to -1.
> On May 10, 2016 10:18 PM, "Yasuo Ohgaki"  wrote:
>
>> Hi Kinn,
>>
>> On Wed, May 11, 2016 at 10:20 AM, Kinn Julião  wrote:
>> >> JS code that does not have pages at all may obtain CSRF token manually.
>> >
>> > That's against CSRF protection... in fact, a remote app can obtain the
>> token
>> > also and make the cross site request forgery...
>> >
>> > -1
>>
>> You seem to __misunderstood__ behavior.
>>
>> Random CSRF token generation key is stored in session data which is
>> private to users.
>> CSRF token is generated by using the secret key.
>>
>> Therefore, attacker cannot get CSRF token unless they have stolen
>> session already (which is not scope of this RFC)
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Kinn Julião]

You seemed to misunderstood your own "get_csrf_token.php" and how attackers
would benefit from that.

Anyway, you're trying to transfer an application behaviour to the core...
Stick to -1.
On May 10, 2016 10:18 PM, "Yasuo Ohgaki"  wrote:

> Hi Kinn,
>
> On Wed, May 11, 2016 at 10:20 AM, Kinn Julião  wrote:
> >> JS code that does not have pages at all may obtain CSRF token manually.
> >
> > That's against CSRF protection... in fact, a remote app can obtain the
> token
> > also and make the cross site request forgery...
> >
> > -1
>
> You seem to __misunderstood__ behavior.
>
> Random CSRF token generation key is stored in session data which is
> private to users.
> CSRF token is generated by using the secret key.
>
> Therefore, attacker cannot get CSRF token unless they have stolen
> session already (which is not scope of this RFC)
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Kinn,

On Wed, May 11, 2016 at 10:20 AM, Kinn Julião  wrote:
>> JS code that does not have pages at all may obtain CSRF token manually.
>
> That's against CSRF protection... in fact, a remote app can obtain the token
> also and make the cross site request forgery...
>
> -1

You seem to __misunderstood__ behavior.

Random CSRF token generation key is stored in session data which is
private to users.
CSRF token is generated by using the secret key.

Therefore, attacker cannot get CSRF token unless they have stolen
session already (which is not scope of this RFC)

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Kinn Julião]

> JS code that does not have pages at all may obtain CSRF token manually.

That's against CSRF protection... in fact, a remote app can obtain the
token also and make the cross site request forgery...

-1

On Tue, May 10, 2016 at 9:17 PM, Yasuo Ohgaki  wrote:

> Hi Stas,
>
> On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev 
> wrote:
> >>> Add where? And where that value would come from? RFC says nothing about
> >>> that.
> >>
> >> As usual. Query parameter when GET is used. Additional input when POST
> >> is used. All users have to do is adding CSRF token to JS program.
> >
> > GET and POST aren't the only HTTP methods. And where JS program would
> > get the correct token from? As far as I can see, there's no function in
> > the RFC that produces it.
>
> JS code that does not have pages at all may obtain CSRF token manually.
>
> get_csrf_token.php
>  session_start(['csrf_protection'=>SESSION_CSRF_GET]);
> echo json_encode(['SESSCSRF'=>SESSCSRF]);
> ?>
>
> then JS apps may use the token. Users must be careful for CSRF token TTL.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
*--*
*Kinn Coelho Julião*
*Toronto - ON/Canada*

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Stas,

On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev  wrote:
>>> Add where? And where that value would come from? RFC says nothing about
>>> that.
>>
>> As usual. Query parameter when GET is used. Additional input when POST
>> is used. All users have to do is adding CSRF token to JS program.
>
> GET and POST aren't the only HTTP methods. And where JS program would
> get the correct token from? As far as I can see, there's no function in
> the RFC that produces it.

JS code that does not have pages at all may obtain CSRF token manually.

get_csrf_token.php
SESSION_CSRF_GET]);
echo json_encode(['SESSCSRF'=>SESSCSRF]);
?>

then JS apps may use the token. Users must be careful for CSRF token TTL.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Stas,

On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev  wrote:
>>> Add where? And where that value would come from? RFC says nothing about
>>> that.
>>
>> As usual. Query parameter when GET is used. Additional input when POST
>> is used. All users have to do is adding CSRF token to JS program.
>
> GET and POST aren't the only HTTP methods. And where JS program would
> get the correct token from? As far as I can see, there's no function in
> the RFC that produces it.

PHP doesn't have other method support yet.
If users have their implementation PUT/etc, they may validate CSRF
token manually.

I intended this feature for simple applications that lacks CSRF
protection at first, but it seems I'm better to change objective. I'll
change target to semi automatic/manual CSRF protection.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi All,

On Tue, May 10, 2016 at 12:24 PM, Yasuo Ohgaki  wrote:
> It's not nice to work on the same code (i.e. session module) for
> multiple RFCs, but time is limited.
>
> I would like to hear from ideas/comments before I write patch for this.
> https://wiki.php.net/rfc/automatic_csrf_protection
>
> Thank you for your comments.

I've changed RFC target from "automatic" to "semi-automatic". i.e.
Changed title.

It is possible to set up web system that could be protected from CSRF
attack fully, but it requires web server setting/simple php script to
do so. If it requires web system modification anyway, it would be
better make this feature more generic.

Users has to write a setting for pages, but it should be good enough
to secure simple applications.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi,

On Wed, May 11, 2016 at 7:06 AM, Yasuo Ohgaki  wrote:
> On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder  wrote:
>> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
>>> Hi all,
>>>
>>> It's not nice to work on the same code (i.e. session module) for
>>> multiple RFCs, but time is limited.
>>>
>>> I would like to hear from ideas/comments before I write patch for this.
>>> https://wiki.php.net/rfc/automatic_csrf_protection
>>>
>>> Thank you for your comments.
>>>
>>> Regards,
>>>
>>> P.S. Precise session ID management is important, but this one is also
>>> important. I'll finish and start voting 2 active session RFCs soon. I
>>> may finish all of them hopefully.
>>>
>>
>> -1 CSRF protection is a very specific need of some parts of a website
>> and not something that is universally required
>
> Did you read RFC?
> It does not enable CSRF protection for all website, but only when it is 
> enabled.

Oops. I set default to protect. Fixed it. Thanks.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Stanislav Malyshev]

Hi!

> Did you read RFC?
> It does not enable CSRF protection for all website, but only when it is 
> enabled.

The RFC says: "Default: session.csrf_protection=1". Which means all
sites would have it (for POST) unless they specifically disable it by
changing configuration.

Also, new variants do not account for existence of other HTTP methods
such as PUT, DELETE, etc. Value "2" also makes little sense - why would
you want to protect GET, but not POST?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Stanislav Malyshev]

Hi!

>> Add where? And where that value would come from? RFC says nothing about
>> that.
> 
> As usual. Query parameter when GET is used. Additional input when POST
> is used. All users have to do is adding CSRF token to JS program.

GET and POST aren't the only HTTP methods. And where JS program would
get the correct token from? As far as I can see, there's no function in
the RFC that produces it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[François Laupretre]

Hi,


Le 10/05/2016 à 22:07, Lester Caine a écrit :

Windows did not worry about which extension was used
in the past, but nowadays the problem is ensuring the correct build of
extension is accessed and while 32bit is still the safer base, it's all
too easy to get them mixed up with 64bit builds. All of MY recent
windows installs have had to be 32bit so this creates a conflict with
PHP7's assumption that modern target will be 64bit ;) TODAY the windows
php.ini needs to be managed to ensure that the correct paths are used to
the correct build, and personally I'd rather not 'simplify' something
which has a much bigger impact - and adding a build identifier to the
file name may be a better fix than trying to rely on the path to ensure
the correct build is accessed.


Right. We could include a build ID in file names. And adapt the way we 
compute file names from extension names. But I don't see how this 
concern conflicts with the RFC.


Regards

François

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[François Laupretre]

Hi Lester,


Le 10/05/2016 à 21:01, Lester Caine a écrit :

The idea has been proposed before, but the addition of php_ for windows
installs has not been universally applied. Extensions like eAccelerator,
adodb and other third party extensions that did not form part of the
windows 'installation' files. Most of these have been killed off by the
restructuring of the core so it's probably less of a problem now than 5
years ago!


As Fleshgrinder suggested, we can easily search for 'php_.dll' 
and, if not found, then '.dll'. This would occur on Windows only.



Another negative is the fact that most Linux installations do not use
entries in the php.ini file to enable extensions, preferring to manage
them via the package manager. THAT particular practice is something I
already copy back to the windows installs, using individual .ini files
for each extension, and stripping those extensions and settings from the
main php.ini.


Using extension names instead of file names will also be supported in 
individual .ini files, just as in the main php.ini.


Regards

François

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Björn Larsson]

Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov:



On 05/11/2016 12:29 AM, Björn Larsson wrote:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP 
extension, but it's not going to be the end of the world, if we 
decided to live with doc-comments only.



Thanks. Dmitry.


Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?


The more I listen to arguments of adepts of existing PHP annotation 
systems, the more I think, that "PHP attributes" is the right name for 
this proposal.

This feature is not just for PHP annotation systems.


Thats a fair point, so Annotation it's not. Still, when I hear PHP
attributes I associate it with class / function attributes. Maybe
just a question getting used to the naming. Hm, wonder if PHP
directives could have been an option?

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi,

On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder  wrote:
> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch for this.
>> https://wiki.php.net/rfc/automatic_csrf_protection
>>
>> Thank you for your comments.
>>
>> Regards,
>>
>> P.S. Precise session ID management is important, but this one is also
>> important. I'll finish and start voting 2 active session RFCs soon. I
>> may finish all of them hopefully.
>>
>
> -1 CSRF protection is a very specific need of some parts of a website
> and not something that is universally required

Did you read RFC?
It does not enable CSRF protection for all website, but only when it is enabled.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Stas,

On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
 wrote:
>> What happens with applications that do not produce HTML at all, such as REST,
>>  - These apps may add SESSCSRF value manually.
>
> Add where? And where that value would come from? RFC says nothing about
> that.

As usual. Query parameter when GET is used. Additional input when POST
is used. All users have to do is adding CSRF token to JS program.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Rowan,

On Tue, May 10, 2016 at 9:36 PM, Rowan Collins  wrote:
> Yasuo Ohgaki wrote on 10/05/2016 11:57:
>>
>> To protect all of URLs automatically, all URLs need to have token.
>> That's the reason why all URLs have token.
>
>
> In my opinion, that fails on both counts: not all URLs need protection (I
> would say for most applications, the majority of URLs do not need it), and
> not all URLs will be protected automatically (because rewriting HTML is a
> hard problem, and because some submissions that need protecting are not
> generated as HTML).
>
> Interestingly, the OWASP page has a whole section on the dangers of exposing
> CSRF tokens in URLs:
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
> It backs up my gut feeling that exposing the CSRF token too widely can
> severely diminish its usefulness; for instance, by exposing tokens in
> Referer headers sent to external sites.
>
> There may be types of application that would benefit from every page having
> a "CSRF or die" policy - e.g. online banking - but I don't think they
> represent a large proportion of the PHP user space, or benefit significantly
> from having the functionality built into the language. For everyone else,
> all that's needed is functions to manually generate, save, and validate
> tokens, and those can trivially be written as a userland library. Indeed
> there are plenty: https://packagist.org/search/?q=csrf

Exposure of CSRF token is obvious security risk.
As I wrote, the risk is the same as trans sid. In addition, it does not
add CSRF token to URLs by default now. (i.e. Protect POST automatically when
it is enabled)

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 12:29 AM, Björn Larsson wrote:

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP 
extension, but it's not going to be the end of the world, if we 
decided to live with doc-comments only.



Thanks. Dmitry.


Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?


The more I listen to arguments of adepts of existing PHP annotation 
systems, the more I think, that "PHP attributes" is the right name for 
this proposal.

This feature is not just for PHP annotation systems.



Regards //Björn Larsson




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Björn Larsson]

Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
it's not going to be the end of the world, if we decided to live with doc-comments only.


Thanks. Dmitry.


Thanks for the good work. Regarding naming, I googled
"PHP attributes" vs "PHP annotations" and looking at the
result, my view is that that Annotation is a better naming
then Attributes. Any hope in changing it?

Regards //Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/10/2016 11:48 PM, Benjamin Eberlei wrote:



On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov > wrote:


Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP
extension, but it's not going to be the end of the world, if we
decided to live with doc-comments only.


one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key 
value pairs? Key-Value would be much more powerful and address a ton 
of objections for us (Doctrine).
Attributes their selves are key-values, only nested values are numeric, 
but instead of simple values it's possible to use expression AST, that 
is more powerful than key-values.




In the current state it is pretty limited for more complex use-cases. 
I don't want to fully embrace the complexities that Larry showed for 
Drupal (in my opinion, too much annotations), but without key value 
pairs we could only use this when we nested JSON into the attribute 
value strings for example, not something I want to mix.


The Drupal example implementation on top of attributes is included in RFC.




Thanks. Dmitry.

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Benjamin Eberlei]

On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  wrote:

> Hi internals,
>
>
> I've started voting on "PHP Attributes" RFC.
>
>
> https://wiki.php.net/rfc/attributes
>
>
> In my opinion, "PHP Attributes" might be a smart tool for PHP extension,
> but it's not going to be the end of the world, if we decided to live with
> doc-comments only.
>

one question, Rasmus Schultz post goes into the similar direction.

Any reason why the annotations are only a numeric list and not key value
pairs? Key-Value would be much more powerful and address a ton of
objections for us (Doctrine).

In the current state it is pretty limited for more complex use-cases. I
don't want to fully embrace the complexities that Larry showed for Drupal
(in my opinion, too much annotations), but without key value pairs we could
only use this when we nested JSON into the attribute value strings for
example, not something I want to mix.

>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

[Levi Morrison]

On Tue, May 10, 2016 at 1:13 PM, Lester Caine  wrote:
> On 10/05/16 17:27, Levi Morrison wrote:
>> Voting will close on Friday, May 20th, 2016 sometime in the evening of UTC-6.
>
> Quick question ... if I simply strip this extra '?' if some library has
> added it will it actually make any difference to the results?
> I still think the whole concept of 'null' needs much better
> documentation in relation to how it fits in generally.
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

It can affect the results.

function foo(?Foo $param) {}

If any code out there is calling foo with null then that code will now
break if you remove the question mark.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Lester Caine]

On 10/05/16 20:18, Fleshgrinder wrote:
> WIN: `php -d extension=php_foo.dll -d zend_extension=php_bar.dll`

I would be most surprised to find windows users running php command
line, but I suppose I am somewhat out of the loop on that side. All my
windows users run PHP on a web server and have trouble even accessing
the command line.

I don't think .so extension is still being used on windows installs.
THAT was another 'fix' used to make installation of third party
extensions easier. Windows did not worry about which extension was used
in the past, but nowadays the problem is ensuring the correct build of
extension is accessed and while 32bit is still the safer base, it's all
too easy to get them mixed up with 64bit builds. All of MY recent
windows installs have had to be 32bit so this creates a conflict with
PHP7's assumption that modern target will be 64bit ;) TODAY the windows
php.ini needs to be managed to ensure that the correct paths are used to
the correct build, and personally I'd rather not 'simplify' something
which has a much bigger impact - and adding a build identifier to the
file name may be a better fix than trying to rely on the path to ensure
the correct build is accessed.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Rasmus Schultz]

A couple of quick comments - I'm sorry, I haven't had time to get them
in before now.

In my opinion, this is pretty bad, for one primary reason: these are
just names and values.

The advantage of this over parsing doc-blocks at run-time is pretty
limited - you can basically only guarantee syntax, you can't guarantee
anything about annotation types or the required arguments. Names and
values still need to be resolved at run-time - that seems really
brittle and redundant.

It's also not what the community wants - they want classes, e.g.
Doctrine annotations, the most popular choice:

https://github.com/doctrine/annotations

Or the project that I started (but no longer contribute to)

https://github.com/php-annotations/php-annotations/

We want classes for the same reason we don't want arrays with magical
key/value pairs - for example, so we can have static analysis,
inspections, auto-completion in IDEs, etc.

Annotations need more consideration for design time - run time
attributes, in my opinion, is not enough, and brings more net
complexity than actual annotations.

Because no behavior or coupling is defined, they won't behave well,
and the coupling will be unpredictable - we'll have lots of
frameworks, all doing things differently, which is the same situation
we have now.

In my opinion, if we need this functionality at all, we need real
annotations - not just new syntax for the data, but taking into
account the behavior.

I think annotations could be as simple as this:

https://gist.github.com/mindplay-dk/ebd5e4f7da51da3c4e56232adef41b46

In my opinion, this immediately solves a lot more problems with a lot
less effort (and fragmentation!) in userland.

It's immediately useful in any script, without having to select and
install a third-party Composer package or write complex code to
interpret the data.

As for "softer" and more complex rules, e.g. regarding the number of
allowed annotations of the same type, or the type of element they're
allowed on, etc. - it doesn't make much sense to try to implement or
enforce such rules, as these wouldn't be enforced until the moment you
actually query the annotations of an element anyhow. This could be
either left up to userland, e.g. consumers can easily check and
enforce constraints themselves using conditionals and exceptions.

As for single vs multiple annotations of the same type, I would ignore
this as well, for the same reason - even if you had an API like
getSingleAnnotation($type) this would have to return either an
instance of $type, or null, so the consumer is still left with the
burden of having to check the result, e.g. no more or less of a burden
than checking the number of returned annotations with count().

To summarize:

- Annotations are immediately useful in any script
- Annotations are coupled directly to classes
- Classes is what most of us want in the end
- Static type-checking is possible

I think that attributes are not the way to go about this - it's not
substantially better than the status quo and doesn't lead to anything
immediately useful to most developers without also
adopting/writing/learning a suitable framework.

Just my opinions.


On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov  wrote:
> Hi internals,
>
>
> I've started voting on "PHP Attributes" RFC.
>
>
> https://wiki.php.net/rfc/attributes
>
>
> In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
> it's not going to be the end of the world, if we decided to live with 
> doc-comments only.
>
>
> Thanks. Dmitry.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Fleshgrinder]

On 5/10/2016 9:01 PM, Lester Caine wrote:
> The idea has been proposed before, but the addition of php_ for windows
> installs has not been universally applied. Extensions like eAccelerator,
> adodb and other third party extensions that did not form part of the
> windows 'installation' files. Most of these have been killed off by the
> restructuring of the core so it's probably less of a problem now than 5
> years ago!
> 
> Another negative is the fact that most Linux installations do not use
> entries in the php.ini file to enable extensions, preferring to manage
> them via the package manager. THAT particular practice is something I
> already copy back to the windows installs, using individual .ini files
> for each extension, and stripping those extensions and settings from the
> main php.ini.
> 
> This is not simply a matter of adding another load mechanism to the mix,
> so any rfc should perhaps bear in mind all the aspects of 'package
> management' process? Certainly it's not quite as simple as assuming
> windows extensions start php_ and end .dll ...
> 

Handling of the prefix is a no brainer. Just check for php_NAME.dll and
fallback to NAME.dll on Windows otherwise. If both fail error out.

The approach to split ini files does not work on CLI.

UNIX: `php -d extension=foo.so -d zend_extension=bar.so`

WIN: `php -d extension=php_foo.dll -d zend_extension=php_bar.dll`

RFC: `php -d extension=foo -d zend_extension=bar`

Are there really extension on Windows without `.dll` extension? I highly
doubt it and would consider erroring out to be okay. Users can still
specify the exact path if the want to.

  function load_extension($name) {
$extension_dir = ini_get('extension_dir');
$extension_dir = rtrim($extension_dir, DIRECTORY_SEPARATOR);
$extension_dir .= DIRECTORY_SEPARATOR;

if (DIRECTORY_SEPARATOR === '\\') {
  foreach (['php_', ''] as $prefix) {
$path = $extension_dir . $prefix . $name . '.dll';
if (is_file($path)) {
  return do_load_extension($path);
}
}
else {
  $path = $extension_dir . $name . '.so';
  if (is_file($path)) {
return do_load_extension($path);
  }
}

return do_load_extension($name);
  }

Something along these lines should do it (of course in C). :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC][VOTE] Nullable Types

[Lester Caine]

On 10/05/16 17:27, Levi Morrison wrote:
> Voting will close on Friday, May 20th, 2016 sometime in the evening of UTC-6.

Quick question ... if I simply strip this extra '?' if some library has
added it will it actually make any difference to the results?
I still think the whole concept of 'null' needs much better
documentation in relation to how it fits in generally.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Lester Caine]

On 10/05/16 17:27, Fleshgrinder wrote:
>> Please read and comment :
>> > 
>> > https://wiki.php.net/rfc/load-ext-by-name
>> > 
> +1 and I am wondering why nobody else ever came to this idea.

The idea has been proposed before, but the addition of php_ for windows
installs has not been universally applied. Extensions like eAccelerator,
adodb and other third party extensions that did not form part of the
windows 'installation' files. Most of these have been killed off by the
restructuring of the core so it's probably less of a problem now than 5
years ago!

Another negative is the fact that most Linux installations do not use
entries in the php.ini file to enable extensions, preferring to manage
them via the package manager. THAT particular practice is something I
already copy back to the windows installs, using individual .ini files
for each extension, and stripping those extensions and settings from the
main php.ini.

This is not simply a matter of adding another load mechanism to the mix,
so any rfc should perhaps bear in mind all the aspects of 'package
management' process? Certainly it's not quite as simple as assuming
windows extensions start php_ and end .dll ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes

[Fleshgrinder]

On 5/10/2016 8:29 PM, Dmitry Stogov wrote:
> Hi internals,
> 
> I've started voting on "PHP Attributes" RFC.
> 
> https://wiki.php.net/rfc/attributes
> 
> In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
> it's not going to be the end of the world, if we decided to live with 
> doc-comments only.
> 

I hope it's going to be negative. The name is misleading and the AST
approach is not really useful in userland. :(

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [RFC] [VOTE] PHP Attributes

[Dmitry Stogov]

Hi internals,


I've started voting on "PHP Attributes" RFC.


https://wiki.php.net/rfc/attributes


In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but 
it's not going to be the end of the world, if we decided to live with 
doc-comments only.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Rowan Collins]

On 10/05/2016 17:54, Stanislav Malyshev wrote:

Hi!


Please read and comment :

https://wiki.php.net/rfc/load-ext-by-name


The RFC says " it is currently impossible to write a single
configuration file that will work in both environments" - but even with
extension fix, wouldn't it be still impossible since Windows are Unix
paths would probably be different?




The RFC already disclaims that:


This RFC does not pretend solving every difference that may exist
between Windows and Unix configurations. Where paths are set,

> the differences will remain.


It also explains how this makes it easier for some people, and some 
tools, and is therefore worth doing.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[François Laupretre]

Hi,

Le 10/05/2016 à 18:54, Stanislav Malyshev a écrit :

The RFC says " it is currently impossible to write a single
configuration file that will work in both environments" - but even with
extension fix, wouldn't it be still impossible since Windows are Unix
paths would probably be different?


Yes, of course. As written in the 'Open Issues' section, the fix does 
not pretend solving every incompatibilities between windows and Unix 
configurations. I just say, that, in several cases, I had to duplicate 
configuration files where the only differences were extension file names 
(mostly when configuration didn't override default paths).


Regards

François


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Chris Riley]

On 10 May 2016 at 17:48, Fleshgrinder  wrote:

> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > It's not nice to work on the same code (i.e. session module) for
> > multiple RFCs, but time is limited.
> >
> > I would like to hear from ideas/comments before I write patch for this.
> > https://wiki.php.net/rfc/automatic_csrf_protection
> >
> > Thank you for your comments.
> >
> > Regards,
> >
> > P.S. Precise session ID management is important, but this one is also
> > important. I'll finish and start voting 2 active session RFCs soon. I
> > may finish all of them hopefully.
> >
>
> -1 CSRF protection is a very specific need of some parts of a website
> and not something that is universally required.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
Sorry but this isn't something that the language should be concerning
itself with. It will cause more pain than it's worth (think magic quotes).

Also, you suggest that PHP should raise an error on session_start if the
validation fails, most of the time if my app gets a csrf failure an error
would be inappropriate as I'd want to handle it myself and display for
example a form validation error message instead of blowing up the whole
script.

Given that this feature is optional it will do nothing to improve security
whilst adding pain to developers who are producing apps designed to run in
multiple environments eg drupal/wordpress etc so a big -1 from me.

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Fleshgrinder]

On 5/10/2016 6:56 PM, Fleshgrinder wrote:
> On 5/10/2016 6:54 PM, Stanislav Malyshev wrote:
>> Hi!
>>
 Please read and comment :

 https://wiki.php.net/rfc/load-ext-by-name
>>
>> The RFC says " it is currently impossible to write a single
>> configuration file that will work in both environments" - but even with
>> extension fix, wouldn't it be still impossible since Windows are Unix
>> paths would probably be different?
>>
> 
> Usage of slashes and relative paths works perfectly fine in Windows; or
> do you mean something different?
> 

Just checked it with a simple script on Windows 7 with PHP 7.0.6.
Slashes are no problem but relative paths seem problematic, hence, there
would be the problem regarding `C:/some/path` vs. `/some/path`.

This RFC would still be a big step ahead because we could do something
like the following:

  php -v

PHP 7.0.6 (cli) (built: Apr 28 2016 13:48:13) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

  php -d zend_extension=xdebug -v

PHP 7.0.6 (cli) (built: Apr 28 2016 13:48:13) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

  php composer install
  php -d zend_extension=xdebug test

This is currently not possible.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Fleshgrinder]

On 5/10/2016 6:54 PM, Stanislav Malyshev wrote:
> Hi!
> 
>>> Please read and comment :
>>>
>>> https://wiki.php.net/rfc/load-ext-by-name
> 
> The RFC says " it is currently impossible to write a single
> configuration file that will work in both environments" - but even with
> extension fix, wouldn't it be still impossible since Windows are Unix
> paths would probably be different?
> 

Usage of slashes and relative paths works perfectly fine in Windows; or
do you mean something different?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Stanislav Malyshev]

Hi!

>> Please read and comment :
>>
>> https://wiki.php.net/rfc/load-ext-by-name

The RFC says " it is currently impossible to write a single
configuration file that will work in both environments" - but even with
extension fix, wouldn't it be still impossible since Windows are Unix
paths would probably be different?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Fleshgrinder]

On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
> Hi all,
> 
> It's not nice to work on the same code (i.e. session module) for
> multiple RFCs, but time is limited.
> 
> I would like to hear from ideas/comments before I write patch for this.
> https://wiki.php.net/rfc/automatic_csrf_protection
> 
> Thank you for your comments.
> 
> Regards,
> 
> P.S. Precise session ID management is important, but this one is also
> important. I'll finish and start voting 2 active session RFCs soon. I
> may finish all of them hopefully.
> 

-1 CSRF protection is a very specific need of some parts of a website
and not something that is universally required.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [RFC][VOTE] Nullable Types

[Levi Morrison]

On Tue, May 10, 2016 at 9:22 AM, Levi Morrison  wrote:
> Dmitry and I have opened [voting on Nullable Types][1]. Note that I
> have changed the phrasing of the two votes but the structure and
> outcomes are the same. Hopefully these changes help clarify the
> possible results.
>
> I thank everyone who has contributed to the implementation or
> discussion for their participation.
>
>   [1]: https://wiki.php.net/rfc/nullable_types#voting_choices

Voting will close on Friday, May 20th, 2016 sometime in the evening of UTC-6.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow loading extensions by name

[Fleshgrinder]

On 5/10/2016 3:22 PM, François Laupretre wrote:
> Please read and comment :
> 
> https://wiki.php.net/rfc/load-ext-by-name
> 

+1 and I am wondering why nobody else ever came to this idea.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Stanislav Malyshev]

Hi!

> What happens with applications that do not produce HTML at all, such as REST,
>  - These apps may add SESSCSRF value manually.

Add where? And where that value would come from? RFC says nothing about
that.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Stanislav Malyshev]

Hi!

> To protect all of URLs automatically, all URLs need to have token.
> That's the reason why all URLs have token. The risk is the same as
> Trans SID session management.

But not all URLs need protecting. There are a lot of URLs that do not
need protecting - and there are a lot of actions, especially in modern
web application, that aren't achieved by simply clicking the link in the
browser. Modern web application is usually a combination of backend and
frontend logic, and if you have any frontend logic driven by XHR or
such, URL rewriting is not going to work.

> Because of  likelihood of the vulnerability, it's better provide basic
> infrastructure. IMO. It's possible to give more control to users.

The problem is the RFC proposes to give less control to users - namely,
the defaults proposed are likely to break an average application *and*
not provide CSRF protection for it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] Nullable Types

[Levi Morrison]

Dmitry and I have opened [voting on Nullable Types][1]. Note that I
have changed the phrasing of the two votes but the structure and
outcomes are the same. Hopefully these changes help clarify the
possible results.

I thank everyone who has contributed to the implementation or
discussion for their participation.

  [1]: https://wiki.php.net/rfc/nullable_types#voting_choices

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-05-10

[lp_benchmark_robot]

Results for project PHP master, build date 2016-05-10 06:29:58+03:00
commit: f9bead7
previous commit:7b65346
revision date:  2016-05-09 18:52:21+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.24% -0.13%  0.70%  
  7.25%
:-|   Drupal 7.36 cgi -T1  0.23%  0.17% -0.12%  
  4.28%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11% -0.13%  0.67%  
  3.32%
:-|   bench.php cgi -T100  0.14% -0.20% 26.68%  
 -0.42%
:-(  micro_bench.php cgi -T10  0.10% -1.04%  3.94%  
  3.42%
:-|  mandelbrot.php cgi -T100  0.04% -0.44% 29.66%  
  6.69%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-05-10/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Allow loading extensions by name

[François Laupretre]

Please read and comment :

https://wiki.php.net/rfc/load-ext-by-name

Regards

François


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Rowan Collins]

Yasuo Ohgaki wrote on 10/05/2016 11:57:

To protect all of URLs automatically, all URLs need to have token.
That's the reason why all URLs have token.


In my opinion, that fails on both counts: not all URLs need protection 
(I would say for most applications, the majority of URLs do not need 
it), and not all URLs will be protected automatically (because rewriting 
HTML is a hard problem, and because some submissions that need 
protecting are not generated as HTML).


Interestingly, the OWASP page has a whole section on the dangers of 
exposing CSRF tokens in URLs: 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL 
It backs up my gut feeling that exposing the CSRF token too widely can 
severely diminish its usefulness; for instance, by exposing tokens in 
Referer headers sent to external sites.


There may be types of application that would benefit from every page 
having a "CSRF or die" policy - e.g. online banking - but I don't think 
they represent a large proportion of the PHP user space, or benefit 
significantly from having the functionality built into the language. For 
everyone else, all that's needed is functions to manually generate, 
save, and validate tokens, and those can trivially be written as a 
userland library. Indeed there are plenty: 
https://packagist.org/search/?q=csrf


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Albert Casademont]

Why use sessions for CSRF Protection? That an be implemented with simple
cookies.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies

Btw, not sure if this should be in php core though...it's more an
application thing...

On Tue, May 10, 2016 at 2:44 PM, Niklas Keller  wrote:

> Yasuo Ohgaki  schrieb am Di., 10. Mai 2016 12:57:
>
> > Hi Rowan,
> >
> > On Tue, May 10, 2016 at 6:38 PM, Rowan Collins 
> > wrote:
> > > Yasuo Ohgaki wrote on 10/05/2016 04:24:
> > >>
> > >> Hi all,
> > >>
> > >> It's not nice to work on the same code (i.e. session module) for
> > >> multiple RFCs, but time is limited.
> > >>
> > >> I would like to hear from ideas/comments before I write patch for
> this.
> > >> https://wiki.php.net/rfc/automatic_csrf_protection
> > >
> > >
> > > I think rewriting every URL, and erroring if the token on a URL has
> > expired,
> > > will not be useful for most people. What happens if I copy the URL of a
> > page
> > > into an e-mail or Twitter post? As soon as anybody clicks that link,
> > they're
> > > going to get an error raised; maybe it will recover by clearing their
> > > session, causing them to log out unnecessarily; maybe it will refuse to
> > show
> > > the content claiming they're not authenticated. In the worst case,
> > someone
> > > might take my URL and use the CSRF token against me - they have a time
> > > limit, but if the application author relied on this protection, the
> same
> > > token will be valid for any action on the site.
> >
> > To protect all of URLs automatically, all URLs need to have token.
> > That's the reason why all URLs have token. The risk is the same as
> > Trans SID session management.
> >
> > > As described, the feature seems to assume that all pages are potential
> > CSRF
> > > targets, when even an authenticated user on a forum spends most of
> their
> > > time on URLs which retrieve data and have no side effects. As Stas
> > pointed
> > > out, not all content is amenable to rewriting, either, which could lead
> > to a
> > > false sense of security - dare I compare the infamous magic quotes? A
> > good
> > > implementation of CSRF protection has to consider when to generate a
> > token,
> > > when to check it, and what to do on failure - trying to submit a
> comment
> > > with an invalid CSRF token might re-display the comment form with
> > pre-filled
> > > content, for instance - and this proposal doesn't seem to address that.
> > >
> > > I think this is the kind of feature that can only really be addressed
> by
> > an
> > > application framework, which can have greater knowledge of when actions
> > are
> > > being triggered, link tokens to specific actions, and so on.
> >
> > Because of  likelihood of the vulnerability, it's better provide basic
> > infrastructure. IMO. It's possible to give more control to users.
> >
> >  - Specify protected method GET/POST or both.
> >
>
> GET should never require automatic CSRF protection. If you need this,
> you're doing something fundamentally wrong.
>
> The only exception are things like OAuth, but these have to be handled
> manually anyway.
>
>  - Add session_csrf_validate() for manual validation
> >
> > Implementation is simple enough even with these addition. (Added to RFC)
> >
> > I considered to protect whole application while I was writing this RFC
> > draft. Thank you for point this out!
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Niklas Keller]

Yasuo Ohgaki  schrieb am Di., 10. Mai 2016 12:57:

> Hi Rowan,
>
> On Tue, May 10, 2016 at 6:38 PM, Rowan Collins 
> wrote:
> > Yasuo Ohgaki wrote on 10/05/2016 04:24:
> >>
> >> Hi all,
> >>
> >> It's not nice to work on the same code (i.e. session module) for
> >> multiple RFCs, but time is limited.
> >>
> >> I would like to hear from ideas/comments before I write patch for this.
> >> https://wiki.php.net/rfc/automatic_csrf_protection
> >
> >
> > I think rewriting every URL, and erroring if the token on a URL has
> expired,
> > will not be useful for most people. What happens if I copy the URL of a
> page
> > into an e-mail or Twitter post? As soon as anybody clicks that link,
> they're
> > going to get an error raised; maybe it will recover by clearing their
> > session, causing them to log out unnecessarily; maybe it will refuse to
> show
> > the content claiming they're not authenticated. In the worst case,
> someone
> > might take my URL and use the CSRF token against me - they have a time
> > limit, but if the application author relied on this protection, the same
> > token will be valid for any action on the site.
>
> To protect all of URLs automatically, all URLs need to have token.
> That's the reason why all URLs have token. The risk is the same as
> Trans SID session management.
>
> > As described, the feature seems to assume that all pages are potential
> CSRF
> > targets, when even an authenticated user on a forum spends most of their
> > time on URLs which retrieve data and have no side effects. As Stas
> pointed
> > out, not all content is amenable to rewriting, either, which could lead
> to a
> > false sense of security - dare I compare the infamous magic quotes? A
> good
> > implementation of CSRF protection has to consider when to generate a
> token,
> > when to check it, and what to do on failure - trying to submit a comment
> > with an invalid CSRF token might re-display the comment form with
> pre-filled
> > content, for instance - and this proposal doesn't seem to address that.
> >
> > I think this is the kind of feature that can only really be addressed by
> an
> > application framework, which can have greater knowledge of when actions
> are
> > being triggered, link tokens to specific actions, and so on.
>
> Because of  likelihood of the vulnerability, it's better provide basic
> infrastructure. IMO. It's possible to give more control to users.
>
>  - Specify protected method GET/POST or both.
>

GET should never require automatic CSRF protection. If you need this,
you're doing something fundamentally wrong.

The only exception are things like OAuth, but these have to be handled
manually anyway.

 - Add session_csrf_validate() for manual validation
>
> Implementation is simple enough even with these addition. (Added to RFC)
>
> I considered to protect whole application while I was writing this RFC
> draft. Thank you for point this out!
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Stas,

On Tue, May 10, 2016 at 1:44 PM, Stanislav Malyshev  wrote:
>> I would like to hear from ideas/comments before I write patch for this.
>> https://wiki.php.net/rfc/automatic_csrf_protection
>
> Could you explain a bit more - when token validation happens? Where the
> SESSCSRF comes from? Does this mean that every session application now
> has to support URL rewrite? What happens with applications that do not
> produce HTML at all, such as REST, or those that produce data further
> modified by Javascript frontend?

when token validation happens?
 - As soon as session_start() is executed.

Where the SESSCSRF comes from?
 - Session module generates random CSRF generation key from
php_ranbom_bytes(). It generate SESSCSRF SHA1 hash value by using the
key and ttl value.

Does this mean that every session application now has to support URL rewrite?
 - No. URL rewriter is used transparently from applications.

What happens with applications that do not produce HTML at all, such as REST,
 - These apps may add SESSCSRF value manually.

or those that produce data further modified by Javascript frontend?
 - JS code may add SESSCSRF value manually.

Thank you for clarification!

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Yasuo Ohgaki]

Hi Rowan,

On Tue, May 10, 2016 at 6:38 PM, Rowan Collins  wrote:
> Yasuo Ohgaki wrote on 10/05/2016 04:24:
>>
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch for this.
>> https://wiki.php.net/rfc/automatic_csrf_protection
>
>
> I think rewriting every URL, and erroring if the token on a URL has expired,
> will not be useful for most people. What happens if I copy the URL of a page
> into an e-mail or Twitter post? As soon as anybody clicks that link, they're
> going to get an error raised; maybe it will recover by clearing their
> session, causing them to log out unnecessarily; maybe it will refuse to show
> the content claiming they're not authenticated. In the worst case, someone
> might take my URL and use the CSRF token against me - they have a time
> limit, but if the application author relied on this protection, the same
> token will be valid for any action on the site.

To protect all of URLs automatically, all URLs need to have token.
That's the reason why all URLs have token. The risk is the same as
Trans SID session management.

> As described, the feature seems to assume that all pages are potential CSRF
> targets, when even an authenticated user on a forum spends most of their
> time on URLs which retrieve data and have no side effects. As Stas pointed
> out, not all content is amenable to rewriting, either, which could lead to a
> false sense of security - dare I compare the infamous magic quotes? A good
> implementation of CSRF protection has to consider when to generate a token,
> when to check it, and what to do on failure - trying to submit a comment
> with an invalid CSRF token might re-display the comment form with pre-filled
> content, for instance - and this proposal doesn't seem to address that.
>
> I think this is the kind of feature that can only really be addressed by an
> application framework, which can have greater knowledge of when actions are
> being triggered, link tokens to specific actions, and so on.

Because of  likelihood of the vulnerability, it's better provide basic
infrastructure. IMO. It's possible to give more control to users.

 - Specify protected method GET/POST or both.
 - Add session_csrf_validate() for manual validation

Implementation is simple enough even with these addition. (Added to RFC)

I considered to protect whole application while I was writing this RFC
draft. Thank you for point this out!

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Rowan Collins]

Yasuo Ohgaki wrote on 10/05/2016 04:24:

Hi all,

It's not nice to work on the same code (i.e. session module) for
multiple RFCs, but time is limited.

I would like to hear from ideas/comments before I write patch for this.
https://wiki.php.net/rfc/automatic_csrf_protection


I think rewriting every URL, and erroring if the token on a URL has 
expired, will not be useful for most people. What happens if I copy the 
URL of a page into an e-mail or Twitter post? As soon as anybody clicks 
that link, they're going to get an error raised; maybe it will recover 
by clearing their session, causing them to log out unnecessarily; maybe 
it will refuse to show the content claiming they're not authenticated. 
In the worst case, someone might take my URL and use the CSRF token 
against me - they have a time limit, but if the application author 
relied on this protection, the same token will be valid for any action 
on the site.


As described, the feature seems to assume that all pages are potential 
CSRF targets, when even an authenticated user on a forum spends most of 
their time on URLs which retrieve data and have no side effects. As Stas 
pointed out, not all content is amenable to rewriting, either, which 
could lead to a false sense of security - dare I compare the infamous 
magic quotes? A good implementation of CSRF protection has to consider 
when to generate a token, when to check it, and what to do on failure - 
trying to submit a comment with an invalid CSRF token might re-display 
the comment form with pre-filled content, for instance - and this 
proposal doesn't seem to address that.


I think this is the kind of feature that can only really be addressed by 
an application framework, which can have greater knowledge of when 
actions are being triggered, link tokens to specific actions, and so on.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] run-tests.php improvement for PHP 7.0+

[Benjamin Eberlei]

On Tue, May 10, 2016 at 6:36 AM, Matt Ficken 
wrote:

> An INI section wouldn't have the extension directory path AND wouldn't
> have the name of the SO to load. On Windows, its
> zend_extension=php_opcache.DLL. Typically the same opcache, etc...
> feature/test should work across os platforms.
>

ah yes of course, sorry for the noise :)

>
> OpCache tests can just use a SKIPIF section to be skipped unless the user
> has configured OpCache to be loaded. Forcing OpCache to be loaded makes
> sure that test gets run during a casual test run (somebody just running
> `make test`). That's what a ZEND_EXTENSION section would do. There are
> several new section types already.
>
> If you really want to add a ZEND_EXTENSIONS section, that's fine.
>
> It is important though to have SKIPIF code that checks for such zend
> extensions being loaded:
>
> That allows for backwards compatibility.
>
> Also, that will avoid a mismatch with PFTT... PFTT has scenarios that can
> load/configure extensions for all tests to be run, fe: run all tests with
> opcache enabled or run all tests with opcache disabled. SKIPIF code would
> allow such PHPTs to be skipped or not for those scenarios, otherwise there
> is a mismatch in features between PFTT and run-test.php.
>
>
> Regards
> -M
>
> On Mon, May 9, 2016 at 9:07 PM, Benjamin Eberlei 
> wrote:
>
>> On Tue, May 10, 2016 at 2:51 AM, François Laupretre 
>> wrote:
>>
>> > Hi Derick,
>> >
>> >
>> > Le 09/05/2016 à 20:36, Derick Rethans a écrit :
>> >
>> >> Hi!
>> >>
>> >> I've recently been having some looks at issues between xdebug and
>> >> opcache, and this meant that I need to write a test case for it.
>> >>
>> >> Ages ago I added support for the "--EXTENSIONS--" section in .phpt
>> >> files, to load extensions that the test 'depends' on. Each item would
>> be
>> >> added to the php invocation as a "-dextension=name.so". For opcache
>> >> however, that needs to be "-dzend_extension=opcache.so".
>> >>
>> >> The attached patch checks for opcache in the list of extensions and
>> then
>> >> uses zend_extension=. I'd like to have this in PHP 7.0 and trunk - any
>> >> objections?
>> >>
>> >> cheers,
>> >> Derick
>> >>
>> >
>> > I know there are not so many Zend extensions around, but I would
>> > definitely prefer a 'ZEND_EXTENSIONS' section.
>> >
>>
>> Wouldn't this work by just using --INI-- instead?
>>
>> --INI--
>> zend_extension=opcache.so
>>
>> greetings
>> Benjamin
>>
>>
>> >
>> > Regards
>> >
>> > François
>> >
>> >
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
>