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

[Yasuo Ohgaki]

Hi Pierre,

On Thu, May 12, 2016 at 10:53 AM, Pierre Joye  wrote:
> My answer is clearly no. We must rather simplified improved the
> session implementations and APIs, focusing purely on its core
> purposes, managing session data storage and provides interfaces
> to match application needs. We do not do that very well anymore.

We did not do very well for a long time, indeed.

Session manager must not accept uninitialized session ID. It's obvious
mandatory requirement for decent session manager, but it took me many
years to add it and it's not enabled by default yet. I think a decade
has passed since strict session was proposed.

Another mandatory feature that time stamp based session data
management is taking years and I'm not sure if I can add this for PHP
7.1.

Even simple mandatory API for house keeping task like session_gc() is
taking many years to be implemented.

It could be an option that abandon session module and let users to
implement decent session manager because we are taking too long time
even for mandatory things even if there are implementations. It is
simply taking too long time to fix them. I'm half joking, but half
serious :)

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] Allow loading extensions by name

[Pierre Joye]

On Thu, May 12, 2016 at 2:34 AM, Fleshgrinder  wrote:
> On 5/10/2016 10:07 PM, Lester Caine wrote:
>> 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 am using Windows and the CLI all day professionally. Yes, people tend
> to think like that but it is ancient thinking. Windows is a very capable
> operating system and allows you to perform all tasks. Although I have to
> admit that PHP tends to be very slow on Windows compared to Linux, that
> is a fact.

Off topic but you are wrong here. As a matter of fact. Check real life
benchmarks and raw benchmarks.


-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
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 Thu, May 12, 2016 at 4:13 AM, Yasuo Ohgaki  wrote:
> Hi Arvids,

> I don't force, but CSRF protection is optional. If you don't need it,
> don't use simply.

You actually do by using ini settings for that, or potentially force it.

Now the main issue is not about whether or not csrf is a good thing,
we all agree on that. In my opinion the questions are:

1. do we want csrf features in core?

I do not think it should. But if we decide it should then the way it
is proposed is sub optimal. CSRF usage depends strongly on the
application or request type, TTL and other behaviors as well. That
being said, that means the use of INI settings and global SESSION
array is wrong. It must be a public API.

2. if yes, does it have to be part of the session extension?

My answer is clearly no. We must rather simplified improved the
session implementations and APIs, focusing purely on its core
purposes, managing session data storage and provides interfaces
to match application needs. We do not do that very well anymore.

I will leave this thread for now as I will going to repeat myself more
than you wish, I think we made our points clear :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
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 Andrey,

On Thu, May 12, 2016 at 7:24 AM, Andrey Andreev  wrote:
> On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki  wrote:
>>
>> Hi Andrey,
>>
>> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev  wrote:
>> >
>> > It assumes, and thus also encourages, that users have an active session
>> > at
>> > all times - this is bad. You're not supposed to start a session for a
>> > user
>> > *until they have logged-in*.
>>
>> You don't have to use it if don't need it or has other complement such
>> as double submit cookie.
>>
>
> I am not concerned about using it myself.
>
> I am against it because it is (among other things) ineffective and
> encourages a bad practice, which I've explained below ... v
>
>>
>> > If you do, then unless you're not storing session data server-side
>> > (which
>> > is hard to do properly and is not supported by ext/session), you're
>> > almost
>> > certainly vulnerable to some form of DoS (e.g. inodes and/or
>> > memory/storage
>> > being filled-up), exhaustion of free IDs, entropy available for new
>> > session
>> > ID generation, pre-fetching of IDs to work around use_strict_mode
>> > restrictions, etc.
>>
>
> ^ ... and you misunderstood it:
>
>>
>> None of these arguments make sense...
>> It does not consume much resources. Moreover, this RFC's CSRF
>> protection requires less resources than most web frameworks'
>> implementation that use session for CSRF protections.
>>
>
> Nowhere have I said that your CSRF implementation uses a lot of resources
> (although it does use more server-side resources than the "double submit
> cookie" method, simply because it stores the token on the server).
>
> I am talking about the implications of calling session_start() for
> unauthenticated users.
> Calling session_start() "blindly", before login is what opens the door for
> the vulnerabilities that I've listed. Not because of heavy resource usage,
> but because it allows an attacker to use-up as many single sessions as they
> wish, until that results in some form of DoS.

User can call session_start() always regardless of this RFC. Needless
session_start() could be a performance issue, but it does not relate
to this RFC.

How many of us thought "I have to call session_start() everywhere for
this CSRF protection!"? I guess those who would like to use this CSRF
protection will just enable POST protection and would not add any
additional session_start(), would you?

Even if this RFC encourages enabling session everywhere, it's not a
strong reason that overwhelms  reduced risk of CSRF vulnerability.

>>
>> >
>> > Therefore, while the session store *after login* is suitable for token
>> > storage, CSRF protection by default just doesn't belong in ext/session.
>>
>> Session task, by its definition, is to distinguish and manage state of
>> requests. Session must distinguish requests, i.e. must keep
>> authenticity. CSRF is obvious authenticity issue. Some of us see
>> session manager as just a storage, but it's not a correct definition.
>
>
> No, CSRF is an authorization issue. Authorization (authority) depends on
> authenticity, but is not the same thing.

Authenticity, authentication, authorization are different terms.

Authenticity is "property that an entity is what it is claims to be"
ISO 27000:2014 2.8 i.e. POST/GET request must be the intended request
from the user access to web server.  Authentication is "provision of assurance
that a claimed characteristic of an entity is correct" ISO 27000:2014
2.7.  Authorization is permission, in short.

Request forgery (CSRF) is typical authenticity issue, not
authorization. CSRF becomes security issue when non-authentic request
could damage something.

There is anonymous authenticity also. For example, anonymous
BBS/comment system requires authenticity (CSRF protection). Otherwise,
attacker would post "I'll detonate bomb!!" to the BBS/comment system
on behalf of others.

> This is a bad argument and ignores everything else that has been said so far
> - you can't override a large amount of reasonable arguments by generalizing
> on a single shared property.

I don't understand this part...

Anyway, main reason why other session managers do not cover CSRF
attack protection is lack of required features. In order to implement
CSRF protection, system must have output buffering and rewrite
mechanism. PHP has both. There is no reason not to implement CSRF
attack protection especially if it is a major security issue.

There should be very good reasons to decline this RFC. I don't see
convincing reasons, yet.

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] Pipe Operator

[Stanislav Malyshev]

Hi!


> If the issue is $$ feels too Perl like, what is the alternative?  Is
> there another way to chain methods cleanly?

Well, that's a loaded question. It presumes we already agreed on needing
to chain methods using special syntax outlined in the RFC - which we
didn't - and the only problem is whether it's $$ or $* or @% or some
other sequence of symbols. I'm not convinced at all of the premise, so
discussing which exactly two characters should be used for $$ does not
really appeal to me.

> In a sense, what we're really talking about here is continuations. 

Not sure how it's continuations:
https://en.wikipedia.org/wiki/Continuation

If anything, generators look like continuations. This just looks like
fancy way to write sequence of function calls with novel syntax. Do you
mean something else by "continuations"? Or I missed some part of the RFC?

> a series of single parameter functions.  So what if we were to limit the
> concurrency syntax to single-parameter functions?  And if you want to
> reduce a multi-parameter function to a single parameter function, yay
> closures.

I'm not sure where "concurrency syntax" comes from. What's concurrent here?

> Either way, I firmly believe that more functional-friendly capabilities
> like continuations, promises, etc. are a direction that PHP needs to
> move, and syntax in that direction is valuable.

I'm not sure that's where PHP *needs* to move, but we already have
continuations, as I mentioned. As for other async capabilities like
promises/futures, that may be possible but there are some hard questions
need to be answered here because PHP is not well suited for environment
sharing.

I also am not sure functional syntax is well suited for PHP, given that
PHP is not a functional language and vast majority on PHP code is not
written in functional manner. Functional programming requires quite
different approach than most PHP applications take, and frankly I'm not
sure why this should change - there are enough functional languages around.

Of course, that doesn't mean avoiding *all* functional features - some
of them make total sense even in non-functional language, like closures
or functions like map/reduce/filter. Some, however, are harder to fit.
-- 
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] Pipe Operator

[Larry Garfield]

On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> Hi!
> 
> > |> seems like a common symbol to use, but it admittedly does look a
> 
> So, usage in one semi-obscure language (F#) and one completely obscure
> one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
> now qualifies for "common". And that counting the fact that neither of
> them actually uses the worst part of proposed syntax - magic variable $$.
> -- 
> Stas Malyshev
> smalys...@gmail.com

If the issue is $$ feels too Perl like, what is the alternative?  Is
there another way to chain methods cleanly?

In a sense, what we're really talking about here is continuations. 
Continuations (over-simplified) are a clean way of setting up "run this
function, pass its result to this function, pass its result to this
function, etc."  That makes composition really easy.  |> is essentially
a continuation syntax.  The $$ is to work around the fact that PHP
function can have an arbitrary number of parameters, whereas
continuations work best with single-parameter functions.

Of course, with currying any multi-parameter function can be reduced to
a series of single parameter functions.  So what if we were to limit the
concurrency syntax to single-parameter functions?  And if you want to
reduce a multi-parameter function to a single parameter function, yay
closures.

Would that limitation help or hinder?

Either way, I firmly believe that more functional-friendly capabilities
like continuations, promises, etc. are a direction that PHP needs to
move, and syntax in that direction is valuable.

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

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

[Andrey Andreev]

Hi,

On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev  wrote:
> >
> > It assumes, and thus also encourages, that users have an active session
> at
> > all times - this is bad. You're not supposed to start a session for a
> user
> > *until they have logged-in*.
>
> You don't have to use it if don't need it or has other complement such
> as double submit cookie.
>
>
I am not concerned about using it myself.

I am against it because it is (among other things) ineffective and
encourages a bad practice, which I've explained below ... v


> > If you do, then unless you're not storing session data server-side (which
> > is hard to do properly and is not supported by ext/session), you're
> almost
> > certainly vulnerable to some form of DoS (e.g. inodes and/or
> memory/storage
> > being filled-up), exhaustion of free IDs, entropy available for new
> session
> > ID generation, pre-fetching of IDs to work around use_strict_mode
> > restrictions, etc.
>
>
^ ... and you misunderstood it:


> None of these arguments make sense...
> It does not consume much resources. Moreover, this RFC's CSRF
> protection requires less resources than most web frameworks'
> implementation that use session for CSRF protections.
>
>
Nowhere have I said that your CSRF implementation uses a lot of resources
(although it does use more server-side resources than the "double submit
cookie" method, simply because it stores the token on the server).

I am talking about the implications of calling session_start() for
unauthenticated users.
Calling session_start() "blindly", before login is what opens the door for
the vulnerabilities that I've listed. Not because of heavy resource usage,
but because it allows an attacker to use-up as many single sessions as they
wish, until that results in some form of DoS.


>
> >
> > Therefore, while the session store *after login* is suitable for token
> > storage, CSRF protection by default just doesn't belong in ext/session.
>
> Session task, by its definition, is to distinguish and manage state of
> requests. Session must distinguish requests, i.e. must keep
> authenticity. CSRF is obvious authenticity issue. Some of us see
> session manager as just a storage, but it's not a correct definition.
>

No, CSRF is an authorization issue. Authorization (authority) depends on
authenticity, but is not the same thing.

This is a bad argument and ignores everything else that has been said so
far - you can't override a large amount of reasonable arguments by
generalizing on a single shared property.

Cheers,
Andrey.

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

[Yasuo Ohgaki]

Hi Andrey,

On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev  wrote:
> Hi,
> This gets a -1 from me as well.
>
> Much has been said already about why this is a bad idea, to the point where
> I don't know why there's still discussion around it. But here's one more
> reason ...
>
> It assumes, and thus also encourages, that users have an active session at
> all times - this is bad. You're not supposed to start a session for a user
> *until they have logged-in*.

You don't have to use it if don't need it or has other complement such
as double submit cookie.

> If you do, then unless you're not storing session data server-side (which
> is hard to do properly and is not supported by ext/session), you're almost
> certainly vulnerable to some form of DoS (e.g. inodes and/or memory/storage
> being filled-up), exhaustion of free IDs, entropy available for new session
> ID generation, pre-fetching of IDs to work around use_strict_mode
> restrictions, etc.

None of these arguments make sense...
It does not consume much resources. Moreover, this RFC's CSRF
protection requires less resources than most web frameworks'
implementation that use session for CSRF protections.

BTW, use_strict_mode is not a "restriction", but a mandatory
requirement for proper session management. What current session
manager is broken is other parts like inadequate session data lifetime
management.

>
> Therefore, while the session store *after login* is suitable for token
> storage, CSRF protection by default just doesn't belong in ext/session.

Session task, by its definition, is to distinguish and manage state of
requests. Session must distinguish requests, i.e. must keep
authenticity. CSRF is obvious authenticity issue. Some of us see
session manager as just a storage, but it's not a correct definition.

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 Arvids,

On Wed, May 11, 2016 at 5:54 PM, Arvids Godjuks
 wrote:
> 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki :
>>
>> Hi Arvids,
>>
>> On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
>>  wrote:
>> > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on
>> > by
>> > default and having any INI settings that affect how engine processes
>> > data in
>> > runtime.
>> > People just don't learn until they shotgun themselves I guess.
>>
>> Override them if you don't like admins to set INI values. I've
>> modified session_start() so that it can set INI values as function
>> parameter.
>> http://php.net/session_start
>
>
> Admins can just forbid to change any settings. And there is an ini setting
> "disable_functions" and alike. They will setup up session auto start and
> forbid usage of the session_start. And force the CSRF. Been in similar
> situations, done that, never want to deal with it again.

Then you should check offending settings.
INI system has downsides, but it has lots of upsides. You just have to
live with it.

Regarding this RFC, you don't have to care "don't work situation"
because it's obvious to users. I'll make sure the manual has proper
warnings.

I understand you don't like INI system, but it cannot be good reason
for declining tool for major security issue. There should be stronger
reason to decline. IMHO.

> I'm not even talking about the fact, that I may have reasons to use a
> different hashing algorithm in the first place.
> Dealing with JS side, when you need to pass the CSRF token there is next can
> of worms.
> And then you get to the part, where you need to use a distributed session
> management, that has it's own can of worms. And forcing CSRF handling into
> the session module probably is going to make it hard to deal with it at all.
>
> So no, sessions are sessions, they should have only one thing to be
> responsible for - storing data. Nothing else. It's a module that already has
> a lot of issues. What you are proposing, is to do what APC did - mixing code
> opcache with shared memory storage. We all know how it ended.

Session task is not a storing data. If you need storage, you can
simply use file, database, etc.

Session task, by definition, is to manage state of
connections/requests, distinguish connections/requests i.e. provide
authenticity.

CSRF is authenticity problem by its definition. Therefore, it is a
task of session manager. I know other system's session managers fail
to cover it, but we don't have to follow inferior design.

>
>>
>>
>>
>> > What I personally would be for, is a CSRF aPI module that comes as
>> > default,
>> > like the Password API one, that gives ability to generate good quality
>> > CSRF
>> > tokens and manage it.
>>
>> Imagine number of CSRF vulnerabilities in PHP apps. It's countless.
>>
>> Letting users to choose right way is not an good options. It is
>> proven. I've added session.use_strict_mode (disallows permanent
>> session hijack, etc) many years ago, but fair number of users aren't
>> enabling this option. I suspect most majority of users aren't enabled
>> it. Even if we provide solution, it's hard to be adopted. If there is
>> no solution, outcome is easy to imagine. IMHO.
>>
>> Users had access to good PRNG. Even if mt_rand() is used, it is hard
>> enough for attackers to guess, yet there are countless CSRF
>> vulnerabilities. What's the reason to ignore the fact, huge number of
>> CSRF vulnerabilities exist in PHP apps?
>>
>> I cannot understand rationale behind you and others think it should be
>> users task completely...
>
>
> If user does not want to use CSRF, you can't force him. And realisticly
> speaking, how are you going to force the tokents on the GET urls? Rewrite
> them. In JSON? In XML? etc? C'mon, these days url's there are single page
> apps with their own routing and stuff and you will never get a CSRF token in
> any automated maner there. It needs to be done by developer of the app.

I don't force, but CSRF protection is optional. If you don't need it,
don't use simply.

>
>>
>>
>> Anyway, I fails to see the reason why PHP should not invalidate CSRF
>> attacks against POST requests with 2 simple parameter or INI...
>
>
> Because they may be out of your control and just  forced on you by a 3rd 
> party.
> Not to mention that 3rd party libraries will do stuff that will not take into 
> account
> this setting or do some hack, and that will negate any security.

If apps has its own CSRF protection, it works independently.
What will negate security? I can think of "session.csrf_domains"
misuse/abuse, but it is the same as cross origin request misuse/abuse.
Cross origin request is common these days and user should be able to
use them correctly. "session.csrf_domains" misuse/abuse is not our
problem.

Regards,

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: 

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

[Yasuo Ohgaki]

Hi Kinn,

On Wed, May 11, 2016 at 8:36 PM, Kinn Julião  wrote:
> You're making confusion between CSRF and Session Hijacking... In any moment
> I mentioned about hijacking someone else's session, but to still being able
> to CSRF (Cross Site Request Forgery).
>
> Any other remote source would still be able to use your "example".
>
> "A is using your own site's contact form, with a plotted csrf token as a
> hidden field in the form, and the same stored in the session".
> With your token solution for asynchronous requests:
> "A is using your own site's contact form, with a csrf token remotely
> requested, and the same stored in its session".
> "B is spamming your site's contact form, with a csrf token remotely
> requested, and the same stored in its session".
>
> Which means: B still being able to CSRF. Which is tottaly different from
> Session Hijacking.

You've said

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

I probably understand the reason why you misunderstood now.

This CSRF protection is works like Trans SID as RFC introduction
states. It is as secure as Trans SID. If you are curious, study Trans
SID and why it is adequately safe.

Regards,

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

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

[PHP-DEV] wiki.php.net bug

[Yasuo Ohgaki]

Hi,

wiki.php.net seems to have a bug that prevent saving document.

How to reproduce
 - Edit page
 - Preview page
 - Try to save, then it errors

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] Allow loading extensions by name

[Fleshgrinder]

On 5/10/2016 10:07 PM, Lester Caine wrote:
> 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 am using Windows and the CLI all day professionally. Yes, people tend
to think like that but it is ancient thinking. Windows is a very capable
operating system and allows you to perform all tasks. Although I have to
admit that PHP tends to be very slow on Windows compared to Linux, that
is a fact.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Lester Caine]

Post from tablet seems to have gone missing ...

On 11/05/16 16:41, Andrey Andreev wrote:
> On Wed, May 11, 2016 at 5:46 PM, Lester Caine  wrote:
> 
>> On 11/05/16 14:40, Andrey Andreev wrote:
>>> Therefore, while the session store *after login* is suitable for token
>>> storage, CSRF protection by default just doesn't belong in ext/session.
>>
>> If I am using php simply to 'add detail' to an element of a page that
>> does not require the client to be logged in then I don't see any ned to
>> enable CSRF, but one of the options on that anonymous guest page may
>> well be a login button. Surely a large percentage of php traffic does
>> not need any security, only DoS filtering? UNTIL one is identified one
>> does not need a secure connection? Although I can see that some people
>> would want to ensure that anonymous content was 'secure', but isn't that
>> the job of https?
>>
> Your login form too needs CSRF protection. It's a chicken and egg problem.

Most of my sites have the login button hidden in the general content so
people can access the back office system from anywhere. THAT takes you
to the login page.

> A lot could be written on the rest of your comments, but they are not
> relevant to the RFC.

'Automatic CSRF Protection' is again just part of a bigger problem. One
thing which has changed in recent months is the availability of free
https certificates, the one thing that has up until now blocked a more
general switch TO https? But again, I don't see that this proposal makes
any sense when all the frameworks I've seen already have their own
managed csrf systems ... and enforce https links when using them?

-- 
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 DRAFT] Automatic CSRF Protection

[Andrey Andreev]

On Wed, May 11, 2016 at 7:16 PM, Niklas Keller  wrote:

>
> 2016-05-11 17:41 GMT+02:00 Andrey Andreev :
>
>>
>> Your login form too needs CSRF protection. It's a chicken and egg problem.
>>
>
> Not really. As long as you don't have the credentials.
> You can't make any requests as the authenticated user, as there is no
> authenticated user.
>
>
Riding an authenticated user's session is the obvious, and indeed most
serious CSRF attack, but not the only one ...

An attacker-chosen account could be leveraged for phishing, and depending
on the functionality of the website - possibly also XSS, malicious software
distribution, who knows what else.

Cheers,
Andrey.

[PHP-DEV] Re: Single Stack for all generators

[Nikita Popov]

On Wed, May 11, 2016 at 4:54 PM, Dmitry Stogov  wrote:

> Hi,
>
>
> Nikita, please review the patch
> https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac
>
> It's the next attempt to use the single stack for all generators.
>
> Now I don't see any problems or BC breaks.
>
>
> In case "yield" is used as an expression in context of function call. e.g.
> var_dump(yield), engine backups and then restores active call frame chain.
>
>
> Bob tested the patch on application that intensively uses generators, and
> reported:
>
> 15% less L2 cache loads
>
> 20% less cycle stalls due to memory subsystem
>
> 3% more  CPU_CLOCK_UNHALTED due to additional freeze/restore.
>
>
> I'm going to commit this patch tomorrow.
>
The patch looks fine to me.

