[Webkit-unassigned] [Bug 166624] New: SecurityOrigin::create triplet constructor does not canonicalize port

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=166624

            Bug ID: 166624
           Summary: SecurityOrigin::create triplet constructor does not
                    canonicalize port
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at igalia.com
                CC: bugs-noreply at webkitgtk.org

WebCore::SecurityOrigin has four public create functions:

    WEBCORE_EXPORT static Ref<SecurityOrigin> create(const URL&);
    static Ref<SecurityOrigin> createUnique();

    WEBCORE_EXPORT static Ref<SecurityOrigin> createFromString(const String&);
    WEBCORE_EXPORT static Ref<SecurityOrigin> create(const String& protocol, const String& host, std::optional<uint16_t> port);

When a WebCore::SecurityOrigin is created using the first function, the port is canonicalized by unsetting it if it matches the default port for a protocol. That is handled by this code in the constructor:

    if (m_port && isDefaultPortForProtocol(m_port.value(), m_protocol))
        m_port = std::nullopt;

The second create function is not relevant to this bug.

The third function, createFromString, converts a String to a URL and then uses this path. So, for example, the expression SecurityOrigin::createFromString("http://example.com:80").port() would return nullopt, as it would if the port was omitted from the URL string. This is correct as per RFC 6454 because http://example.com and http://example.com:80 have the same security origin.

The issue lies with the fourth constructor. It does not perform this canonicalization, allowing two different nonequal SecurityOrigin objects to be created that represent the same security origin. That is, this constructor could be used to create a SecurityOrigin with protocol http, port 80, even though the other constructors would always canonicalize port 80 to nullopt.

I noticed this when working on exposing WebKitSecurityOrigin in the GTK+ API. I'm performing the canonicalization at the GTK+ API level for now, but I think it makes sense to do it in WebCore instead. I wonder if changing this in WebCore would expose unexpected side effects.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161230/30247063/attachment.html>