[privoxy-devel] [ ijbswa-Bugs-932612 ] session-cookies-only breaks cookies instead of deleting them

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #932612, was opened at 2004-04-10 00:16
Message generated for change (Comment added) made by fabiankeil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=932612&group_id=11118

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: funct: header manipulation
Group: version 3.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: O.S. (olaf)
Assigned to: Fabian Keil (fabiankeil)
Summary: session-cookies-only breaks cookies instead of deleting them

Initial Comment:
version: 3.0.3
OS: Linux, kernel 2.4.23, distrib: debian woody/sarge
Browsers: Any Graphical I have installed: konqueror 3.1.3, galeon 1.3.13, mozilla 1.6, netscape 4.77

Similar to bug #892883 of project "webcalendar" I get the login page re-displayed if logging in with correct username/password, regardless of the browser used.  The workaround suggested in #892883 anonymously by "Behrend" did not change anything.

Demo URL: http://webcalendar.sourceforge.net/demo/login.php
 make sure that 
http://config.privoxy.org/show-url-info?url=http%3A%2F%2Fwebcalendar.sourceforge.net%2Fdemo%2F
displays 
 -crunch-incoming-cookies 
 -crunch-outgoing-cookies
 +session-cookies-only 
and that it does not display
 -session-cookies-only
for the demo URL.

How to reproduce this bug: 
log in, log out using " Entra/Esci " in the first bottom line - 
 (the demo is configured to Italian)
 and then you cannot login again using privoxy.

watch the content of your browser's cookies while doing this.
 It has to do something with cookies.
This is why I blame privoxy for this behaviour:

If I disable the action "session-cookies-only" for WebCalendar access I can login.  But looking at my cookie contents I always receive only session cookies by webcalendar (which I appreciate). The only difference is that - if using privoxy -
 cookies named "webcalendar_session" won't be deleted but get their value reset to "deleted". Therefore is privoxy to blame.
If I set my browser to "limit all cookies to this session" (konqueror, galeon, not tested with mozilla) the cookie "webcalendar_session" will be deleted properly on logout.

----------------------------------------------------------------------

>Comment By: Fabian Keil (fabiankeil)
Date: 2007-01-30 15:00

Message:
Logged In: YES 
user_id=875547
Originator: NO

Should be fixed in CVS now.

----------------------------------------------------------------------

Comment By: Wes R (wesyah234)
Date: 2006-12-06 18:57

Message:
Logged In: YES 
user_id=214289
Originator: NO

Sorry about the double post back there... 

Any update on this?  seems that privoxy is stripping out the expires= part
of the SetCookie header, thus allowing the dummy cookie value to be set on
the browser...

----------------------------------------------------------------------

Comment By: Wes R (wesyah234)
Date: 2006-11-18 04:02

Message:
Logged In: YES 
user_id=214289
Originator: NO

Thanks to all who are looking into this!

I think I have it figured out.

I agree that the web server is setting the cookie to a value of "deleted",
but I still need to figure out why the cookie properly expires when not
using privoxy and it doesn't expire when using privoxy.

So I ran the Live Http Headers extension in Firefox, and captured the
header traffic both with privoxy and without privoxy.

When not using privoxy, and calling clearCookie.php, I see this from the
server to the browser:
Set-Cookie: testcookie=deleted; expires=Fri, 18 Nov 2005 03:35:43 GMT
(That expiration is the current time, thus the cookie properly expires and
is not stored in the browser and not sent back on the next GET)  It's still
strange that apache chooses to send "deleted", but it's no matter, since
the expiration is now and it expires correctly.

But when using privoxy, and calling clearCookie.php, I see this from the
server to the browser:
Set-Cookie: testcookie=deleted;
(the expiration is not there.  And I can only assume that privoxy has
stripped it off)

So I think this is what's happening: Apache is sending a dummy "deleted"
value, and it shouldn't matter because the exipration will tell the browser
to expire the cookie.  But when privoxy sees the set-cookie header, it
strips out the exipration, resulting in the dummy value getting stored on
the browser and getting sent in subsequent requests.

Does this sound like a reasonable explanation?  

