Bug 54084 – Hostnames should cannonicalize to lowercase (to match every other browser)

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Eric Seidel (no email)]

Hostnames should cannonicalize to lowercase (to match every other browser)

[Eric Seidel (no email)]

Created attachment 81777 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 81777 [details]
Patch

Clearing flags on attachment: 81777

Committed r78044: <http://trac.webkit.org/changeset/78044>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Timothy Hatcher]

This caused regressions and breakage in Safari extensions. Extension URLs (based on bundle identifiers) are allowed to have only case differences. But now with this change the extension URLs conflict and no longer uniquely identify an extension.

I'd like to propose this change only apply to http, https and maybe file URLs. It seems wrong to assume lowercase is correct for all other URL schemes. Does that seem okay to you Eric?

[Adam Barth]

Can you give an example of a Safari extension URL?

Quoting from http://www.ietf.org/rfc/rfc2396.txt

---8<---

   The URI syntax is dependent upon the scheme.  In general, absolute
   URI are written as follows:

      <scheme>:<scheme-specific-part>

   An absolute URI contains the name of the scheme being used (<scheme>)
   followed by a colon (":") and then a string (the <scheme-specific-
   part>) whose interpretation depends on the scheme.

   The URI syntax does not require that the scheme-specific-part have
   any general structure or set of semantics which is common among all
   URI.  However, a subset of URI do share a common syntax for
   representing hierarchical relationships within the namespace.  This
   "generic URI" syntax consists of a sequence of four main components:

      <scheme>://<authority><path>?<query>

   each of which, except <scheme>, may be absent from a particular URI.
   For example, some URI schemes do not allow an <authority> component,
   and others do not use a <query> component.

--->8----

In particular, the question is what sort of URI these things are.

[Timothy Hatcher]

They are hierarchical.

safari-extension://com.apple.Safari.Test-8Y3CDS73R8/cf03fc47/test.html

[Adam Barth]

Ok.  We can change KURL to be more selective about which schemes it canonicalizes.  However, please be aware that extensions whose authority differ only in case will not be properly isolated from each other by the web platform.  In particular, they'll inhabit the same security origin, which means they can XSS each other.  Also, they'll share persistent storage, such as localStorage.

Another note: because you've reversed the dotted authority hierarchy, there could be serious negative security interactions with with cookies and document.domain (as well as other security features that attempt to understand the DNS hierarchy).

[Adam Barth]

+sam because there are interactions with SecurityOrigin canonicalization too.

[Adam Roben (:aroben)]

(In reply to comment #7)
> Ok.  We can change KURL to be more selective about which schemes it canonicalizes.  However, please be aware that extensions whose authority differ only in case will not be properly isolated from each other by the web platform.  In particular, they'll inhabit the same security origin, which means they can XSS each other.  Also, they'll share persistent storage, such as localStorage.

This is good to know, and may require us to make changes in Safari.

> Another note: because you've reversed the dotted authority hierarchy, there could be serious negative security interactions with with cookies and document.domain (as well as other security features that attempt to understand the DNS hierarchy).

We're aware of that, and are using SecurityOrigin's "domain relaxation forbidden" concept to try to head off problems here. (In fact, this is what that concept was added for.)

[Eric Seidel (no email)]

Filed bug 54271 about making a special case for safari-extension.  I'll write up a patch tomorrow.

[Eric Seidel (no email)]

@abarth: Do we need to file bugs about the possible security issues with safari-extension?  Would you be willing to file those bugs?

[Adam Barth]

(In reply to comment #11)
> @abarth: Do we need to file bugs about the possible security issues with safari-extension?  Would you be willing to file those bugs?

I don't know enough of the details to answer that question.  If there's a problem, the solution is also likely to be in the Safari layer rather than the WebKit layer.  I'll defer to folks who know more about these things to assess whether these issues are actually problematic.

[Adam Roben (:aroben)]

I filed <rdar://problem/8988695> to cover the Safari issues.