bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] wget bug re cookies


From: Tim Ruehsen
Subject: Re: [Bug-wget] wget bug re cookies
Date: Tue, 13 Sep 2016 16:49:32 +0200
User-agent: KMail/5.2.3 (Linux/4.7.0-1-amd64; KDE/5.25.0; x86_64; ; )

On Tuesday, September 13, 2016 11:46:39 PM CEST David Oppenheim wrote:
> wget has long had a problem with cookies - it does not handle
> them the same as browsers. As a consequence it is often not usable
> in sites with session logins other than very simple logins,
> for example SiteMinder controlled web sites.
> 
> Specifically, wget treats a received cookie that does not include
> an explicit domain as having a domain of the host (good) but
> requiring an exact match before that cookie is sent in later replies
> (bad - not like browsers).
> 
> So a cookie from foo.com that doesn't set the domain will only
> be sent by wget back to foo.com, not to xx.foo.com
> 
> This follows RFC 6265 (see section 4.1.2.3).  But is not the way
> today's browsers work.
> 
> The issue is simply fixed in cookies.c by removing one line :
> 
>   /* Sanitize parts of cookie. */
> 
>   if (!cookie->domain)
>     {
>       cookie->domain = xstrdup (host);
>   ////      cookie->domain_exact = 1;   // This code obeys RFC 6265 but is
> not the way real browsers behave
> 
> 
> I'm happy to discuss further if you're interested.
> 
> I think this change would make wget immensely more useful (and
> it's very useful already, thanks !)


IMO, it would make wget immensely more insecure :')

We don't have to argue, others made a pretty good job in discussion all the 
cookie RFCs and testing different types of browsers.
From what I can read here 
(http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/), only 
Internet Explorer isn't RFC conform regarding cookies 
without domain (but year 2014 is *very* long ago regarding security issues).

So if you really want 'Internet Explorer Insecurity' (and I can guess that 
there some use cases), we should protect the RFC behavior by a new switch 
(e.g. like --internet-explorer-insecurity[=on] with default to off).
You might have a better name... ;-)

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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