Robin wrote:
The <access> element is used to restrict a widget's access to a
limited set of network resources. In the absence of an <access>
element, all access to network resources is forbidden.
The <access> element has a single @href attribute the content of which
is an IRI-like string. The access opening that is specified by that
string is defined as follows:
- the scheme component MUST be present, and access is granted only
for that scheme; and
- the host component MUST be present. If it begins with "*." then
the host that follows the "*." is granted access to, as well as all of
its lower-level domains; otherwise access is only granted for that
domain; and
- if the port component is absent, it is considered to be specified
to be the default for the provided scheme. Access is granted only to
that port; and
- if the path and query string component is present, then access is
granted for any path and query string that starts with the specified
string. It is treated as an opaque string, no attempt must be made to
map to potential directories on the remote server; and
- if a fragment component is specified, it must be ignored.
Two questions:
1. How is the information in this access element going to be used at
installation time or distribution time? I'd like to see some spec
text that explains this.
2. If one of the risks we're interested in is firewall traversal, then
then proposed domain name wildcard has a somewhat different risk
profile than just a single domain name: while you can do a DNS
rebinding attack for a single hostname, that's a well-known issue, and
hopefully worked around in today's browser engines. With the
wildcard, though, it becomes relatively easy to do firewall
traversal: For example, one could simply generate DNS records
n.n.n.n.example.com that point to the IP address n.n.n.n.
I wonder whether it might be useful to clearly distinguish the two
cases (given the different risk profiles); I'd also like to see some
discussion of this effect in the security considerations.
Thanks,
--
Thomas Roessler, W3C <[email protected]>
