Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93214 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10621 invoked from network); 11 May 2016 08:14:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2016 08:14:35 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.220.170 mail-qk0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:35876] helo=mail-qk0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2B/33-28272-9E9E2375 for ; Wed, 11 May 2016 04:14:34 -0400 Received: by mail-qk0-f170.google.com with SMTP id x7so20860739qkd.3 for ; Wed, 11 May 2016 01:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=35ZRAdQMWnTifnWIdTVLQnPxKTFWe0zhav+aLijaHkI=; b=pprsj+1HYFPUOq9owJBE9pUYGNeIu1TRYgGi8W0sbSqlxuU0i609cb7qTHSjIrux40 zGaW4Z8uQBpLHaScQXHPYSYLRaY+0Elbd0qhbf8OghZH+z1QAP5tDMU/tW2rUpLAdC8v Q74lgAgCHGNtT+3D4ldBXXmGBi3YpllsXTnWS0jhCI07nCMGSSlI6j47/u3ougYQ0HLA LRswAOjnZQOyxtP6OFD6St5qUOj0b4lOE6LB83Wa53OM2JtrEfJYuFWiop50SjtyVWhO F9t4v1RQdEMCZmInwLd1bvZytvvKdQj8Mizs/lDc9cqIIR9lUO5RwFXWIWEqYK2nu8TT 10bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=35ZRAdQMWnTifnWIdTVLQnPxKTFWe0zhav+aLijaHkI=; b=QheASSFXrTULD3w6JmAO1bz+YX2oSp9KqRRIVCPeQhNqM0jGMaXcYGUXumKOLcqe8t VDSCYDSLyc5gDD+Oy5V1o9nMbkOROz6TwM535pzdwaTv8DuoYQVD9s6gd0VXmvDyPJXi W3oIfZ7ug5nvKz7jeXWwNNejFIfTO4kZGe3bvNmh0aLi7q0faD+rDKW+SiqIaYuAWIz0 7DocMoQFgcLFeygmIuhIJZ5wl4aeSPE+Mq0gbnllpDMydFpKfnzeuHPTu8lVyxDIhRgv pUt5Ny1nP3go+GYu3WnLVuAktVLMDEAcWiktUgur19zZWaKe+OXBhIGmGSRBfhuNAFa3 jJZw== X-Gm-Message-State: AOPr4FWQMIiRULkFS+RyK5ZrWivpzztA/Q2NXFlyHNOt9LYaEn/RNR2IPgEyqfoITeDCf7O097WRPm4y8AqpXQ== X-Received: by 10.55.118.71 with SMTP id r68mr1951931qkc.198.1462954471631; Wed, 11 May 2016 01:14:31 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.140.27.133 with HTTP; Wed, 11 May 2016 01:13:51 -0700 (PDT) In-Reply-To: References: <3b115b37-d399-0b69-24b4-de5c95c4a069@gmail.com> Date: Wed, 11 May 2016 17:13:51 +0900 X-Google-Sender-Auth: 701zGTgAfSDQsvr22E4qkJUVTVo Message-ID: To: Arvids Godjuks Cc: Niklas Keller , Stanislav Malyshev , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi all, On Wed, May 11, 2016 at 5:05 PM, Yasuo Ohgaki wrote: > On Wed, May 11, 2016 at 4:33 PM, Arvids Godjuks > wrote: >> i'm -1 on the CSRF in the sessions at all. Even more -1 on having it on by >> default and having any INI settings that affect how engine processes data in >> runtime. >> 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... BTW, I'm not asking PHP developers to implement this feature, but I'm willing to implement/maintain the feature. Why 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