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.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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
Hi Stas,
I would like to hear from ideas/comments before I write patch for this.
https://wiki.php.net/rfc/automatic_csrf_protectionCould 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
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
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
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
Hi Stas,
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
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
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
Hi Stas,
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
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
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 Coelho Julião
Toronto - ON/Canada
Hi Kinn,
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
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.
Hi Kinn,
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
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?
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.Hi Kinn,
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
Hi Kinn,
The point with your example is:
The cross site can request the "get_csrf_token.php", store on its session
(even curl can save the session id cookie or whatever), get the token and
request the endpoint with the retrieved token and session id.Got it?
Wrong assumption.
How would you set attacker's session ID to victim?
BTW, session hijack/adoption is not scope of this RFC, but precise
session management RFC.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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
yohgaki@ohgaki.net
Hi Niklas,
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
2016-05-11 6:50 GMT+02:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi Niklas,
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).
So I didn't ignore GET usage.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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.
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
Hi all,
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
modifiedsession_start()so that it can set INI values as function
parameter.
http://php.net/session_startWhat 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
<?php
session_start(['csrf_rewrite'=>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
yohgaki@ohgaki.net
Why
<?php
session_start(['csrf_rewrite'=>SESSION_CSRF_POST,
'csrf_validate'=>SESSION_CSRF_POST]);
?>and protect CSRF attacks against POST requests are bad for PHP and its users?
-
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. -
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. -
Because it complicates the session code with extra responsibilities,
rather than concentrating on safely persisting arbitrary state data. -
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]
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
);
I realised I over-complicated this, all you need is:
ob_add_rewrite_param(array $fields, int $flags)
ob_add_rewrite_param( [ 'csrf_token' => MyFramework\CSRF::getToken() ],
REWRITE_POST_FORMS | REWRITE_URL_LINKS );
That said, this - and the CSRF mechanism as currently proposed - rely
heavily on the quality of that output rewriting engine. I've never used
it, so have no idea how well it actually works with a modern application.
Regards,
Rowan Collins
[IMSoP]
Hi,
Sorry for scattered mails.
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
yohgaki@ohgaki.net
Hi Yasuo!
2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki yohgaki@ohgaki.net:
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
modifiedsession_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
yohgaki@ohgaki.net
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.
Hi Yasuo!
2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki yohgaki@ohgaki.net:
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
modifiedsession_start()so that it can set INI values as function
parameter.
http://php.net/session_startAdmins 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
yohgaki@ohgaki.net
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 <img> 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]
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.
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 <img> 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]
And again, I'm bashing against/based in his poor example for asynchronous
requests...
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.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 <img> 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]
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 http://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:
<img 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:
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]
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 rowan.collins@gmail.com
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 http://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:<img 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
<img src="http://victim.example.com/generate_csrf_token.php">;
generates a new CSRF token, as in Yasuo's example, the attacker could of
course write this: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_VulnerabilitiesRegards,
Rowan Collins
[IMSoP]
--
--
Kinn Coelho Julião
Toronto - ON/Canada
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 <img> 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]
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.
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
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.
2016-05-11 17:41 GMT+02:00 Andrey Andreev narf@devilix.net:
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.
2016-05-11 17:41 GMT+02:00 Andrey Andreev narf@devilix.net:
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.
Post from tablet seems to have gone missing ...
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
Hi Andrey,
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
yohgaki@ohgaki.net
Hi,
Hi Andrey,
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.
Hi Andrey,
Hi Andrey,
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 ... vIf 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.
Callingsession_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
yohgaki@ohgaki.net
Hi Kinn,
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
yohgaki@ohgaki.net
Hi Arvids,
On Wed, May 11, 2016 at 5:54 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:
2016-05-11 11:05 GMT+03:00 Yasuo Ohgaki yohgaki@ohgaki.net:
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
modifiedsession_start()so that it can set INI values as function
parameter.
http://php.net/session_startAdmins 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
yohgaki@ohgaki.net
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:
- 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.
- 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&APIs
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
Hi Pierre,
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 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
yohgaki@ohgaki.net
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 :)
Yasuo ... THIS is the situation with a number of elements of PHP, and I
DO understand where you are coming from. PHP is nicely modular and so
creating a complete module ... well documented ... clean API ... makes
perfect sense. Getting acceptance may be a different matter, such as
switching from mysql to mysqli, but it does provide a document-able
upgrade path for the problem in hand.
I'm the first to admit I rely on the simple options so still use
anonymous session for the majority of users simply because they are
never going to log in, while I conciser and authenticated user as a
different animal so needs a different type of security. That is the main
reason I posted the 'off topic' bits earlier in this thread. It IS a
matter of what is the ideal set-up for the vast majority of PHP users
who can justify laying out lots of money for the best chargeable
security, and there is now at least a path that can be documented to
help them which includes https, sessions and authentication?
--
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
Hi Lester,
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 :)Yasuo ... THIS is the situation with a number of elements of PHP, and I
DO understand where you are coming from. PHP is nicely modular and so
creating a complete module ... well documented ... clean API ... makes
perfect sense. Getting acceptance may be a different matter, such as
switching from mysql to mysqli, but it does provide a document-able
upgrade path for the problem in hand.I'm the first to admit I rely on the simple options so still use
anonymous session for the majority of users simply because they are
never going to log in, while I conciser and authenticated user as a
different animal so needs a different type of security. That is the main
reason I posted the 'off topic' bits earlier in this thread. It IS a
matter of what is the ideal set-up for the vast majority of PHP users
who can justify laying out lots of money for the best chargeable
security, and there is now at least a path that can be documented to
help them which includes https, sessions and authentication?
I was half serious and willing to maintain/improve session module,
security related area especially.
Anyway, session module should be like RDBMS, not NoSQL. I don't want
to care about locks, race conditions, synchronization,
vulnerabilities, etc. It should just work out of the box with
reasonable default behavior. IMO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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]
Hi Rowan,
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_protectionI 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
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_protectionI think rewriting every URL, and erroring if the token on a URL has
expired,
will not be useful for most people. What happens if I copy the URL of a
page
into an e-mail or Twitter post? As soon as anybody clicks that link,
they're
going to get an error raised; maybe it will recover by clearing their
session, causing them to log out unnecessarily; maybe it will refuse to
show
the content claiming they're not authenticated. In the worst case,
someone
might take my URL and use the CSRF token against me - they have a time
limit, but if the application author relied on this protection, the same
token will be valid for any action on the site.To protect all of URLs automatically, all URLs need to have token.
That's the reason why all URLs have token. The risk is the same as
Trans SID session management.As described, the feature seems to assume that all pages are potential
CSRF
targets, when even an authenticated user on a forum spends most of their
time on URLs which retrieve data and have no side effects. As Stas
pointed
out, not all content is amenable to rewriting, either, which could lead
to a
false sense of security - dare I compare the infamous magic quotes? A
good
implementation of CSRF protection has to consider when to generate a
token,
when to check it, and what to do on failure - trying to submit a comment
with an invalid CSRF token might re-display the comment form with
pre-filled
content, for instance - and this proposal doesn't seem to address that.I think this is the kind of feature that can only really be addressed by
an
application framework, which can have greater knowledge of when actions
are
being triggered, link tokens to specific actions, and so on.Because of likelihood of the vulnerability, it's better provide basic
infrastructure. IMO. It's possible to give more control to users.
- Specify protected method GET/POST or both.
GET should never require automatic CSRF protection. If you need this,
you're doing something fundamentally wrong.
The only exception are things like OAuth, but these have to be handled
manually anyway.
- Add session_csrf_validate() for manual validation
Implementation is simple enough even with these addition. (Added to RFC)
I considered to protect whole application while I was writing this RFC
draft. Thank you for point this out!Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Why use sessions for CSRF Protection? That an be implemented with simple
cookies.
Btw, not sure if this should be in php core though...it's more an
application thing...
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_protectionI think rewriting every URL, and erroring if the token on a URL has
expired,
will not be useful for most people. What happens if I copy the URL of a
page
into an e-mail or Twitter post? As soon as anybody clicks that link,
they're
going to get an error raised; maybe it will recover by clearing their
session, causing them to log out unnecessarily; maybe it will refuse to
show
the content claiming they're not authenticated. In the worst case,
someone
might take my URL and use the CSRF token against me - they have a time
limit, but if the application author relied on this protection, the
same
token will be valid for any action on the site.To protect all of URLs automatically, all URLs need to have token.
That's the reason why all URLs have token. The risk is the same as
Trans SID session management.As described, the feature seems to assume that all pages are potential
CSRF
targets, when even an authenticated user on a forum spends most of
their
time on URLs which retrieve data and have no side effects. As Stas
pointed
out, not all content is amenable to rewriting, either, which could lead
to a
false sense of security - dare I compare the infamous magic quotes? A
good
implementation of CSRF protection has to consider when to generate a
token,
when to check it, and what to do on failure - trying to submit a
comment
with an invalid CSRF token might re-display the comment form with
pre-filled
content, for instance - and this proposal doesn't seem to address that.I think this is the kind of feature that can only really be addressed
by
an
application framework, which can have greater knowledge of when actions
are
being triggered, link tokens to specific actions, and so on.Because of likelihood of the vulnerability, it's better provide basic
infrastructure. IMO. It's possible to give more control to users.
- Specify protected method GET/POST or both.
GET should never require automatic CSRF protection. If you need this,
you're doing something fundamentally wrong.The only exception are things like OAuth, but these have to be handled
manually anyway.
- Add session_csrf_validate() for manual validation
Implementation is simple enough even with these addition. (Added to RFC)
I considered to protect whole application while I was writing this RFC
draft. Thank you for point this out!Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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]
Hi Rowan,
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
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
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_protectionThank 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
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_protectionThank 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.
Hi,
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_protectionThank 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
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
Hi,
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_protectionThank 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 requiredDid 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
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_protectionThank 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
Hi,
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_protectionThank you for your comments.
I will try to explain a bit my view on all the current efforts (welcome) to
secure session managements and related areas.
For the last one, I do not think php should take of it. If we still want to
do it, I won't do it all using what it is proposed. It should provide APIs,
easy to use and being used on demand (think of the password APIs for csrf
protection). INI settings are unflexible, hard to custom or fix later. The
pléthore of packages (and some very good ones like in slim fe) lead the
way.
This RFC also makes many assumptions about erroneous common cases as many
other said in this thread.
About all other RFCs to secure or improve sessions. My feeling is simple:
The current session code and designs is old, very old. It does not match
today ways to do things. Every time we fix it, I see a band aid fix.
In other words, rewrite the damned thing. Make clear, simple APIs, enable
secure behavior by default and limit the ini options to the very strict
minimum.
We all already used custom extensions for management anyway (serialization,
different backends, etc). It may not help shared hosting but these are kind
of hopeless in many regards.
Regards,
P.S. Precise session ID management is important, but this one is also
important. I'll finish and start voting 2 active session RFCs soon. I
may finish all of them hopefully.
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_protectionThank 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
Hi Pierre,
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