[RFC DRAFT] Automatic CSRF Protection

Stas Malyshev

10 years ago

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 rewrite? What happens with applications that do not
produce HTML at all, such as REST, or those that produce data further
modified by Javascript frontend?

--
Stas Malyshev
smalyshev@gmail.com

Yasuo Ohgaki

10 years ago

Hi Stas,

On Tue, May 10, 2016 at 1:44 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

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

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

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

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

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

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

Thank you for clarification!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

10 years ago

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
smalyshev@gmail.com

Yasuo Ohgaki

10 years ago

Hi Stas,

On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:

>> What happens with applications that do not produce HTML at all, such as REST,
>>  - These apps may add SESSCSRF value manually.
>
> Add where? And where that value would come from? RFC says nothing about
> that.

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

10 years ago

Hi!

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

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

--
Stas Malyshev
smalyshev@gmail.com

Yasuo Ohgaki

10 years ago

Hi Stas,

On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Niklas Keller

10 years ago

Yasuo Ohgaki <yohgaki@ohgaki.net> schrieb am Mi., 11. Mai 2016 03:11:

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

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

If users have their implementation PUT/etc, they may validate CSRF

Yasuo Ohgaki

10 years ago

Hi Stas,

On Wed, May 11, 2016 at 7:58 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

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

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Kinn Julião

10 years ago

> 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 <yohgaki@ohgaki.net> wrote:

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

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

Yasuo Ohgaki

10 years ago

Hi Kinn,

On Wed, May 11, 2016 at 10:20 AM, Kinn Julião <kinncj@gmail.com> wrote:

>> JS code that does not have pages at all may obtain CSRF token manually.
>
> That's against CSRF protection... in fact, a remote app can obtain the token
> also and make the cross site request forgery...
>
> -1

You seem to __misunderstood__ behavior.

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Kinn Julião

10 years ago

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" <yohgaki@ohgaki.net> wrote:

Niklas Keller

10 years ago

Yasuo Ohgaki <yohgaki@ohgaki.net> schrieb am Mi., 11. Mai 2016 00:05:

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

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

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

Regards,

Yasuo Ohgaki

10 years ago

Hi Niklas,

On Wed, May 11, 2016 at 1:40 PM, Niklas Keller <me@kelunik.com> wrote:

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

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

So I didn't ignore GET usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Niklas Keller

10 years ago

2016-05-11 6:50 GMT+02:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Niklas,
>
> On Wed, May 11, 2016 at 1:40 PM, Niklas Keller <me@kelunik.com> wrote:
> > Yasuo Ohgaki <yohgaki@ohgaki.net> schrieb am Mi., 11. Mai 2016 00:05:
> >>
> >> Hi Stas,
> >>
> >> On Wed, May 11, 2016 at 12:32 AM, Stanislav Malyshev
> >> <smalyshev@gmail.com> 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).

Arvids Godjuks

10 years ago

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.

Yasuo Ohgaki

10 years ago

Hi Arvids,

On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks
<arvids.godjuks@gmail.com> 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
yohgaki@ohgaki.net

Rowan Collins

10 years ago

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

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

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

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

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

Regards,

--
Rowan Collins
[IMSoP]

Yasuo Ohgaki

10 years ago

Hi Rowan,

On Tue, May 10, 2016 at 6:38 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

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

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

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

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

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Niklas Keller

10 years ago

Yasuo Ohgaki <yohgaki@ohgaki.net> schrieb am Di., 10. Mai 2016 12:57:

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

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

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

- Add session_csrf_validate() for manual validation

Albert Casademont Filella

10 years ago

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

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

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

On Tue, May 10, 2016 at 2:44 PM, Niklas Keller <me@kelunik.com> wrote:

Rowan Collins

10 years ago

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

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

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

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

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

Regards,

--
Rowan Collins
[IMSoP]

Yasuo Ohgaki

10 years ago

Hi Rowan,

On Tue, May 10, 2016 at 9:36 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

10 years ago

Hi!

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

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

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

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

--
Stas Malyshev
smalyshev@gmail.com

Fleshgrinder

10 years ago

On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:

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

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

--
Richard "Fleshgrinder" Fussenegger

Chris Riley

10 years ago

On 10 May 2016 at 17:48, Fleshgrinder <php@fleshgrinder.com> wrote:

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

Sorry but this isn't something that the language should be concerning
itself with. It will cause more pain than it's worth (think magic quotes).

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

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

Yasuo Ohgaki

10 years ago

Hi,

On Wed, May 11, 2016 at 1:48 AM, Fleshgrinder <php@fleshgrinder.com> wrote:

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

10 years ago

Hi!

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

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

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

--
Stas Malyshev
smalyshev@gmail.com

Yasuo Ohgaki

10 years ago

Hi,

On Wed, May 11, 2016 at 7:06 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

10 years ago

Hi All,

On Tue, May 10, 2016 at 12:24 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

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

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Pierre Joye

10 years ago

Hi,

On May 10, 2016 10:25 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:

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

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

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

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

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

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

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

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

Yasuo Ohgaki

10 years ago

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye <pierre.php@gmail.com> wrote:

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

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

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Yasuo Ohgaki

10 years ago

Hi Pierre,

On Wed, May 11, 2016 at 1:12 PM, Pierre Joye <pierre.php@gmail.com> wrote:

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

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

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

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net