>From my own testing with a "Hello World" Aerys server, after multiple
benchmark runs it previously started to mmap+munmap two new MM segments on
each request, leading to a decline from 50k rps to 5k. With the patch this
no longer occurs and the rps is stable at > 50k rps. (Though that may be
more luck than anything.)

Nikita

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

[Niklas Keller]

2016-05-11 17:41 GMT+02:00 Andrey Andreev :

> On Wed, May 11, 2016 at 5:46 PM, Lester Caine  wrote:
>
> > On 11/05/16 14:40, Andrey Andreev wrote:
> > > Therefore, while the session store *after login* is suitable for token
> > > storage, CSRF protection by default just doesn't belong in ext/session.
> >
> > If I am using php simply to 'add detail' to an element of a page that
> > does not require the client to be logged in then I don't see any ned to
> > enable CSRF, but one of the options on that anonymous guest page may
> > well be a login button. Surely a large percentage of php traffic does
> > not need any security, only DoS filtering? UNTIL one is identified one
> > does not need a secure connection? Although I can see that some people
> > would want to ensure that anonymous content was 'secure', but isn't that
> > the job of https?
> >
> >
> Your login form too needs CSRF protection. It's a chicken and egg problem.
>

Not really. As long as you don't have the credentials.
You can't make any requests as the authenticated user, as there is no
authenticated user.

But logout needs it, that's often forgotten.


> A lot could be written on the rest of your comments, but they are not
> relevant to the RFC.
>
> Cheers,
> Andrey.
>

Re: [PHP-DEV] Single Stack for all generators

[Bob Weinand]

Looks like there is an "ine" in the link:

Correct link: https://gist.github.com/dstogov/06116f1610f45f81523a9927c6c243ac 


Bob

> Am 11.05.2016 um 17:02 schrieb Joe Watkins :
> 
> 404
> 
> Cheers
> Joe
> 
> On Wed, May 11, 2016 at 3:54 PM, Dmitry Stogov  wrote:
> 
>> Hi,
>> 
>> 
>> Nikita, please review the patch
>> https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac
>> 
>> It's the next attempt to use the single stack for all generators.
>> 
>> Now I don't see any problems or BC breaks.
>> 
>> 
>> In case "yield" is used as an expression in context of function call. e.g.
>> var_dump(yield), engine backups and then restores active call frame chain.
>> 
>> 
>> Bob tested the patch on application that intensively uses generators, and
>> reported:
>> 
>> 15% less L2 cache loads
>> 
>> 20% less cycle stalls due to memory subsystem
>> 
>> 3% more  CPU_CLOCK_UNHALTED due to additional freeze/restore.
>> 
>> 
>> I'm going to commit this patch tomorrow.
>> 
>> 
>> Thanks. Dmitry.
>> 

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

[Andrey Andreev]

On Wed, May 11, 2016 at 5:46 PM, Lester Caine  wrote:

> On 11/05/16 14:40, Andrey Andreev wrote:
> > Therefore, while the session store *after login* is suitable for token
> > storage, CSRF protection by default just doesn't belong in ext/session.
>
> If I am using php simply to 'add detail' to an element of a page that
> does not require the client to be logged in then I don't see any ned to
> enable CSRF, but one of the options on that anonymous guest page may
> well be a login button. Surely a large percentage of php traffic does
> not need any security, only DoS filtering? UNTIL one is identified one
> does not need a secure connection? Although I can see that some people
> would want to ensure that anonymous content was 'secure', but isn't that
> the job of https?
>
>
Your login form too needs CSRF protection. It's a chicken and egg problem.

A lot could be written on the rest of your comments, but they are not
relevant to the RFC.

Cheers,
Andrey.

Re: [PHP-DEV] Single Stack for all generators

[Joe Watkins]

404

Cheers
Joe

On Wed, May 11, 2016 at 3:54 PM, Dmitry Stogov  wrote:

> Hi,
>
>
> Nikita, please review the patch
> https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac
>
> It's the next attempt to use the single stack for all generators.
>
> Now I don't see any problems or BC breaks.
>
>
> In case "yield" is used as an expression in context of function call. e.g.
> var_dump(yield), engine backups and then restores active call frame chain.
>
>
> Bob tested the patch on application that intensively uses generators, and
> reported:
>
> 15% less L2 cache loads
>
> 20% less cycle stalls due to memory subsystem
>
> 3% more  CPU_CLOCK_UNHALTED due to additional freeze/restore.
>
>
> I'm going to commit this patch tomorrow.
>
>
> Thanks. Dmitry.
>

[PHP-DEV] Single Stack for all generators

[Dmitry Stogov]

Hi,


Nikita, please review the patch 
https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac

It's the next attempt to use the single stack for all generators.

Now I don't see any problems or BC breaks.


In case "yield" is used as an expression in context of function call. e.g. 
var_dump(yield), engine backups and then restores active call frame chain.


Bob tested the patch on application that intensively uses generators, and 
reported:

15% less L2 cache loads

20% less cycle stalls due to memory subsystem

3% more  CPU_CLOCK_UNHALTED due to additional freeze/restore.


I'm going to commit this patch tomorrow.


Thanks. Dmitry.

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

[Lester Caine]

On 11/05/16 14:40, Andrey Andreev wrote:
> Therefore, while the session store *after login* is suitable for token
> storage, CSRF protection by default just doesn't belong in ext/session.

If I am using php simply to 'add detail' to an element of a page that
does not require the client to be logged in then I don't see any ned to
enable CSRF, but one of the options on that anonymous guest page may
well be a login button. Surely a large percentage of php traffic does
not need any security, only DoS filtering? UNTIL one is identified one
does not need a secure connection? Although I can see that some people
would want to ensure that anonymous content was 'secure', but isn't that
the job of https?

-- 
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 DRAFT] Automatic CSRF Protection

[Rowan Collins]

On 11/05/2016 14:07, Kinn Julião wrote:

So following your example then.
You could place an HTML page on a completelu different site... maybe
this page:
https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attacker_example_net
:-)


Neither of the files in that gist are demonstrating CSRF as such.

attacker_example_net is bypassing the Same Origin Policy; it 
hand-wavingly pre-supposes a misconfiguration which allows this, 
including sending the user's cookies with the cross-domain request. Note 
that if the first XHR can successfully generate a CSRF token, then you 
don't need an  tag, since a second XHR to the rewritten URL will 
succeed. At this point, you have a far stronger attack footprint than 
normal CSRF anyway, because you can access privileged data and 
arbitrarily impersonate the user in a 2-way conversation with the server.


supersafe.com_img.jpg is simply a spam script. The request to 
http://example.com/contact.php is coming from the server hosting the 
site, and doesn't impersonate anybody. If the form requires the user to 
have previously authenticated, this will simply fail, because it never 
authenticates as anybody. If your implication is that you've tricked 
somebody else's *server* into executing this code, that's yet another 
type of attack, and there are much worse things you could do with the 
ability to run arbitrary code on their server.




As I mentioned in comments there:
/*
From this point, this attack will only work if:
1 - CORS is missconfigured
*/


Yes. As OWASP says, to protect against CSRF, one must first protect 
against XSS. However, protecting against XSS does not protect against 
CSRF, so token-checking or similar countermeasures are still necessary.




If the user must be responsible to secure it properly, why should be this magic 
added to the core?


I'm not convinced it should be in the core, but "some users will have 
XSS vulnerabilities" is not a good reason for it not to be.



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

[Andrey Andreev]

Hi,
This gets a -1 from me as well.

Much has been said already about why this is a bad idea, to the point where
I don't know why there's still discussion around it. But here's one more
reason ...

It assumes, and thus also encourages, that users have an active session at
all times - this is bad. You're not supposed to start a session for a user
*until they have logged-in*.
If you do, then unless you're not storing session data server-side (which
is hard to do properly and is not supported by ext/session), you're almost
certainly vulnerable to some form of DoS (e.g. inodes and/or memory/storage
being filled-up), exhaustion of free IDs, entropy available for new session
ID generation, pre-fetching of IDs to work around use_strict_mode
restrictions, etc.

Therefore, while the session store *after login* is suitable for token
storage, CSRF protection by default just doesn't belong in ext/session.

Cheers,
Andrey.

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

[Kinn Julião]

So following your example then.
You could place an HTML page on a completelu different site... maybe this
page:
https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attacker_example_net
:-)

As I mentioned in comments there:
/*
>From this point, this attack will only work if:
1 - CORS is missconfigured
*/

The understanding is: the user must be responsible to configure it
properly, to secure it properly.
If the user must be responsible to secure it properly, why should be this
magic added to the core?

On Wed, May 11, 2016 at 8:48 AM, Rowan Collins 
wrote:

> On 11/05/2016 13:22, Kinn Julião wrote:
>
>> CSRF is not related to spam or rate limiting, it is related to
>>>
>> impersonation. A spam bot can simply repeatedly request new HTML forms
>> and scrape out the hidden input.
>>
>> The Spam bot was just an example, contering his own example.
>>
>> And it still a cross site request... Either if it comes from a bot or not.
>>
>
> No, it's just "a request". I ask for a URL, I get some content. There is
> no "cross-site" involved, and no "forgery".
>
>
> About the pixel, what can prevent a mail pixel to point to
>> "attacker.com/img.jpg " which fetches the
>> "whatever_his_enpoint_to_return_the_token.php", grab the token and
>> forward to the form? The same as what prevets it from scraping the html?
>> Nothing... So in the end, this RFC improves nothing as mentioned above.
>>
>
> What you are saying there is "all CSRF tokens are pointless". The large
> number of articles recommending them and libraries implementing them should
> be a pretty big clue that they are not.
>
> I think you are misunderstanding how the attack works; here is a simple
> example. If you are logged into a site called victim.example.com, I can
> place an HTML page on a completely different site (say,
> attacker.example.net) with the following code:
>
> http://victim.example.com/change_password.php?new_password=h4xx0r;>
>
> Your browser will then send a request to the specified URL, and execute
> the command. At no point does the server at attacker.example.net receive
> any data from victim.example.com, but it can trick you into sending
> commands to it, with your authenticated privileges.
>
> With a CSRF token in place, the passive attack above will be rejected -
> "missing or invalid CSRF token". In the response, a fresh CSRF token may
> well be forwarded to your browser, but it is never forwarded to the
> attacker.
>
> Let's say we have an endpoint that simply checks the request cookies and
> generates a new CSRF token, as in Yasuo's example, the attacker could of
> course write this:
>
> http://victim.example.com/generate_csrf_token.php;>
>
> But this is no use - it tricks you into sending a command that generates a
> new token, but the attacker can't see what token was generated, so can't
> impersonate you.
>
>
> If you can read the value of that response, that is an XSS vulnerability.
> As the OWASP page linked to earlier says "any cross-site scripting
> vulnerability can be used to defeat token, Double-Submit cookie, referer
> and origin based CSRF defenses":
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#No_Cross-Site_Scripting_.28XSS.29_Vulnerabilities
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>



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

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

