Hi Joao, On Sun, Oct 27, 2019 at 03:51:18PM -0300, Joao Morais wrote: > > Hi list, the attached patch fixes a warn message if the domain option, from > cookie keyword, configures a domain without starting with a dot. > > > From ee0d7f60d4b0c31e779b639c39e0226cbc920e69 Mon Sep 17 00:00:00 2001 > From: Joao Morais <jcmorai...@gmail.com> > Date: Sun, 27 Oct 2019 15:04:15 -0300 > Subject: [PATCH] BUG/MINOR: config: Warn cookie domain only if missing > embedded dot > > The domain option of the cookie keyword allows to define which domain or > domains > should use the the cookie value of a cookie-based server affinity. If the > domain > does not start with a dot, the user agent should only use the cookie on hosts > that matches the provided domains. If the configured domain starts with a dot, > the user agent can use the cookie with any host ending with the configured > domain. > > haproxy config parser helps the admin warning about a potentially buggy > config: > defining a domain without an embedded dot which does not start with a dot, > which > is forbidden by the RFC. However the condition was warning valid domains as > well.
No, please look at the RFC again, it's very precise on this : https://tools.ietf.org/html/rfc2109 | 4.3.2 Rejecting Cookies | | To prevent possible security or privacy violations, a user agent | rejects a cookie (shall not store its information) if any of the | following is true: | | * The value for the Path attribute is not a prefix of the request- | URI. | | * The value for the Domain attribute contains no embedded dots or | does not start with a dot. See the "OR" above ? Hence: - a domain with no embedded dots is invalid - a domain that does not start with a dot is invalid This is further explained in the last example with "Domain=ajax.com" : | | * The value for the request-host does not domain-match the Domain | attribute. | | * The request-host is a FQDN (not IP address) and has the form HD, | where D is the value of the Domain attribute, and H is a string | that contains one or more dots. | | Examples: | | * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com | would be rejected, because H is y.x and contains a dot. | | * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would | be accepted. | | * A Set-Cookie with Domain=.com or Domain=.com., will always be | rejected, because there is no embedded dot. | | * A Set-Cookie with Domain=ajax.com will be rejected because the | value for Domain does not begin with a dot. So I could say that we apply exactly what the spec mandates. I know that browsers tend to be more permissive than the spec to accomodate for old applications (and for broken ones as well) but as new attacks appear, they can quickly switch to a stricter mode and break some applications. Thus the warning should remain to inform the user that there is a risk that sooner or later a browser will reject such a cookie. Cheers, Willy