In reading the comment history, Gergely Bor on 2005-02-16 seems to be
saying the same thing: "... if the date is removed, it's likely to be
interpreted by the client as a normal textual value and therefore it's set
instead of removed..."

----------------------------------------------------------------------

Comment By: Wes R (wesyah234)
Date: 2006-11-18 04:00

Message:
Logged In: YES 
user_id=214289
Originator: NO

Thanks to all who are looking into this!

I think I have it figured out.

I agree that the web server is setting the cookie to a value of "deleted",
but I still need to figure out why the cookie properly expires when not
using privoxy and it doesn't expire when using privoxy.

So I ran the Live Http Headers extension in Firefox, and captured the
header traffic both with privoxy and without privoxy.

When not using privoxy, and calling clearCookie.php, I see this from the
server to the browser:
Set-Cookie: testcookie=deleted; expires=Fri, 18 Nov 2005 03:35:43 GMT
(That expiration is the current time, thus the cookie properly expires and
is not stored in the browser and not sent back on the next GET)  It's still
strange that apache chooses to send "deleted", but it's no matter, since
the expiration is now and it expires correctly.

But when using privoxy, and calling clearCookie.php, I see this from the
server to the browser:
Set-Cookie: testcookie=deleted;
(the expiration is not there.  And I can only assume that privoxy has
stripped it off)

So I think this is what's happening: Apache is sending a dummy "deleted"
value, and it shouldn't matter because the exipration will tell the browser
to expire the cookie.  But when privoxy sees the set-cookie header, it
strips out the exipration, resulting in the dummy value getting stored on
the browser and getting sent in subsequent requests.

Does this sound like a reasonable explanation?  

In reading the comment history, Gergely Bor on 2005-02-16 seems to be
saying the same thing: "... if the date is removed, it's likely to be
interpreted by the client as a normal textual value and therefore it's set
instead of removed..."

----------------------------------------------------------------------

Comment By: Hal Burgiss (hal9)
Date: 2006-11-18 02:48

Message:
Logged In: YES 
user_id=322640
Originator: NO

I'll add that I run session-cookies for / in user.action going back a
number of weeks now (and no related browser settings), and this is what I
have:

$ cat  ../.mozilla/firefox/dzzl74tr.default/cookies.txt  |wc -l
   94

94 cookies, and "deleted" appears nowhere:

$ grep -i deleted  ../.mozilla/firefox/dzzl74tr.default/cookies.txt  |wc
-l
      0

Not sure what's going on, but there is more than one piece to the puzzle.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-11-18 00:41

Message:
Logged In: NO 

The value "deleted" is not being assigned by Privoxy, it's coming out of
your own server as a cookie assignment.  An independent test of your
clearCookie page can be seen using:

http://mbn.dk/q/?method=GET&url=http%3A%2F%2Fwww.yawebhost.com%2Fprivoxy%2FclearCookie.php&xtra=&vars=

The headers that your server produced are:
====================
HTTP/1.1 200 OK
Date: Sat, 18 Nov 2006 00:32:22 GMT
Server: Apache
X-Powered-By: PHP/4.4.4
Set-Cookie: testcookie=deleted; expires=Fri, 18 Nov 2005 00:32:21 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
====================

I haven't a clue why you'd ever see different behavior for that "deleted"
value when you're not using Privoxy.

----------------------------------------------------------------------

Comment By: Wes R (wesyah234)
Date: 2006-11-17 16:11

Message:
Logged In: YES 
user_id=214289
Originator: NO

That's great that the session-cookies-only thing is disabled by default in
the newer versions of Privoxy.  I agree this will help to cause less
problems, as people update their proxies.  However, the problem will still
exist for some time as there will always be older installations around.

I am particularly interested in your comment about being partly the web
application's fault for not using proper input validation.  To illustrate
what I'm seeing, I isolated the issue to a few php scripts.  I've installed
them on a webserver to make it easier for people to test.  The source code
is simple:

in setCookie.php:
setCookie('testcookie', 'hello');

in testCookie.php:
echo "the value of testcookie is: ".$_COOKIE['testcookie'];

in clearCookie.php:
setCookie('testcookie', '', time()-60000);

When I run setCookie.php, clearCookie.php, testCookie.php without going
through privoxy, the value of the cookie is empty.