[Rowan Collins]

On 11/05/2016 13:22, Kinn Julião wrote:

CSRF is not related to spam or rate limiting, it is related to

impersonation. A spam bot can simply repeatedly request new HTML forms
and scrape out the hidden input.

The Spam bot was just an example, contering his own example.

And it still a cross site request... Either if it comes from a bot or not.


No, it's just "a request". I ask for a URL, I get some content. There is 
no "cross-site" involved, and no "forgery".




About the pixel, what can prevent a mail pixel to point to
"attacker.com/img.jpg " which fetches the
"whatever_his_enpoint_to_return_the_token.php", grab the token and
forward to the form? The same as what prevets it from scraping the html?
Nothing... So in the end, this RFC improves nothing as mentioned above.


What you are saying there is "all CSRF tokens are pointless". The large 
number of articles recommending them and libraries implementing them 
should be a pretty big clue that they are not.


I think you are misunderstanding how the attack works; here is a simple 
example. If you are logged into a site called victim.example.com, I can 
place an HTML page on a completely different site (say, 
attacker.example.net) with the following code:


src="http://victim.example.com/change_password.php?new_password=h4xx0r;>


Your browser will then send a request to the specified URL, and execute 
the command. At no point does the server at attacker.example.net receive 
any data from victim.example.com, but it can trick you into sending 
commands to it, with your authenticated privileges.


With a CSRF token in place, the passive attack above will be rejected - 
"missing or invalid CSRF token". In the response, a fresh CSRF token may 
well be forwarded to your browser, but it is never forwarded to the 
attacker.


Let's say we have an endpoint that simply checks the request cookies and 
generates a new CSRF token, as in Yasuo's example, the attacker could of 
course write this:


http://victim.example.com/generate_csrf_token.php;>

But this is no use - it tricks you into sending a command that generates 
a new token, but the attacker can't see what token was generated, so 
can't impersonate you.



If you can read the value of that response, that is an XSS 
vulnerability. As the OWASP page linked to earlier says "any cross-site 
scripting vulnerability can be used to defeat token, Double-Submit 
cookie, referer and origin based CSRF defenses": 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#No_Cross-Site_Scripting_.28XSS.29_Vulnerabilities


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

[Rowan Collins]

On 11/05/2016 09:13, Yasuo Ohgaki wrote:

Why

SESSION_CSRF_POST,
'csrf_validate'=>SESSION_CSRF_POST]);
?>

and protect CSRF attacks against POST requests are bad for PHP and its users?


1) Because it gives users a false sense of security. If you say "turn 
this on and don't think about CSRF", and then somebody is caught by a 
CSRF vulnerability because the HTML rewriter wasn't smart enough to 
inject the parameter in the right place, they will feel you misled them. 
If you can't say that, then it's not really as simple as you implied.


2) Because it treats all users as malicious actors, rather than fallible 
ones. If you take too long writing a comment, you shouldn't get a 500 
error when you submit it, you should get a friendly message and a 
pre-filled form. That requires integration with the application 
framework, not with the session manager.


3) Because it complicates the session code with extra responsibilities, 
rather than concentrating on safely persisting arbitrary state data.


4) Because it adds yet another global setting that would be essential to 
be turned on for some applications, off for others.


The current proposal has effectively 4 features:

- Automatic generation and storage of a CSRF token on session start; a 
fairly trivial task to implement in plain PHP.


- Optional automatic rewriting of HTML to include the token. This is the 
only part that is actually hard to do without the core's involvement, 
but see point 1 above.


- A method to validate the CSRF token. Again, this is fairly simple to 
implement in PHP, and a quick glance at Packagist shows there are plenty 
of off-the-shelf implementations with various features.


- Optional automatic enforcement of the CSRF check. This is also fairly 
easy to implement in plain PHP, and since the user is likely to need to 
implement user code to make use of it anyway (e.g. set_error_handler is 
mentioned in the current RFC), it may actually be easier to perform the 
check manually.



Thinking about it, the only part that has some value being in core is 
the HTML rewriting. Perhaps what is actually needed is a lower-level 
function that PHP libraries can use to hook into this with whatever 
parameters they want, e.g.


register_html_rewrite_callback(
function() { return [ 'csrf_token' => MyFramework\CSRF::getToken() 
]; },

REWRITE_POST_FORMS | REWRITE_URL
);


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

[Kinn Julião]

And again, I'm bashing against/based in his poor example for asynchronous
requests...
On May 11, 2016 8:22 AM, "Kinn Julião"  wrote:

> > CSRF is not related to spam or rate limiting, it is related to
> impersonation. A spam bot can simply repeatedly request new HTML forms and
> scrape out the hidden input.
>
> The Spam bot was just an example, contering his own example.
>
> And it still a cross site request... Either if it comes from a bot or not.
>
> About the pixel, what can prevent a mail pixel to point to "
> attacker.com/img.jpg" which fetches the
> "whatever_his_enpoint_to_return_the_token.php", grab the token and forward
> to the form? The same as what prevets it from scraping the html? Nothing...
> So in the end, this RFC improves nothing as mentioned above.
> On May 11, 2016 8:16 AM, "Rowan Collins"  wrote:
>
>> On 11/05/2016 12:36, Kinn Julião wrote:
>>
>>> You're making confusion between CSRF and Session Hijacking... In any
>>> moment
>>> I mentioned about hijacking someone else's session, but to still being
>>> able
>>> to CSRF (Cross Site Request Forgery).
>>>
>>
>> CSRF generally implies tricking an authenticated user into making a
>> request using their own session. Without any form of token check, an
>> identical request will be sent from any user, so you don't need to know
>> anything about the user or their session to perform the attack - it can in
>> fact be entirely passive, e.g. the src of an  embedded in another page.
>>
>> With a CSRF token bound to each session, you can't perform a passive
>> attack, because you need to first discover some information from their
>> session, and target the attack.
>>
>> Without tricking the user into submitting the request with their own
>> authentication, there is no forgery, and no attack.
>>
>>
>> Any other remote source would still be able to use your "example".
>>>
>>
>> A remote source would only be able to read their own CSRF token, not that
>> of another user. If they are not authorised to submit the content, it is
>> not the CSRF token's job to enforce that.
>>
>>
>> "A is using your own site's contact form, with a plotted csrf token as a
>>> hidden field in the form, and the same stored in the session".
>>> With your token solution for asynchronous requests:
>>> "A is using your own site's contact form, with a csrf token remotely
>>> requested, and the same stored in its session".
>>>
>>
>> All CSRF tokens are "remotely requested", in that they are sent from the
>> server to the client's browser during a legitimate request. There is no
>> difference in exposure between an HTML hidden input in the response to "GET
>> /display_comment_form.php" and a JSON value in the response to "GET
>> /generate_form_token.php".
>>
>>
>> "B is spamming your site's contact form, with a csrf token remotely
>>> requested, and the same stored in its session".
>>>
>>
>> CSRF is not related to spam or rate limiting, it is related to
>> impersonation. A spam bot can simply repeatedly request new HTML forms and
>> scrape out the hidden input.
>>
>> 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

[Kinn Julião]

> CSRF is not related to spam or rate limiting, it is related to
impersonation. A spam bot can simply repeatedly request new HTML forms and
scrape out the hidden input.

The Spam bot was just an example, contering his own example.

And it still a cross site request... Either if it comes from a bot or not.

About the pixel, what can prevent a mail pixel to point to "
attacker.com/img.jpg" which fetches the
"whatever_his_enpoint_to_return_the_token.php", grab the token and forward
to the form? The same as what prevets it from scraping the html? Nothing...
So in the end, this RFC improves nothing as mentioned above.
On May 11, 2016 8:16 AM, "Rowan Collins"  wrote:

> On 11/05/2016 12:36, Kinn Julião wrote:
>
>> You're making confusion between CSRF and Session Hijacking... In any
>> moment
>> I mentioned about hijacking someone else's session, but to still being
>> able
>> to CSRF (Cross Site Request Forgery).
>>
>
> CSRF generally implies tricking an authenticated user into making a
> request using their own session. Without any form of token check, an
> identical request will be sent from any user, so you don't need to know
> anything about the user or their session to perform the attack - it can in
> fact be entirely passive, e.g. the src of an  embedded in another page.
>
> With a CSRF token bound to each session, you can't perform a passive
> attack, because you need to first discover some information from their
> session, and target the attack.
>
> Without tricking the user into submitting the request with their own
> authentication, there is no forgery, and no attack.
>
>
> Any other remote source would still be able to use your "example".
>>
>
> A remote source would only be able to read their own CSRF token, not that
> of another user. If they are not authorised to submit the content, it is
> not the CSRF token's job to enforce that.
>
>
> "A is using your own site's contact form, with a plotted csrf token as a
>> hidden field in the form, and the same stored in the session".
>> With your token solution for asynchronous requests:
>> "A is using your own site's contact form, with a csrf token remotely
>> requested, and the same stored in its session".
>>
>
> All CSRF tokens are "remotely requested", in that they are sent from the
> server to the client's browser during a legitimate request. There is no
> difference in exposure between an HTML hidden input in the response to "GET
> /display_comment_form.php" and a JSON value in the response to "GET
> /generate_form_token.php".
>
>
> "B is spamming your site's contact form, with a csrf token remotely
>> requested, and the same stored in its session".
>>
>
> CSRF is not related to spam or rate limiting, it is related to
> impersonation. A spam bot can simply repeatedly request new HTML forms and
> scrape out the hidden input.
>
> 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

[Rowan Collins]

On 11/05/2016 12:36, Kinn Julião wrote:

You're making confusion between CSRF and Session Hijacking... In any moment
I mentioned about hijacking someone else's session, but to still being able
to CSRF (Cross Site Request Forgery).


CSRF generally implies tricking an authenticated user into making a 
request using their own session. Without any form of token check, an 
identical request will be sent from any user, so you don't need to know 
anything about the user or their session to perform the attack - it can 
in fact be entirely passive, e.g. the src of an  embedded in 
another page.


With a CSRF token bound to each session, you can't perform a passive 
attack, because you need to first discover some information from their 
session, and target the attack.


Without tricking the user into submitting the request with their own 
authentication, there is no forgery, and no attack.




Any other remote source would still be able to use your "example".


