Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93257 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13451 invoked from network); 12 May 2016 00:27:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2016 00:27:52 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.192.46 mail-qg0-f46.google.com Received: from [209.85.192.46] ([209.85.192.46:32993] helo=mail-qg0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D7/75-28272-70EC3375 for ; Wed, 11 May 2016 20:27:51 -0400 Received: by mail-qg0-f46.google.com with SMTP id f92so33427374qgf.0 for ; Wed, 11 May 2016 17:27:51 -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=+dwbwo1AZu+UxJRPTCdYZOYNYZYD4rYG21P8bMGqrE4=; b=ROPG/wQjkFP0QQojMl27NWtUKcMPM+RYaesPGfYW5jTST+O9OUR/qFUF+QxOMS7hx3 pNlOkdoiDZYSWTAnErXMcb6K4MD9zWNIsktcdxv+iJrz0+mngYF3FcqJg90hIIuf92Bh 9w8clVFIPKx2G44LOMKL6njldPWY6igIB0CXLuJWih9ToQ9q4b1vPM/+awhzwz2fInnG 0ZXEAuBjWXkThbyVvHePHrOAFJs8ObtnTCbVS48HUQJE8e472hh73h6CZEHx1rd0xT80 KpTiKBa6V8xHVrTDZzLB72afaPFzvinky9JgfyL6+8PFng97Tbbs6xIcEVZwSQKablBR mTmg== 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=+dwbwo1AZu+UxJRPTCdYZOYNYZYD4rYG21P8bMGqrE4=; b=bgt4/luTHrP0Sbxf3uHdrQreNZogrV9bwNG4DXMbjZWiod1S+WRtYAoJz8CrZ7pXfa FUPRMQx6rgeFesDLKjAGGK8Dhg2ZzAlud3OV3+xGtCBuNBUrCI3/8vBytQvp8yankEQU Gu4PSBG7Ek/FFhjcWo05XD/67iE5VRCDDYuXMuvO90LQWEOmYz9yg6iVtHC7flH3eG4E sSd4xwzUwpY5vKxcidTWc5laCN3S3Au8YujA6dMOMsVU8p+Xyg50P8P6UFqtkuVV9SFz ppbMKu2mcM2gILDwOMupXT/orPzyaV1tP46RPTTlRzybOqf05NzG3UrIA3eOkMBhmpTv 7H6Q== X-Gm-Message-State: AOPr4FW4biIQddrLPbr2kfAl3jubG2K1X8iC1sbSn/uPMpIKoiXdfF1/BNzmA1bMhCVfyFcRWsPBtcAU1FBzyA== X-Received: by 10.140.94.234 with SMTP id g97mr6684618qge.35.1463012868482; Wed, 11 May 2016 17:27:48 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.140.27.133 with HTTP; Wed, 11 May 2016 17:27:08 -0700 (PDT) In-Reply-To: References: <3b115b37-d399-0b69-24b4-de5c95c4a069@gmail.com> <4667bb84-4401-4dd6-6193-fcf3aa6b3d48@gmail.com> <4d97846f-81d6-6cad-91ad-5e513a709e91@gmail.com> Date: Thu, 12 May 2016 09:27:08 +0900 X-Google-Sender-Auth: wprQBrA0ETOH3h7oZp2u1kvh4uU Message-ID: To: Andrey Andreev Cc: "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 Andrey, On Thu, May 12, 2016 at 7:24 AM, Andrey Andreev wrote: > On Thu, May 12, 2016 at 12:39 AM, Yasuo Ohgaki wrote: >> >> Hi Andrey, >> >> On Wed, May 11, 2016 at 10:40 PM, Andrey Andreev wrote: >> > >> > It assumes, and thus also encourages, that users have an active session >> > at >> > 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. 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