[Webkit-unassigned] [Bug 34289] WebSocket ignores HttpOnly cookies, but should use in Handshake.

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Fumitoshi Ukai <ukai at chromium.org>  2010-02-11 19:15:49 PST ---
(In reply to comment #2)
> (From update of attachment 47825 [details])
> +# Copyright (C) 2009 Google Inc. All rights reserved.
> 
> 2010.
> 
> +Should say PASS:
> +
> +WebSocket open
> +WebSocket closed
> +PASS cookie is "WK-test=1; WK-test-httponly=1"
> +PASS successfullyParsed is true
> 
> The "should say pass" phrase is slightly misguiding - it's a series of PASS
> messages, followed by "TEST COMPLETE".
> 
> +        "-x", "/websocket/tests/cookies",
> 
> It's confusing to have .html files that are processed as CGIs, and it's
> confusing to have directories that are magically different from others. The
> run-webkit-tests script has a built-in list of extensions for tests, which
> includes .pl and .php, among others.
> 
> +    shouldBe("cookie", '"WK-test=1; WK-test-httponly=1"');
> 
> I'm always nervous when cookie names are reused. We already have WK-test used
> by xmlhttprequest/cookies.html test, and I don't see how this new test can not
> make it fail (other than if it's more than a 1000 tests away, and gets a new
> DRT instance).

I think this is because these belong to different port.
Anyway, changed them to WK-websocket-test-* to make it clear.

> 
> Please use unique cookie names, ideally ones that clearly correspond to the
> test (I should have set a good example of the latter with
> xmlhttprequest/cookies.html!)
> 
> +static String getCookiesForWebSocket(Document *document, KURL& url)
> 
> WebSocket code should not attempt to build Cookie headers itself. For example,
> we should use +[NSHTTPCookie requestHeaderFieldsWithCookies:] on Mac OS X, just
> like cookies() function in CookieJar does.
> 
> This should be trivial to implement by adapting cookie() code, the only minor
> challenge is coming up with a nice name for the new CookieJar function. I'm
> thinking of cookieRequestHeaderFieldValue().
> 
> +SECURITY WARNING: This uses CGIHTTPServer and CGIHTTPServer is not secure.
> 
> I had some difficulty parsing this phrase. And a more detailed explanation of
> how this is insecure would help - Apache also executes CGIs, but this doesn't
> automatically make it insecure. 
> 
> +It may execute arbitrary Python code or external programs. It should not be
> +used outside a firewall.
> 
> I think it's actually more common that insecure servers run outside of firewall
> (more precisely, in "DMZ"). That way, one can't use them as trampoline for
> bypassing firewall.

I just copied it from python's CGIHTTPServer warning phrase.
I think it's unsecure because original CGIHTTPServer might run any executable
outside of document root. 
pywebsocket checks .. should not be used for request path for cgi, so it might
be ok.
Do you think we should remove this warning?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.