A remote source would only be able to read their own CSRF token, not 
that of another user. If they are not authorised to submit the content, 
it is not the CSRF token's job to enforce that.




"A is using your own site's contact form, with a plotted csrf token as a
hidden field in the form, and the same stored in the session".
With your token solution for asynchronous requests:
"A is using your own site's contact form, with a csrf token remotely
requested, and the same stored in its session".


All CSRF tokens are "remotely requested", in that they are sent from the 
server to the client's browser during a legitimate request. There is no 
difference in exposure between an HTML hidden input in the response to 
"GET /display_comment_form.php" and a JSON value in the response to "GET 
/generate_form_token.php".




"B is spamming your site's contact form, with a csrf token remotely
requested, and the same stored in its session".


CSRF is not related to spam or rate limiting, it is related to 
impersonation. A spam bot can simply repeatedly request new HTML forms 
and scrape out the hidden input.


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]

Le 11/05/2016 à 06:59, Joe Watkins a écrit :

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.


I realize that I shouldn't have mentioned the possibility to unify 
Windows/Unix configurations, even if I personally have cases where 
WIndows & Unix INI files need to be duplicated just because of 
'extension=' lines. Once again, we are stuck in 'if it doesn't solve 
everything, it's useless'.


So, please consider it just make things easier for documentation writers 
and end-users. You may think that 'the knowledge is well dispersed' but, 
about every months, I see people from project teams coming at me and 
asking why the 'extension=php_xxx.dll' line they found on Internet 
doesn't work on their Linux installation. After years of similar 
requests, I'm proposing this change. But I'm probably wrong and it is 
clear that everyone in the world has the same knowledge about PHP as 
yours or mine!


Regards

François

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

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

[Lester Caine]

On 11/05/16 12:53, François Laupretre wrote:
> Le 11/05/2016 à 08:20, Christian Stoller a écrit :
>>> -Ursprüngliche Nachricht-
>>> Von: François Laupretre [mailto:franc...@php.net], Gesendet:
>>> Dienstag, 10. Mai 2016 15:23
>>>
>>> Please read and comment :
>>>
>>> https://wiki.php.net/rfc/load-ext-by-name
>> Why not just naming them *.so on all platforms and removing the "php_"
>> prefix on Windows?
>>
>> Apache modules on Windows also have the .so suffix.
> 
> AFAIK, the 'php_' prefix is required on WIndows because, without it,
> some extension file names would conflict with system DLLs. The only way
> to unify names would be to add the php_ prefix everywhere. This is the
> mechanism used by Apache, with the 'mod_' prefix. Unfortunately, PHP
> started on Unix, where the prefix was not needed, and didn't want to
> change the Unix behavior when Windows support was added.
> 
> About the '.so' suffix, some systems don't use this as shared lib
> suffix. HP-UX, for instance, uses '.sl', and others exist, like
> '.dynlib'. On some systems, you cannot load a dynamic library if its
> suffix is not the right one. So , '.so' is not usable everywhere.

One tends to forget the reason some decisions were made, and when
prompted the reasons come back. It's the simple fact that windows will
look in the path to see if it finds a copy of a 'library' which is the
main problem here, and in my case it's finding copies of the gds32.dll
which are the wrong format for the php_interbase.dll extension. I'm
seeing the same problem with other third party clients, so in my book it
is important to keep using the extension so one knows exactly which
files are involved.

But as I said I properly planned revamp of handling extensions does make
sense?

-- 
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: AW: [PHP-DEV] [RFC] Allow loading extensions by name

[Rowan Collins]

On 11/05/2016 07:20, Christian Stoller wrote:

Why not just naming them *.so on all platforms


While it can't be relied on, a file suffix does communicate something 
about the type of the file. Someone might list the downloads for an 
extension as "foo.so (for Linux/Unix); foo.dll (for Windows)" and it 
would be obvious what format the files were in.



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

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

[François Laupretre]

Le 11/05/2016 à 08:20, Christian Stoller a écrit :

-Ursprüngliche Nachricht-
Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. Mai 
2016 15:23

Please read and comment :

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

Regards

François



Why not just naming them *.so on all platforms and removing the "php_" prefix 
on Windows?

Apache modules on Windows also have the .so suffix.

Best regards
Christian



AFAIK, the 'php_' prefix is required on WIndows because, without it, 
some extension file names would conflict with system DLLs. The only way 
to unify names would be to add the php_ prefix everywhere. This is the 
mechanism used by Apache, with the 'mod_' prefix. Unfortunately, PHP 
started on Unix, where the prefix was not needed, and didn't want to 
change the Unix behavior when Windows support was added.


About the '.so' suffix, some systems don't use this as shared lib 
suffix. HP-UX, for instance, uses '.sl', and others exist, like 
'.dynlib'. On some systems, you cannot load a dynamic library if its 
suffix is not the right one. So , '.so' is not usable everywhere.


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

[Kinn Julião]

You're making confusion between CSRF and Session Hijacking... In any moment
I mentioned about hijacking someone else's session, but to still being able
to CSRF (Cross Site Request Forgery).

Any other remote source would still be able to use your "example".

"A is using your own site's contact form, with a plotted csrf token as a
hidden field in the form, and the same stored in the session".
With your token solution for asynchronous requests:
"A is using your own site's contact form, with a csrf token remotely
requested, and the same stored in its session".
"B is spamming your site's contact form, with a csrf token remotely
requested, and the same stored in its session".

Which means: B still being able to CSRF. Which is tottaly different from
Session Hijacking.
On May 11, 2016 4:54 AM, "Arvids Godjuks"  wrote:

> Hi Yasuo!
>
> 2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki :
>
> > Hi Arvids,
> >
> > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
> >  wrote:
> > > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on
> > by
> > > default and having any INI settings that affect how engine processes
> > data in
> > > runtime.
> > > People just don't learn until they shotgun themselves I guess.
> >
> > Override them if you don't like admins to set INI values. I've
> > modified session_start() so that it can set INI values as function
> > parameter.
> > http://php.net/session_start
>
>
> Admins can just forbid to change any settings. And there is an ini setting
> "disable_functions" and alike. They will setup up session auto start and
> forbid usage of the session_start. And force the CSRF. Been in similar
> situations, done that, never want to deal with it again.
> I'm not even talking about the fact, that I may have reasons to use a
> different hashing algorithm in the first place.
> Dealing with JS side, when you need to pass the CSRF token there is next
> can of worms.
> And then you get to the part, where you need to use a distributed session
> management, that has it's own can of worms. And forcing CSRF handling into
> the session module probably is going to make it hard to deal with it at
> all.
>
> So no, sessions are sessions, they should have only one thing to be
> responsible for - storing data. Nothing else. It's a module that already
> has a lot of issues. What you are proposing, is to do what APC did - mixing
> code opcache with shared memory storage. We all know how it ended.
>
>
> >
> >
> > > What I personally would be for, is a CSRF aPI module that comes as
> > default,
> > > like the Password API one, that gives ability to generate good quality
> > CSRF
> > > tokens and manage it.
> >
> > Imagine number of CSRF vulnerabilities in PHP apps. It's countless.
> >
> > Letting users to choose right way is not an good options. It is
> > proven. I've added session.use_strict_mode (disallows permanent
> > session hijack, etc) many years ago, but fair number of users aren't
> > enabling this option. I suspect most majority of users aren't enabled
> > it. Even if we provide solution, it's hard to be adopted. If there is
> > no solution, outcome is easy to imagine. IMHO.
> >
> > Users had access to good PRNG. Even if mt_rand() is used, it is hard
> > enough for attackers to guess, yet there are countless CSRF
> > vulnerabilities. What's the reason to ignore the fact, huge number of
> > CSRF vulnerabilities exist in PHP apps?
> >
> > I cannot understand rationale behind you and others think it should be
> > users task completely...
> >
>
> If user does not want to use CSRF, you can't force him. And realisticly
> speaking, how are you going to force the tokents on the GET urls? Rewrite
> them. In JSON? In XML? etc? C'mon, these days url's there are single page
> apps with their own routing and stuff and you will never get a CSRF token
> in any automated maner there. It needs to be done by developer of the app.
>
>
> >
> > Anyway, I fails to see the reason why PHP should not invalidate CSRF
> > attacks against POST requests with 2 simple parameter or INI...
> >
>
> Because they may be out of your control and just forced on you by a 3rd
> party. Not to mention that 3rd party libraries will do stuff that will not
> take into account this setting or do some hack, and that will negate any
> security.
>
>
> >
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
>

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

[Michael Wallner]

On 11/05/16 12:26, Lester Caine wrote:
> On 10/05/16 21:26, Levi Morrison wrote:
>> 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.
> 
> Cart before Horse comes to mind ...
> 
> If the function is going to fail if you pass in a null ... you check for

Why do you assume it'll fail?

> the null before calling it. OK the '?' is a flag that you need to do
> that, but you really need proper documentation as to just what Foo
> expects. If I've handled the null case situation, the ? is redundant?
> 
> I'm still failing to see an overall picture of what people are trying to
> achieve. Adding errors means that those errors need to be handled. If
> the function gets a 'null' then there is a reason, and either the
> function should not have been called ... workflow failed ... or the
> function should simply handle the 'null' case. If the '?' throws an
> error the workflow is broken after the event where a user code warning
> would be more helpful.
> 

function foo(?Foo $param)

is equivalent to

function foo(Foo $param = null)

except the former does not provide a default, i.e. it requires an
argument being passed to a call to foo().

-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

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

[Quim Calpe]

On Wed, May 11, 2016 at 12:26 PM, Lester Caine  wrote:

> On 10/05/16 21:26, Levi Morrison wrote:
> > 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.
>
> Cart before Horse comes to mind ...
>
> If the function is going to fail if you pass in a null ... you check for
> the null before calling it. OK the '?' is a flag that you need to do
> that, but you really need proper documentation as to just what Foo
> expects. If I've handled the null case situation, the ? is redundant?
>

function foo(?Foo $param) Is not going to fail if you pass a null,
precisely "?" allow you to pass a null


I'm still failing to see an overall picture of what people are trying to
> achieve. Adding errors means that those errors need to be handled. If
> the function gets a 'null' then there is a reason, and either the
> function should not have been called ... workflow failed ... or the
> function should simply handle the 'null' case. If the '?' throws an
> error the workflow is broken after the event where a user code warning
> would be more helpful.
>
> --
> 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] Re: [RFC][VOTE] Nullable Types

[Lester Caine]

On 10/05/16 21:26, Levi Morrison wrote:
> 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.

Cart before Horse comes to mind ...

If the function is going to fail if you pass in a null ... you check for
the null before calling it. OK the '?' is a flag that you need to do
that, but you really need proper documentation as to just what Foo
expects. If I've handled the null case situation, the ? is redundant?

