Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72505 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 926 invoked from network); 12 Feb 2014 08:20:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2014 08:20:20 -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.215.54 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.215.54 mail-la0-f54.google.com Received: from [209.85.215.54] ([209.85.215.54:36778] helo=mail-la0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/00-00747-2CE2BF25 for ; Wed, 12 Feb 2014 03:20:19 -0500 Received: by mail-la0-f54.google.com with SMTP id y1so6700695lam.41 for ; Wed, 12 Feb 2014 00:20:15 -0800 (PST) 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:content-type; bh=4iPul2/T1PKCn9367PP2wWh7R2HJbdlgF9RoFNsVicw=; b=UbXFHnhOcQoSuJk5VgrFfrDKDKbVYGvSLfHpngPyLHEL7V8SxSnfAUCgeaB6DGThI5 etkiVZ+xIqfdZizO33EQSvK5PlYqwCatj7O85Kbt5BNb3LMNRWZ5KzFSAl4zv8YqGbcP hGXuojPR1f+23VqcDJgn7+STffQNUWl7Ft6xKJxhvdorJu877UlhhC+XZnhqXXw96Nm2 PIHXakZmeIT2FHdu+iVdm0mH2xxFGa1namT1IDnJRcKJ9YnDeysdxxA7NNIhoxTZfD9T coiWYeVi8B6Zo7kZmgBLlySVhh9IHjsXwH+YEGa/RxTbS3AvhxAY3yzqGfGICK4vtx2R EIXg== X-Received: by 10.152.36.70 with SMTP id o6mr29725433laj.7.1392193215265; Wed, 12 Feb 2014 00:20:15 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.199.37 with HTTP; Wed, 12 Feb 2014 00:19:35 -0800 (PST) In-Reply-To: <4ED7146272E04A47B986ED49E771E347BBC71EE8F1@Ikarus.ameusgmbh.intern> References: <4ED7146272E04A47B986ED49E771E347BBC71EE85D@Ikarus.ameusgmbh.intern> <4ED7146272E04A47B986ED49E771E347BBC71EE8F1@Ikarus.ameusgmbh.intern> Date: Wed, 12 Feb 2014 17:19:35 +0900 X-Google-Sender-Auth: 2IgazOX10nWsV-xVTmAMZetZeEM Message-ID: To: Christian Stoller Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=089e0160b6180e002e04f2313ee0 Subject: Re: [PHP-DEV] Empty session cookie leads to warning From: yohgaki@ohgaki.net (Yasuo Ohgaki) --089e0160b6180e002e04f2313ee0 Content-Type: text/plain; charset=UTF-8 Hi Christian, On Wed, Feb 12, 2014 at 4:25 PM, Christian Stoller wrote: > > What is the reason for having extremely insecure session ID? > > Is user sending empty cookie by deleting cookie value? > > > > Regards, > > > > Hi Yasuo, > > the resource, which has been called, is a dynamic generated playlist file > (.M3U) and it seemed like the user agent was a Windows Media Player, > because of the passed HTTP headers. But I have no clue why the empty cookie > has been sent. > > I have extended the application, so that the cookie value is checked and > the session won't be started if it is empty. > > But maybe there is someone who could improve the warning message a bit. In > this case it could say "The session id is empty or too short." I cannot prevent clients from sending empty(invalid) session id cookie, but I can make session module try to regenerate session ID silently when invalid session is sent regardless of use_strict_mode. The error message may be too much as clients can send any session ID cookie. Issue is that current code does not distinguish whether the invalid session ID is set by programmer or client. I'm not sure what is the best approach. Does anyone have idea? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --089e0160b6180e002e04f2313ee0--