To try for yourself:
http://www.yawebhost.com/privoxy/

When I run the same sequence of scripts through privoxy, the value of the
cookie becomes "deleted". This is a problem for my web application because
I display the value of the cookie to the user, and when I attempt to delete
it, I really want it to be gone, but instead the user sees the word
"deleted" on the screen.  I can fix this by adding a hook that also checks
for the word "deleted", however this isn't a universal solution because it
fails when the system actually desires to set a cookie to a value of
"deleted".

Hopefully this clarifies what I'm seeing.  I don't understand how input
validation would change anything with this scenario.  If there is something
I'm doing wrong with the cookie handling, please let me know.

Thanks.

----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2006-11-16 11:37

Message:
Logged In: YES 
user_id=875547
Originator: NO

This bug still exists in Privoxy 3.0.5 beta and will
not be fixed in 3.0.6 either. I will look into fixing
it once 3.0.6 is out, but it doesn't have high priority.

Since Privoxy 3.0.5 beta the session-cookies-only action
is disabled by default and should therefore cause less problems.

I assume nowadays most Privoxy users will use their browser's
cookie handling for this anyway. Privoxy users who really need
session-cookies-only can work around this bug by using a custom
header filter to remove offending cookies.

Of course this Privoxy bug only shows up if the website
doesn't use proper input validation. If this Privoxy bug
affects your web application, that's at least partly the
web application's fault. 

----------------------------------------------------------------------

Comment By: Wes R (wesyah234)
Date: 2006-11-15 20:06

Message:
Logged In: YES 
user_id=214289
Originator: NO

Could you please update us on this bug report?  I am seeing the same
situation.  I wrote a web application (actually a PHP web framework, hosted
here at sourceforge) that will set a transient status message via a cookie.
 I redirect the user to a page that will show the status message (ie. the
contents of the cookie).  Then, after showing it once, it will set it to ''
with a date in the past,  (the recommended way to "delete" a cookie).  If
the user then reloads the page, the status message will go away, because
the cookie value will be empty. 

This behavior fails when going through privoxy with the default settings. 
When the user refreshes, the status message changes to the words "deleted".
 Fortunately, a quick search brought me to this bug posting, so I know I'm
not going insane wondering how the value "deleted" got into my cookie!

If a website sets a cookie to an empty value, I don't think privoxy should
step in and set the value to the text "deleted".

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-02-16 16:01

Message:
Logged In: NO 

I have this problem as well (or something very similar)...

I dig the debug log a bit, and found the following scenario erroneous:
 - Site has +session-cookies-only prop set in config
 - Site has a persistent cookie created already or site tries to create it
during the session
 - Site issues a persistent cookie removal request with sg. like
"Set-Cookie: SomeCookieKey=deleted; expires=Tue, 17-Feb-2004 14:23:32 GMT"
 - Expected result: cookie is deleted; scenario without Privoxy: cookie is
deleted; scenario with Privoxy: cookie is not deleted.

Sadly such removals are quite common, the core PHP issues removals like
that so every PHP script that would remove a persistent cookie fails to do
so in a +session-cookies-only environment. (NB. other "cookie-sessioning"
solutions like the one in Mozilla seem to support such scenarios.)

NB. obviously the problem is that since some MSIE versions require the
value to be set 'deleted' instead of '', if the date is removed, it's
likely to be interpreted by the client as a normal textual value and
therefore it's set instead of removed.

My suggestion is to skip date removal if the date is in the past _and_ the
value is eq 'deleted'.

I have not tested the scenario with '' instead of 'deleted'; the problem
may affect such scenarios as well.

Sadly this problem affects our corporate website as well, resulting in our
serach engine being fed with trash, which is far from neat; so it'd be
great if this could be fixed. Thank you. (BTW, been a Junkbuster fan for a
long while, and I find Privoxy cool too, keep up the good work :))

Best regards,
  Gergely Bor
  bo...@in...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=932612&group_id=11118

[privoxy-devel] [ ijbswa-Bugs-932612 ] session-cookies-only breaks cookies instead of deleting them

HTTP proxy to block ads and customize webpages

[privoxy-devel] [ ijbswa-Bugs-932612 ] session-cookies-only breaks cookies instead of deleting them