I'm still failing to see an overall picture of what people are trying to
achieve. Adding errors means that those errors need to be handled. If
the function gets a 'null' then there is a reason, and either the
function should not have been called ... workflow failed ... or the
function should simply handle the 'null' case. If the '?' throws an
error the workflow is broken after the event where a user code warning
would be more helpful.

-- 
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: AW: [PHP-DEV] [RFC] Allow loading extensions by name

[Lester Caine]

On 11/05/16 07:20, Christian Stoller wrote:
> Apache modules on Windows also have the .so suffix.

THAT was what I was forgetting ;)

-- 
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 11/05/16 05:59, Joe Watkins wrote:
> 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.

That is my thought as well. Getting windows installations of PHP working
with the third party clients needed to complete the jigsaw is irritating
at least at the moment. It's bad enough trying to tell nieve users how
to check just which client library their system is using when windows
already hides the extensions from them, and further hiding just which
extension PHP is using ... or guessing if the file has php_ in front. Is
not helping windows users. Very few Linux based installs use the php.ini
file as shipped, so there is little point making changes to that just
for the windows installs anyway?

I would like to see the name problem solved, but php_ was added for some
very good reason at that time, and then ignored by third party
extensions, which is now probably irrelevant, but I would suggest that
THAT should perhaps be the target in PHP8 along with a standardising of
named ini files containing the associated entries rather than yet
another 'sticking plaster' on something which is not going to help lon term.

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

[Rowan Collins]

On 11/05/2016 05:46, Joe Watkins wrote:

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


Arguably, with the right choice of extension methods, an implementation 
requiring a single scalar could be extended to support arbitrary 
expressions later, since "scalar" is a subset of "expression".


For instance, getAttributes() could provide a NULL value for any 
attribute with a non-scalar argument, and a separate getAttributesAST() 
could return an AST tree even if it consisted of a single constant.


I'm still not convinced the freedom of AST is justified though, as 
opposed to a constant expression parsed according to standard PHP 
semantics (e.g. an associative array) or some specific syntax 
(effectively named parameters).


I'd personally be against both options in the current RFC, because I 
think the language should be providing much more to make this useful.


Regards,
--
Rowan Collins
[IMSoP]

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

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

[Joe Watkins]

Dmitry,

> The difference is small, but attributes standardize syntax and provide
standard storage with simple API.

It's too small. If we go ahead now and introduce constants or strings as
the only supported form of attribute, we will never get anything more than
that.

> I don't know about such hooks in the engine. do I miss something? :)

There's no zend_set_magic_comments hook :D

There's mechanisms like op array ctor, reserved space, and overloading all
kinds of ways ... it's doable ... you already know it is ...

> I missed. do you speak about attributes with AST or doc-comments with
strings.

I'm saying I decided the write some extension code that "parses" doc
comments, in anticipation that we would eventually get ast attributes ...

Cheers
Joe

On Wed, May 11, 2016 at 10:09 AM, Dmitry Stogov  wrote:

