W3C home > Mailing lists > Public > public-appformats@w3.org > July 2007

[ac] wildcard rules and subdomains

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 03 Jul 2007 17:35:57 -0700
Message-ID: <468AEB6D.3050308@sicking.cc>
To: "WAF WG (public)" <public-appformats@w3.org>

Hi All,

Currently the spec says that a rule like "*.example.com" does not match 
a request from example.com. The result is that if you want to give 
access to anything coming from example.com, including any subdomains, 
you'll have to write a rule like:

Content-Access-Control: allow <*.example.com>, <example.com>

And similarly, if you want to deny requests from evil.com you have to do:

Content-Access-Control: deny <*.evil.com>, <evil.com>

I think it would be better if *.example.com also matched example.com.

Pros:
In many cases you can write simpler rules since I'd imagine it's more 
likely that you want to deny or grant access to both a domain and its 
subdomains, than that you just want one of the two.

There's no longer a risk that someone will think that *.example.com does 
match example.com.

Cons:
There's a risk that someone will think that *.example.com does not match 
example.com.

I actually think that the consequences of misunderstanding is smaller in 
the latter case. Lets example the possible misunderstandings under the 
two algorithms:


== Current algorithm, *.example.com does not match example.com ==
Author uses the rule
Content-Access-Control: allow <*.example.com>
and thinks this grants access to example.com

The consequences aren't very bad, the only thing that will happen is 
that when the site example.com is used things will not work. This is 
easily detectable and fixed

Author uses the rule
Content-Access-Control: deny <*.example.com>
and thinks this denies access to example.com

The consequences are bad. Access is not denied to example.com even 
though that was intended.

== Proposed algorithm, *.example.com does match example.com ==
Author uses the rule
Content-Access-Control: allow <*.example.com>
and thinks this does not grant access to example.com

The consequences are somewhat bad, access is granted to example.com even 
though that was not intended. However, it is likely that however runs 
example.com could simply set up foo.example.com and use that to get 
access. In general I can't think of a real-world example where you'd 
trust the subdomains of a site, but not the top domain.

Author uses the rule
Content-Access-Control: deny <*.example.com>
and thinks this does not deny access to example.com

The consequences aren't very bad, the only thing that will happen is 
that when the site example.com is used things will not work. This is 
easily detectable and fixed.

/ Jonas
Received on Wednesday, 4 July 2007 00:36:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC