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

Hi Lester, On Thu, May 12, 2016 at 6:27 PM, Lester Caine wrote: > On 12/05/16 04:19, Yasuo Ohgaki wrote: >> 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

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

On 12/05/16 04:19, Yasuo Ohgaki wrote: > 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

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

On 11/05/2016 13:29, Rowan Collins wrote: 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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 -

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

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

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

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

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

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 >

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye wrote: > On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote: >> >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear

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

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

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

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

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

Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 03:11: > Hi Stas, > > On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev > wrote: > >>> Add where? And where that value would come from? RFC says nothing about > >>> that. > >> > >> As usual. Query parameter

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

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

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

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

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

You seemed to misunderstood your own "get_csrf_token.php" and how attackers would benefit from that. Anyway, you're trying to transfer an application behaviour to the core... Stick to -1. On May 10, 2016 10:18 PM, "Yasuo Ohgaki" wrote: > Hi Kinn, > > On Wed, May 11, 2016 at

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

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

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

> JS code that does not have pages at all may obtain CSRF token manually. That's against CSRF protection... in fact, a remote app can obtain the token also and make the cross site request forgery... -1 On Tue, May 10, 2016 at 9:17 PM, Yasuo Ohgaki wrote: > Hi Stas, > > On

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

Hi Stas, On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote: >>> Add where? And where that value would come from? RFC says nothing about >>> that. >> >> As usual. Query parameter when GET is used. Additional input when POST >> is used. All users have to do is adding

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

Hi Stas, On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote: >>> Add where? And where that value would come from? RFC says nothing about >>> that. >> >> As usual. Query parameter when GET is used. Additional input when POST >> is used. All users have to do is adding

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

Hi, On Wed, May 11, 2016 at 7:06 AM, Yasuo Ohgaki wrote: > On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote: >> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: >>> Hi all, >>> >>> It's not nice to work on the same code (i.e. session module) for >>>

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

Hi! > Did you read RFC? > It does not enable CSRF protection for all website, but only when it is > enabled. The RFC says: "Default: session.csrf_protection=1". Which means all sites would have it (for POST) unless they specifically disable it by changing configuration. Also, new variants do

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

Hi! >> Add where? And where that value would come from? RFC says nothing about >> that. > > As usual. Query parameter when GET is used. Additional input when POST > is used. All users have to do is adding CSRF token to JS program. GET and POST aren't the only HTTP methods. And where JS program

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

Hi, On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote: > On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear from ideas/comments

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

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

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

Hi Rowan, On Tue, May 10, 2016 at 9:36 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 10/05/2016 11:57: >> >> To protect all of URLs automatically, all URLs need to have token. >> That's the reason why all URLs have token. > > > In my opinion, that fails on both

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

On 10 May 2016 at 17:48, Fleshgrinder wrote: > On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote: > > Hi all, > > > > It's not nice to work on the same code (i.e. session module) for > > multiple RFCs, but time is limited. > > > > I would like to hear from ideas/comments before I

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

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

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

Hi! > What happens with applications that do not produce HTML at all, such as REST, > - These apps may add SESSCSRF value manually. Add where? And where that value would come from? RFC says nothing about that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development

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

Hi! > To protect all of URLs automatically, all URLs need to have token. > That's the reason why all URLs have token. The risk is the same as > Trans SID session management. But not all URLs need protecting. There are a lot of URLs that do not need protecting - and there are a lot of actions,

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

Yasuo Ohgaki wrote on 10/05/2016 11:57: To protect all of URLs automatically, all URLs need to have token. That's the reason why all URLs have token. In my opinion, that fails on both counts: not all URLs need protection (I would say for most applications, the majority of URLs do not need

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

Why use sessions for CSRF Protection? That an be implemented with simple cookies. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Double_Submit_Cookies Btw, not sure if this should be in php core though...it's more an application thing... On Tue, May

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

Yasuo Ohgaki schrieb am Di., 10. Mai 2016 12:57: > Hi Rowan, > > On Tue, May 10, 2016 at 6:38 PM, Rowan Collins > wrote: > > Yasuo Ohgaki wrote on 10/05/2016 04:24: > >> > >> Hi all, > >> > >> It's not nice to work on the same code (i.e. session

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

Hi Stas, On Tue, May 10, 2016 at 1:44 PM, Stanislav Malyshev wrote: >> I would like to hear from ideas/comments before I write patch for this. >> https://wiki.php.net/rfc/automatic_csrf_protection > > Could you explain a bit more - when token validation happens? Where the >

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

Hi Rowan, On Tue, May 10, 2016 at 6:38 PM, Rowan Collins wrote: > Yasuo Ohgaki wrote on 10/05/2016 04:24: >> >> Hi all, >> >> It's not nice to work on the same code (i.e. session module) for >> multiple RFCs, but time is limited. >> >> I would like to hear from

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

Yasuo Ohgaki wrote on 10/05/2016 04:24: Hi all, It's not nice to work on the same code (i.e. session module) for multiple RFCs, but time is limited. I would like to hear from ideas/comments before I write patch for this. https://wiki.php.net/rfc/automatic_csrf_protection I think rewriting

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

Hi! > I would like to hear from ideas/comments before I write patch for this. > https://wiki.php.net/rfc/automatic_csrf_protection Could you explain a bit more - when token validation happens? Where the SESSCSRF comes from? Does this mean that every session application now has to support URL

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

Hi all, It's not nice to work on the same code (i.e. session module) for multiple RFCs, but time is limited. I would like to hear from ideas/comments before I write patch for this. https://wiki.php.net/rfc/automatic_csrf_protection Thank you for your comments. Regards, P.S. Precise session ID