[Top][All Lists]
[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