>
>
> On 05/11/2016 11:42 AM, Joe Watkins wrote:
>
> Dmitry,
>
> > Except the fact, that doc-comment content don't have to conform to any
> rules
>
> Nor does an attributes value that is just a string, that isn't validated
> by compiler ... it doesn't *have* to conform to any rules.
>
> That's exactly what people are voting for though, that seems to be what
> people want
>
>
> I think, different people expect very different functionality and many
> just don't like to introduce replacement for existing doc-comments.
> Probably the majority of voters against AST, just don't care about
> applications of this feature (extensible compiler, meta-programming,
> compile-time execution, etc)
>
>
> I desperately do not want that. I don't see the remarkable difference
> (although there is obviously difference) between attributes that are just
> strings or constant values and doc comments.
>
> The difference is small, but attributes standardize syntax and provide
> standard storage with simple API.
> In my view, better to get at least this than nothing.
>
>
> > and you have to parse it and extract the necessary part of meta
> information every time you need it.
>
> You know that's not really true, there are already hooks and mechanisms to
> "compile" strings in doc comments, I used them literally yesterday ...
>
> I don't know about such hooks in the engine. do I miss something? :)
>
>
> I used them in anticipation that we would get a superior solution some
> time soon ... it now looks like we will not :(
>
>
> I missed. do you speak about attributes with AST or doc-comments with
> strings.
>
>
> I don't want to invent ways to parse code, or extract it from anywhere ...
> we have a whole engine, an entire folder of code dedicated to that, it is
> nonsensical not to utilize it.
>
>
> You shouldn't worry about parsing PHP grammar in attribute strings, we
> would just provide an API call in the engine that reuses zendparse() and
> returns AST.
> This would take just 10-20 C lines.
>
> Thanks. Dmitry.
>
>
> Cheers
> Joe
>
>
>
> On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov  wrote:
>
>>
>>
>> On 05/11/2016 09:57 AM, Joe Watkins wrote:
>>
>> Dmitry,
>>
>> > but it's possible to get the same power translating string values of
>> attributes into AST in the hooks.
>>
>> Aware.
>>
>> Enough of the complexity is already the responsibility of the consumer of
>> the attributes.
>>
>> It's already possible to get strings (and so AST) from doc comments, we
>> don't need anything new if that's all you want to do.
>>
>> Essentially, moving something from doc comments to <> makes zero
>> sense to me.
>>
>>
>> Except the fact, that doc-comment content don't have to conform to any
>> rules, and you have to parse it and extract the necessary part of meta
>> information every time you need it. It's not a big problem to do this using
>> Doctrine library, but how are you going to do this in a compiler hook?
>>
>>
>>
>> Cheers
>> Joe
>>
>> On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov < 
>> dmi...@zend.com> wrote:
>>
>>>
>>>
>>> On 05/11/2016 09:02 AM, Joe Watkins wrote:
>>>
>>> Morning Dmitry,
>>>
>>> > On the other hand simple string may be parsed into AST with just one
>>> additional call to ast\compile_string().
>>>
>>> You're not really suggesting that I write my tools in user land, are you
>>> ? It's me, Joe :)ce
>>>
>>>
>>> At first days of RFC discussion Sara pointed on over-design regarding
>>> AST.
>>> I saw sense in here comments and updated RFC.
>>>
>>>
>>> I *only* want attributes as they were originally proposed, and I can't
>>> vote to reflect that.
>>>
>>> As discussed in private, what I want is attributes, as originally
>>> proposed, and a hookable compiler; Anything else is not good enough.
>>>
>>>
>>> Personally, I'm for AST as well, but it's possible to get the same power
>>> translating string values of attributes into AST in the hooks.
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>>
>>> Cheers
>>> Joe
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < 
>>> dmi...@zend.com> wrote:
>>>
 Hi Joe,

 The sense in native support for AST is 

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

[Dmitry Stogov]

On 05/11/2016 11:42 AM, Joe Watkins wrote:

Dmitry,

> Except the fact, that doc-comment content don't have to conform to 
any rules


Nor does an attributes value that is just a string, that isn't 
validated by compiler ... it doesn't *have* to conform to any rules.


That's exactly what people are voting for though, that seems to be 
what people want


I think, different people expect very different functionality and many 
just don't like to introduce replacement for existing doc-comments.
Probably the majority of voters against AST, just don't care about 
applications of this feature (extensible compiler, meta-programming, 
compile-time execution, etc)


I desperately do not want that. I don't see the remarkable difference 
(although there is obviously difference) between attributes that are 
just strings or constant values and doc comments.
The difference is small, but attributes standardize syntax and provide 
standard storage with simple API.

In my view, better to get at least this than nothing.



> and you have to parse it and extract the necessary part of meta 
information every time you need it.


You know that's not really true, there are already hooks and 
mechanisms to "compile" strings in doc comments, I used them literally 
yesterday ...

I don't know about such hooks in the engine. do I miss something? :)



I used them in anticipation that we would get a superior solution some 
time soon ... it now looks like we will not :(


I missed. do you speak about attributes with AST or doc-comments with 
strings.




I don't want to invent ways to parse code, or extract it from anywhere 
... we have a whole engine, an entire folder of code dedicated to 
that, it is nonsensical not to utilize it.


You shouldn't worry about parsing PHP grammar in attribute strings, we 
would just provide an API call in the engine that reuses zendparse() and 
returns AST.

This would take just 10-20 C lines.

Thanks. Dmitry.


Cheers
Joe



On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov > wrote:




On 05/11/2016 09:57 AM, Joe Watkins wrote:

Dmitry,

> but it's possible to get the same power translating string
values of attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the
consumer of the attributes.

It's already possible to get strings (and so AST) from doc
comments, we don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <> makes
zero sense to me.


Except the fact, that doc-comment content don't have to conform to
any rules, and you have to parse it and extract the necessary part
of meta information every time you need it. It's not a big problem
to do this using Doctrine library, but how are you going to do
this in a compiler hook?




Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov > wrote:



On 05/11/2016 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

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

You're not really suggesting that I write my tools in user
land, are you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed,
and I can't vote to reflect that.

As discussed in private, what I want is attributes, as
originally proposed, and a hookable compiler; Anything else
is not good enough.


Personally, I'm for AST as well, but it's possible to get the
same power translating string values of attributes into AST
in the hooks.

Thanks. Dmitry.




Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov
> wrote:

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 

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

[Benjamin Eberlei]

On Wed, May 11, 2016 at 10:42 AM, Joe Watkins  wrote:

> Dmitry,
>
> > Except the fact, that doc-comment content don't have to conform to any
> rules
>
> Nor does an attributes value that is just a string, that isn't validated by
> compiler ... it doesn't *have* to conform to any rules.
>
> That's exactly what people are voting for though, that seems to be what
> people want :s
>
> I desperately do not want that. I don't see the remarkable difference
> (although there is obviously difference) between attributes that are just
> strings or constant values and doc comments.
>
> > and you have to parse it and extract the necessary part of meta
> information every time you need it.
>
> You know that's not really true, there are already hooks and mechanisms to
> "compile" strings in doc comments, I used them literally yesterday ...
>
> I used them in anticipation that we would get a superior solution some time
> soon ... it now looks like we will not :(
>
> I don't want to invent ways to parse code, or extract it from anywhere ...
> we have a whole engine, an entire folder of code dedicated to that, it is
> nonsensical not to utilize it.
>

Yes agree. I have to admit not to have read the RFC with my full attention
before, i would have spotted this otherwise.
I would really love to have attributes being arbitrarily nested arrays in
addition to just a list of strings and have the PHP parser
recognize, parse and validate that its correct.

<>
getAttributes() returns ["ORM\Entity" => "User"]

^ This is a very simple example from the RFC, but next to the very complex
Drupal example, there are rather "lightweight"
usages that make up the majority of Annotations in Docblocks right now. I
would like to see:

< "MyApp\UserRepository", "table" =>
"users")>>
getAttributes() returns ["ORM\Entity" => ["repositoryClass" =>
"MyApp\UserRepository", "table" => "users"]]

The example from Drupal parsing the AST Nodes in the RFC nodes is extremely
complex code and would lead again to hundrets of slightly different
implementations
and no standardization around them. Essentially re-implementing the PHP
Parser in PHP on top of ast\nodes is not really what 80% of the users need
here, which is
arbitrary metadata (east way to represented in PHP as array).


>
> Cheers
> Joe
>
>
>
> On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov  wrote:
>
> >
> >
> > On 05/11/2016 09:57 AM, Joe Watkins wrote:
> >
> > Dmitry,
> >
> > > but it's possible to get the same power translating string values of
> > attributes into AST in the hooks.
> >
> > Aware.
> >
> > Enough of the complexity is already the responsibility of the consumer of
> > the attributes.
> >
> > It's already possible to get strings (and so AST) from doc comments, we
> > don't need anything new if that's all you want to do.
> >
> > Essentially, moving something from doc comments to <> makes zero
> > sense to me.
> >
> >
> > Except the fact, that doc-comment content don't have to conform to any
> > rules, and you have to parse it and extract the necessary part of meta
> > information every time you need it. It's not a big problem to do this
> using
> > Doctrine library, but how are you going to do this in a compiler hook?
> >
> >
> >
> > Cheers
> > Joe
> >
> > On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov  wrote:
> >
> >>
> >>
> >> On 05/11/2016 09:02 AM, Joe Watkins wrote:
> >>
> >> Morning Dmitry,
> >>
> >> > On the other hand simple string may be parsed into AST with just one
> >> additional call to ast\compile_string().
> >>
> >> You're not really suggesting that I write my tools in user land, are you
> >> ? It's me, Joe :)ce
> >>
> >>
> >> At first days of RFC discussion Sara pointed on over-design regarding
> AST.
> >> I saw sense in here comments and updated RFC.
> >>
> >>
> >> I *only* want attributes as they were originally proposed, and I can't
> >> vote to reflect that.
> >>
> >> As discussed in private, what I want is attributes, as originally
> >> proposed, and a hookable compiler; Anything else is not good enough.
> >>
> >>
> >> Personally, I'm for AST as well, but it's possible to get the same power
> >> translating string values of attributes into AST in the hooks.
> >>
> >> Thanks. Dmitry.
> >>
> >>
> >>
> >> Cheers
> >> Joe
> >>
> >>
> >>
> >> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < 
> >> dmi...@zend.com> wrote:
> >>
> >>> 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
> >>> 

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

[Arvids Godjuks]

Hi Yasuo!

2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki :

> Hi Arvids,
>
> On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
>  wrote:
> > i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on
> by
> > default and having any INI settings that affect how engine processes
> data in
> > runtime.
> > People just don't learn until they shotgun themselves I guess.
>
> Override them if you don't like admins to set INI values. I've
> modified session_start() so that it can set INI values as function
> parameter.
> http://php.net/session_start


Admins can just forbid to change any settings. And there is an ini setting
"disable_functions" and alike. They will setup up session auto start and
forbid usage of the session_start. And force the CSRF. Been in similar
situations, done that, never want to deal with it again.
I'm not even talking about the fact, that I may have reasons to use a
different hashing algorithm in the first place.
Dealing with JS side, when you need to pass the CSRF token there is next
can of worms.
And then you get to the part, where you need to use a distributed session
management, that has it's own can of worms. And forcing CSRF handling into
the session module probably is going to make it hard to deal with it at all.

So no, sessions are sessions, they should have only one thing to be
responsible for - storing data. Nothing else. It's a module that already
has a lot of issues. What you are proposing, is to do what APC did - mixing
code opcache with shared memory storage. We all know how it ended.


>
>
> > What I personally would be for, is a CSRF aPI module that comes as
> default,
> > like the Password API one, that gives ability to generate good quality
> CSRF
> > tokens and manage it.
>
> Imagine number of CSRF vulnerabilities in PHP apps. It's countless.
>
> Letting users to choose right way is not an good options. It is
> proven. I've added session.use_strict_mode (disallows permanent
> session hijack, etc) many years ago, but fair number of users aren't
> enabling this option. I suspect most majority of users aren't enabled
> it. Even if we provide solution, it's hard to be adopted. If there is
> no solution, outcome is easy to imagine. IMHO.
>
> Users had access to good PRNG. Even if mt_rand() is used, it is hard
> enough for attackers to guess, yet there are countless CSRF
> vulnerabilities. What's the reason to ignore the fact, huge number of
> CSRF vulnerabilities exist in PHP apps?
>
> I cannot understand rationale behind you and others think it should be
> users task completely...
>

If user does not want to use CSRF, you can't force him. And realisticly
speaking, how are you going to force the tokents on the GET urls? Rewrite
them. In JSON? In XML? etc? C'mon, these days url's there are single page
apps with their own routing and stuff and you will never get a CSRF token
in any automated maner there. It needs to be done by developer of the app.


>
> Anyway, I fails to see the reason why PHP should not invalidate CSRF
> attacks against POST requests with 2 simple parameter or INI...
>

Because they may be out of your control and just forced on you by a 3rd
party. Not to mention that 3rd party libraries will do stuff that will not
take into account this setting or do some hack, and that will negate any
security.


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

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

[Joe Watkins]

Dmitry,

> Except the fact, that doc-comment content don't have to conform to any
rules

Nor does an attributes value that is just a string, that isn't validated by
compiler ... it doesn't *have* to conform to any rules.

That's exactly what people are voting for though, that seems to be what
people want :s

I desperately do not want that. I don't see the remarkable difference
(although there is obviously difference) between attributes that are just
strings or constant values and doc comments.

> and you have to parse it and extract the necessary part of meta
information every time you need it.

You know that's not really true, there are already hooks and mechanisms to
"compile" strings in doc comments, I used them literally yesterday ...

I used them in anticipation that we would get a superior solution some time
soon ... it now looks like we will not :(

I don't want to invent ways to parse code, or extract it from anywhere ...
we have a whole engine, an entire folder of code dedicated to that, it is
nonsensical not to utilize it.

Cheers
Joe



On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov  wrote:

>
>
> On 05/11/2016 09:57 AM, Joe Watkins wrote:
>
> Dmitry,
>
> > but it's possible to get the same power translating string values of
> attributes into AST in the hooks.
>
> Aware.
>
> Enough of the complexity is already the responsibility of the consumer of
> the attributes.
>
> It's already possible to get strings (and so AST) from doc comments, we
> don't need anything new if that's all you want to do.
>
> Essentially, moving something from doc comments to <> makes zero
> sense to me.
>
>
> Except the fact, that doc-comment content don't have to conform to any
> rules, and you have to parse it and extract the necessary part of meta
> information every time you need it. It's not a big problem to do this using
> Doctrine library, but how are you going to do this in a compiler hook?
>
>
>
> Cheers
> Joe
>
> On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov  wrote:
>
>>
>>
>> On 05/11/2016 09:02 AM, Joe Watkins wrote:
>>
>> Morning Dmitry,
>>
>> > On the other hand simple string may be parsed into AST with just one
>> additional call to ast\compile_string().
>>
>> You're not really suggesting that I write my tools in user land, are you
>> ? It's me, Joe :)ce
>>
>>
>> At first days of RFC discussion Sara pointed on over-design regarding AST.
>> I saw sense in here comments and updated RFC.
>>
>>
>> I *only* want attributes as they were originally proposed, and I can't
>> vote to reflect that.
>>
>> As discussed in private, what I want is attributes, as originally
>> proposed, and a hookable compiler; Anything else is not good enough.
>>
>>
>> Personally, I'm for AST as well, but it's possible to get the same power
>> translating string values of attributes into AST in the hooks.
>>
>> Thanks. Dmitry.
>>
>>
>>
>> Cheers
>> Joe
>>
>>
>>
>> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < 
>> dmi...@zend.com> wrote:
>>
>>> 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 <
>>> bjorn.x.lars...@telia.com> 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 

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

[Yasuo Ohgaki]

Hi,

Sorry for scattered mails.

On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki  wrote:
>> What I personally would be for, is a CSRF aPI module that comes as default,
>> like the Password API one, that gives ability to generate good quality CSRF
>> tokens and manage it.

Token generation is automatic, but this RFC supports fully manual CSRF
validation, too. The RFC page only has semi manual example only. I'll
add a example for this.

Anyway, I fails to see the reason why PHP should not invalidate CSRF
attacks against POST requests with 2 simple parameter or INI...

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 all,

On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki  wrote:
> On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
>  wrote:
>> i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by
>> default and having any INI settings that affect how engine processes data in
>> runtime.
>> People just don't learn until they shotgun themselves I guess.
>
> Override them if you don't like admins to set INI values. I've
> modified session_start() so that it can set INI values as function
> parameter.
> http://php.net/session_start
>
>> What I personally would be for, is a CSRF aPI module that comes as default,
>> like the Password API one, that gives ability to generate good quality CSRF
>> tokens and manage it.
>
> Imagine number of CSRF vulnerabilities in PHP apps. It's countless.
>
> Letting users to choose right way is not an good options. It is
> proven. I've added session.use_strict_mode (disallows permanent
> session hijack, etc) many years ago, but fair number of users aren't
> enabling this option. I suspect most majority of users aren't enabled
> it. Even if we provide solution, it's hard to be adopted. If there is
> no solution, outcome is easy to imagine. IMHO.
>
> Users had access to good PRNG. Even if mt_rand() is used, it is hard
> enough for attackers to guess, yet there are countless CSRF
> vulnerabilities. What's the reason to ignore the fact, huge number of
> CSRF vulnerabilities exist in PHP apps?
>
> I cannot understand rationale behind you and others think it should be
> users task completely...

BTW, I'm not asking PHP developers to implement this feature, but I'm
willing to implement/maintain the feature.

Why

SESSION_CSRF_POST,
'csrf_validate'=>SESSION_CSRF_POST]);
?>

and protect CSRF attacks against POST requests are bad for PHP and its users?

Thanks.

--
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 Arvids,

On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
 wrote:
> i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by
> default and having any INI settings that affect how engine processes data in
> runtime.
> People just don't learn until they shotgun themselves I guess.

Override them if you don't like admins to set INI values. I've
modified session_start() so that it can set INI values as function
parameter.
http://php.net/session_start

> What I personally would be for, is a CSRF aPI module that comes as default,
> like the Password API one, that gives ability to generate good quality CSRF
> tokens and manage it.

Imagine number of CSRF vulnerabilities in PHP apps. It's countless.

