bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Supercookie issues


From: Tim Rühsen
Subject: Re: [Bug-wget] Supercookie issues
Date: Fri, 9 Nov 2012 20:17:14 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Am Freitag, 9. November 2012 schrieb Ángel González:
> On 09/11/12 16:27, Tim Ruehsen wrote:
> > While implementing cookies for Mget (https://github.com/rockdaboot/mget) 
> > conforming to RFC 6265, I stubled over http://publicsuffix.org/ (Mozilla 
> > Public Suffix List).
> >
> > Looking at Wget sources discovers, that there is just a very incomplete 
check 
> > for public suffixes. That implies a very severe vulnerability to 
"supercookie" 
> > attacks when cookies are switched on (they are by default).
> >
> > Since Mget was ment as a Wget2 candidate (all or parts of the sources), 
please 
> > feel free to copy the needed sourcecode from it (see cookie.c/cookie.h and 
> > tests/test.c for test routines). Right now, I just don't have the time to 
do 
> > the work, but of course I will answer your questions.
> >
> > ShouldN't there be a warning within the docs / man pages.
> > What do you think ?
> >
> > Regards, Tim

> I see little reason for concern about supercookies on wget given that it
> is unlikely
> to use it for different "tasks" in the same invocation, and cookies are not
> automatically loaded/saved accross invocations.
> And for having a supercookie passed in the same run (eg. one website
> redirected
> to the other), they are probably cooperating domains, so the supercookie
> doesn't
> add much information.
> You would need to be using --load-cookies and --save-cookies to allow such
> supercookie spying.

That's what i use wget. Logging in on a website and accessing my private data.
One could do that even with one call to wget, so --load/save-cookies is not 
even needed.

> The worst case is probably if the cookie file was shared with a browser,
> or it was
> taken from a browser (with many cookies unrelated for what is intended) and
> passed to wget with --load-cookies and wget sent more cookies than
> expected .

That is one possibility, but as i said, you won't need --load/save-cookies to 
be vulnerable. 

> Although not too important, it should be fixed, of course. The Mozilla
> Public Suffix
> List isn't very simple for reuse, its format is designed for how they
> use it internally.

No, the format is easy, clear, understandable und well documented.

Maybe I didn't say understandable in my first post:
The code is there and tested
You just have to call cookie_load_public_suffixes(filename), call repeatedly 
cookie_suffix_match(domain). Very easy.

Regards, Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]