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: Sun, 11 Nov 2012 21:19:20 +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 20:17, Tim Rühsen wrote:
> > Am Freitag, 9. November 2012 schrieb Ángel González:
> >> 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. 

> Can you provide an example on how you are using wget, that leads you to
> think
> you would be vulnerable?
> I think you may be misunderstanding something (but perhaps it turns out
> it's me
> who is wrong!).
> 
> Maybe it is most dangerous if you have load_cookies and save_cookies set
> in your
> wgetrc, instead of passing an appropiate one for each task.
> 
> Even then, the case you mention of stealing your private data is quite
> hard, as
> the to-be-stolen website is very unlikely to use a "vulnerable" domain
> (ie. not caught
> by the general rules used by wget).

Thanks to your questions I spent more time into the issue.

Well, at least the expression "supercookie" is misleading. I got it from 
http://publicsuffix.org, but meanwhile I know "supercookie" in general means 
DOM/Web storage - another kind of persistently storing server infos on the 
client side. But that is another issue, not relevant for wget right now.

In general: storing cookies with a public domain attribute *may* leak your 
privacy. The normal user is not aware of that fact, so the used client 
software should take care of that. Most browsers do that by using the PSL 
(Public Suffix List). Wget is a cookie storing client and thus should use the 
PSL as well. The Mozilla PSL is - as they write - not perfect, but all we 
have.
I can't give you an example where privacy leaking really takes place. But I 
could construct / think of such cases.


> >> 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.
> I answered without checking, from what I remembered. Reading it now, it
> does
> seem quite straightforward to interpret the list. Although perhaps a bit
> more complex
> to do that efficiently for multiple domains.
> 
> I don't know where's that function you mention, I don't see it in the
> website. Perhaps
> it belongs to your mget?

Yes. Go to https://github.com/rockdaboot/mget and click on 'cookie.c'.
Test cases can be found in tests/test.c/test_cookies()

Regards, Tim



reply via email to

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