On 11/05/2016 09:13, Yasuo Ohgaki wrote:
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?
1) Because it gives users a false sense of security. If you say "turn
this on and don't think about CSRF", and then somebody is caught by a
CSRF vulnerability because the HTML rewriter wasn't smart enough to
inject the parameter in the right place, they will feel you misled them.
If you can't say that, then it's not really as simple as you implied.
2) Because it treats all users as malicious actors, rather than fallible
ones. If you take too long writing a comment, you shouldn't get a 500
error when you submit it, you should get a friendly message and a
pre-filled form. That requires integration with the application
framework, not with the session manager.
3) Because it complicates the session code with extra responsibilities,
rather than concentrating on safely persisting arbitrary state data.
4) Because it adds yet another global setting that would be essential to
be turned on for some applications, off for others.
The current proposal has effectively 4 features:
- Automatic generation and storage of a CSRF token on session start; a
fairly trivial task to implement in plain PHP.
- Optional automatic rewriting of HTML to include the token. This is the
only part that is actually hard to do without the core's involvement,
but see point 1 above.
- A method to validate the CSRF token. Again, this is fairly simple to
implement in PHP, and a quick glance at Packagist shows there are plenty
of off-the-shelf implementations with various features.
- Optional automatic enforcement of the CSRF check. This is also fairly
easy to implement in plain PHP, and since the user is likely to need to
implement user code to make use of it anyway (e.g. set_error_handler is
mentioned in the current RFC), it may actually be easier to perform the
check manually.
Thinking about it, the only part that has some value being in core is
the HTML rewriting. Perhaps what is actually needed is a lower-level
function that PHP libraries can use to hook into this with whatever
parameters they want, e.g.
register_html_rewrite_callback(
function() { return [ 'csrf_token' => MyFramework\CSRF::getToken()
]; },
REWRITE_POST_FORMS | REWRITE_URL
);
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
