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
signature.asc
Description: This is a digitally signed message part.
