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 even if there are imp
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 half
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.
register_html_rewrit
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&APIs
> to match application needs. We
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 th
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
>> >
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
> use
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 th
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 hav
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
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
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
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/sessi
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
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
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 demonstrati
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. Y
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 - CO
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
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", an
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 hidd
> 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
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
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
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
> > ru
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 automati
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.
>> Peo
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.
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 sh
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 c
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 th
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 applicatio
Hi Pierre,
On Wed, May 11, 2016 at 1:12 PM, Pierre Joye wrote:
> The current session code and designs is old, very old. It does not match
> today ways to do things. Every time we fix it, I see a band aid fix.
Let's rewrite session module someday.
In the meantime, I would like to add features to
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, ot
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,
>> >>
On Wed, May 11, 2016 at 1:12 PM, Pierre Joye wrote:
> On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote:
>>
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch for
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
Hi Kinn,
On Wed, May 11, 2016 at 11:56 AM, Kinn Julião wrote:
> The point with your example is:
> The cross site can request the "get_csrf_token.php", store on its session
> (even curl can save the session id cookie or whatever), get the token and
> request the endpoint with the retrieved token a
Yasuo Ohgaki schrieb am Mi., 11. Mai 2016 03:11:
> Hi Stas,
>
> On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev
> wrote:
> >>> Add where? And where that value would come from? RFC says nothing about
> >>> that.
> >>
> >> As usual. Query parameter when GET is used. Additional input when POST
Hi,
On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote:
>
> Hi all,
>
> It's not nice to work on the same code (i.e. session module) for
> multiple RFCs, but time is limited.
>
> I would like to hear from ideas/comments before I write patch for this.
> https://wiki.php.net/rfc/automatic_csrf_protecti
The point with your example is:
The cross site can request the "get_csrf_token.php", store on its session
(even curl can save the session id cookie or whatever), get the token and
request the endpoint with the retrieved token and session id.
Got it?
On May 10, 2016 10:53 PM, "Kinn Julião" wrote:
You seemed to misunderstood your own "get_csrf_token.php" and how attackers
would benefit from that.
Anyway, you're trying to transfer an application behaviour to the core...
Stick to -1.
On May 10, 2016 10:18 PM, "Yasuo Ohgaki" wrote:
> Hi Kinn,
>
> On Wed, May 11, 2016 at 10:20 AM, Kinn Julião
Hi Kinn,
On Wed, May 11, 2016 at 10:20 AM, Kinn Julião wrote:
>> JS code that does not have pages at all may obtain CSRF token manually.
>
> That's against CSRF protection... in fact, a remote app can obtain the token
> also and make the cross site request forgery...
>
> -1
You seem to __misunde
> JS code that does not have pages at all may obtain CSRF token manually.
That's against CSRF protection... in fact, a remote app can obtain the
token also and make the cross site request forgery...
-1
On Tue, May 10, 2016 at 9:17 PM, Yasuo Ohgaki wrote:
> Hi Stas,
>
> On Wed, May 11, 2016 at
Hi Stas,
On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote:
>>> Add where? And where that value would come from? RFC says nothing about
>>> that.
>>
>> As usual. Query parameter when GET is used. Additional input when POST
>> is used. All users have to do is adding CSRF token to JS progra
Hi Stas,
On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev wrote:
>>> Add where? And where that value would come from? RFC says nothing about
>>> that.
>>
>> As usual. Query parameter when GET is used. Additional input when POST
>> is used. All users have to do is adding CSRF token to JS progra
Hi,
On Wed, May 11, 2016 at 7:06 AM, Yasuo Ohgaki wrote:
> On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote:
>> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
>>> Hi all,
>>>
>>> It's not nice to work on the same code (i.e. session module) for
>>> multiple RFCs, but time is limited.
>>>
>>> I woul
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 no
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 w
Hi,
On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder wrote:
> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch for thi
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. Qu
Hi Rowan,
On Tue, May 10, 2016 at 9:36 PM, Rowan Collins wrote:
> Yasuo Ohgaki wrote on 10/05/2016 11:57:
>>
>> To protect all of URLs automatically, all URLs need to have token.
>> That's the reason why all URLs have token.
>
>
> In my opinion, that fails on both counts: not all URLs need protec
On 10 May 2016 at 17:48, Fleshgrinder wrote:
> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > It's not nice to work on the same code (i.e. session module) for
> > multiple RFCs, but time is limited.
> >
> > I would like to hear from ideas/comments before I write patch for this.
> >
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
>
> Than
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 Ma
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, esp
Yasuo Ohgaki wrote on 10/05/2016 11:57:
To protect all of URLs automatically, all URLs need to have token.
That's the reason why all URLs have token.
In my opinion, that fails on both counts: not all URLs need protection
(I would say for most applications, the majority of URLs do not need
it)
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
Yasuo Ohgaki schrieb am Di., 10. Mai 2016 12:57:
> Hi Rowan,
>
> On Tue, May 10, 2016 at 6:38 PM, Rowan Collins
> wrote:
> > Yasuo Ohgaki wrote on 10/05/2016 04:24:
> >>
> >> Hi all,
> >>
> >> It's not nice to work on the same code (i.e. session module) for
> >> multiple RFCs, but time is limite
Hi Stas,
On Tue, May 10, 2016 at 1:44 PM, Stanislav Malyshev wrote:
>> I would like to hear from ideas/comments before I write patch for this.
>> https://wiki.php.net/rfc/automatic_csrf_protection
>
> Could you explain a bit more - when token validation happens? Where the
> SESSCSRF comes from? D
Hi Rowan,
On Tue, May 10, 2016 at 6:38 PM, Rowan Collins wrote:
> Yasuo Ohgaki wrote on 10/05/2016 04:24:
>>
>> Hi all,
>>
>> It's not nice to work on the same code (i.e. session module) for
>> multiple RFCs, but time is limited.
>>
>> I would like to hear from ideas/comments before I write patch
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 eve
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 rewr
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
64 matches
Mail list logo