Letting users to choose right way is not an good options. It is
proven. I've added session.use_strict_mode (disallows permanent
session hijack, etc) many years ago, but fair number of users aren't
enabling this option. I suspect most majority of users aren't enabled
it. Even if we provide solution, it's hard to be adopted. If there is
no solution, outcome is easy to imagine. IMHO.

Users had access to good PRNG. Even if mt_rand() is used, it is hard
enough for attackers to guess, yet there are countless CSRF
vulnerabilities. What's the reason to ignore the fact, huge number of
CSRF vulnerabilities exist in PHP apps?

I cannot understand rationale behind you and others think it should be
users task completely...

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 10:27 AM, Stanislav Malyshev wrote:

Hi!


Personally, I'm for AST as well, but it's possible to get the same power
translating string values of attributes into AST in the hooks.

Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.
In general yes, but we don't have grammar for doc-comments, and even 
extracting general string value may be not trivial.


/**
 * Adds two positive numbers
 *
 * @ensures $x + $y >=
 *  0
 * // support for multi-line attribute values?
 * @on_enter @enter_function(__FUNCTION__);
 * '@' sign before enter_function() is a silence operator.
 */
function add($x, $y) {
return $x + $y;
}


--
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 1:54 PM, "Yasuo Ohgaki"  wrote:
>
> Hi Pierre,
>
> On Wed, May 11, 2016 at 2:19 PM, Pierre Joye  wrote:
> > 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.
>
> Session, authenticity, authentication cannot divide into independent
> parts, but they are dependent by its nature. Whether we like it or
> not, session is a part of authenticity/authentication. (I'm not going
> to add authentication feature. Session's task is to store
> authentication "flag", but I think authenticity is part of session)
> Current session module provide authenticity partially and it could
> provide good authenticity check with relatively simple change. This is
> what I would like to change by this RFC.
>
> I fully agree that implementations of proper session, authenticity,
> authentication are hard. They are not simple tasks and could be
> implemented badly like many applications in the wild.

We have very good userland csrf implementation provided for almost all
leading tools out there. I think this is where it should stay, userland.

> If these tasks
> are easy and almost all developers/applications do them correctly, I
> would not bother. Unfortunately, it's not. PHP has to be provided
> basic utility to web developers for the task. IMO.

Fixing education issues by adding upcoming magic quotes like feature is not
very appealing to me. Csrf is not a bad thing as mq were but the idea
described in this rfc is leading us in a very similar direction.

> PHP is made for easy web application development. This RFC could
> provide easy, yet good enough, CSRF protection when only POST is used.
> It's just a matter of

Never been as simple for the cases I had. I see it as a rather simplistic
case used as a generic implementation system or site wise.

Csrf may need session like many other things.  It does not mean it should
be part of the session extension but use it if necessary.

>
> What is good about this RFC is applications that use only POST for
> data modifications could be protected w/o single line of code
> modification. And most importantly, it's easy to implement this :)
> So I don't see reasons let it developers burden.

About microservices. Totally agree. The session module should care about
session management and nothing else. And for this part only, except what
has landed in recently I have a strong feeling that it is band aiding
things instead of having something modern apps could use. In short, let
stop the band aid fixes and do something better to begin with, for each
"service". Userland (already there for most) and core (outside to begin
with).

Adding so many ini settings and unrelated features won't help here, in
countrary.  It will make even harder to replace it when we are so far (if
it happens ;).

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

[Arvids Godjuks]

Hi internals,

i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by
default and having any INI settings that affect how engine processes data
in runtime.
People just don't learn until they shotgun themselves I guess.

What I personally would be for, is a CSRF aPI module that comes as default,
like the Password API one, that gives ability to generate good quality CSRF
tokens and manage it.

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

[Stanislav Malyshev]

Hi!

> Personally, I'm for AST as well, but it's possible to get the same power
> translating string values of attributes into AST in the hooks.

Extending this, it's also possible to get the same power just extracting
phpdocs and applying AST to them.
-- 
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] [VOTE] PHP Attributes

[Dmitry Stogov]

On 05/11/2016 09:57 AM, Joe Watkins wrote:

Dmitry,

> but it's possible to get the same power translating string values of 
attributes into AST in the hooks.


Aware.

Enough of the complexity is already the responsibility of the consumer 
of the attributes.


It's already possible to get strings (and so AST) from doc comments, 
we don't need anything new if that's all you want to do.


Essentially, moving something from doc comments to <> makes zero 
sense to me.


Except the fact, that doc-comment content don't have to conform to any 
rules, and you have to parse it and extract the necessary part of meta 
information every time you need it. It's not a big problem to do this 
using Doctrine library, but how are you going to do this in a compiler hook?




Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov > wrote:




On 05/11/2016 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

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

You're not really suggesting that I write my tools in user land,
are you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design
regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed, and I
can't vote to reflect that.

As discussed in private, what I want is attributes, as originally
proposed, and a hookable compiler; Anything else is not good enough.


Personally, I'm for AST as well, but it's possible to get the same
power translating string values of attributes into AST in the hooks.

Thanks. Dmitry.




Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov > wrote:

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] [VOTE] PHP Attributes

[Joe Watkins]

Dmitry,

> but it's possible to get the same power translating string values of
attributes into AST in the hooks.

Aware.

Enough of the complexity is already the responsibility of the consumer of
the attributes.

It's already possible to get strings (and so AST) from doc comments, we
don't need anything new if that's all you want to do.

Essentially, moving something from doc comments to <> makes zero
sense to me.

Cheers
Joe

On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov  wrote:

>
>
> On 05/11/2016 09:02 AM, Joe Watkins wrote:
>
> Morning Dmitry,
>
> > On the other hand simple string may be parsed into AST with just one
> additional call to ast\compile_string().
>
> You're not really suggesting that I write my tools in user land, are you ?
> It's me, Joe :)ce
>
>
> At first days of RFC discussion Sara pointed on over-design regarding AST.
> I saw sense in here comments and updated RFC.
>
>
> I *only* want attributes as they were originally proposed, and I can't
> vote to reflect that.
>
> As discussed in private, what I want is attributes, as originally
> proposed, and a hookable compiler; Anything else is not good enough.
>
>
> Personally, I'm for AST as well, but it's possible to get the same power
> translating string values of attributes into AST in the hooks.
>
> Thanks. Dmitry.
>
>
>
> Cheers
> Joe
>
>
>
> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov  wrote:
>
>> 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 <
>> bjorn.x.lars...@telia.com> 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 2:19 PM, Pierre Joye  wrote:
> 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.

Session, authenticity, authentication cannot divide into independent
parts, but they are dependent by its nature. Whether we like it or
not, session is a part of authenticity/authentication. (I'm not going
to add authentication feature. Session's task is to store
authentication "flag", but I think authenticity is part of session)
Current session module provide authenticity partially and it could
provide good authenticity check with relatively simple change. This is
what I would like to change by this RFC.

I fully agree that implementations of proper session, authenticity,
authentication are hard. They are not simple tasks and could be
implemented badly like many applications in the wild. If these tasks
are easy and almost all developers/applications do them correctly, I
would not bother. Unfortunately, it's not. PHP has to be provided
basic utility to web developers for the task. IMO.

PHP is made for easy web application development. This RFC could
provide easy, yet good enough, CSRF protection when only POST is used.
It's just a matter of

SESSION_CSRF_POST,
  'csrf_validate'=>SESSION_CSRF_POST]);
// Do something useful w/o caring CSRF if data modification is
// done by POST only.
?>

We are in micro service era. Full featured frameworks should not be
required for simple request/response applications. It should be
something like

SESSION_CSRF_POST,
  'csrf_validate'=>SESSION_CSRF_POST]);

// Do something useful w/o caring CSRF if data modification is
// done by POST only.
check_authentication_and_authorization_if_not_redirect_to_appropriate_page_and_exit();
output_json_response(do_some_usuful_data_update_by($_POST));
?>

This is simple, fast and maintainable. There are many simple data
retrieval/modification APIs now. This is what I would like to achieve.

What is good about this RFC is applications that use only POST for
data modifications could be protected w/o single line of code
modification. And most importantly, it's easy to implement this :)
So I don't see reasons let it developers burden.

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 09:02 AM, Joe Watkins wrote:

Morning Dmitry,

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


You're not really suggesting that I write my tools in user land, are 
you ? It's me, Joe :)ce


At first days of RFC discussion Sara pointed on over-design regarding AST.
I saw sense in here comments and updated RFC.



I *only* want attributes as they were originally proposed, and I can't 
vote to reflect that.


As discussed in private, what I want is attributes, as originally 
proposed, and a hookable compiler; Anything else is not good enough.


Personally, I'm for AST as well, but it's possible to get the same power 
translating string values of attributes into AST in the hooks.


Thanks. Dmitry.



Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov > wrote:


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

[Niklas Keller]

2016-05-11 6:50 GMT+02:00 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.
>

It is, because it will be leaked to other sites without having special
headers. Older browsers not supporting those headers will still expose
those tokens in referer headers.

APIs are a different topic. They're not visited by the user directly, so
the URL is never exposed to other sites (may they be via clicked links or
embedded images).


> So I didn't ignore GET usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

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

[Christian Stoller]

> -Ursprüngliche Nachricht-
> Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. 
> Mai 2016 15:23
>
> Please read and comment :
>
> https://wiki.php.net/rfc/load-ext-by-name
>
> Regards
> 
> François
>

Why not just naming them *.so on all platforms and removing the "php_" prefix 
on Windows?

Apache modules on Windows also have the .so suffix.

Best regards
Christian

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

[Joe Watkins]

Morning,

Because you have confused the vote by adding additional options very
late in the discussion, and because the majority are in favour of something
I think is harmful; I've had to vote no, on a feature that I want :s

Cheers
Joe

On Wed, May 11, 2016 at 7:02 AM, Joe Watkins  wrote:

> Morning Dmitry,
>
> > On the other hand simple string may be parsed into AST with just one
> additional call to ast\compile_string().
>
> You're not really suggesting that I write my tools in user land, are you ?
> It's me, Joe :)
>
> I *only* want attributes as they were originally proposed, and I can't
> vote to reflect that.
>
> As discussed in private, what I want is attributes, as originally
> proposed, and a hookable compiler; Anything else is not good enough.
>
> Cheers
> Joe
>
>
>
> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov  wrote:
>
>> 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 <
>> bjorn.x.lars...@telia.com> 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] [VOTE] PHP Attributes

[Joe Watkins]

Morning Dmitry,

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

You're not really suggesting that I write my tools in user land, are you ?
It's me, Joe :)

I *only* want attributes as they were originally proposed, and I can't vote
to reflect that.

As discussed in private, what I want is attributes, as originally proposed,
and a hookable compiler; Anything else is not good enough.

Cheers
Joe



On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov  wrote:

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