Bug 26270 – Exception on XMLHTTPRequest with certain characters in username or password

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Platform

[Josh Triplett]

(Also filed as 6885749 in Apple's bug-tracking system at http://developer.apple.com/bugreporter/ .)

Attempting to open an XMLHTTPRequest with an HTTP Auth username and password will throw an exception unless the username and password consist exclusively of alphanumeric characters or a limited set of symbols.

Steps to Reproduce:

The attached test file will use JavaScript to check which characters Safari allows in usernames and passwords.  Place the attached test file xhr-char-test.html on a webserver.  Access it in Safari via HTTP.  When the included JavaScript finishes running, it will display a table of all characters from 0-255 and whether Safari threw an exception when attempting to use them.

Alternatively, access the test page at http://ext.serialist.net/tests/xhr-char-test.html to see the same results.

Expected Results:

Safari should allow requests via XMLHTTPRequest to use any username or password, without throwing an exception.

Actual Results:

Safari throws an exception if attempting to perform an XMLHTTPRequest unless the username and password consist exclusively of letters, numbers, or a limited set of symbols.

Notes:

We tested running this same test case in Firefox 3, Internet Explorer 7, and Konqueror 3.5.9, all of which allow any character in usernames or passwords.  We also tested in Arora, which uses WebKit, and it threw an exception on exactly the same characters as Safari.

I'll also attach a copy of the results from Safari, for convenience.

[Josh Triplett]

Created attachment 31086 [details]
Test case for characters allowed in XMLHTTPRequest username or password

[Josh Triplett]

Created attachment 31087 [details]
Results from test case on Safari

[James Robinson]

Confirmed on WebKit nightly (r44702).  The relevant specs - HTTP Auth, XHR, and HTML5 all seem silent on what characters should be allowed.

[Josh Triplett]

ping?  Any status on this bug?

[Julien Chaffraix]

Created attachment 95195 [details]
Proposed fix: Change KURL encoding logic to handle user/password properly

[WebKit Review Bot]

Attachment 95195 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/http..." exit_code: 1

Source/WebCore/platform/KURL.cpp:1535:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 5 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Julien Chaffraix]

Created attachment 95204 [details]
Same as previously but with a missing space that made the EWS sad

[Alexey Proskuryakov]

Comment on attachment 95204 [details]
Same as previously but with a missing space that made the EWS sad

This should properly handle and test characters with Unicode codes > 255. And the interesting question is what character encoding to use!

[Rob Walker]

(In reply to comment #8)
> (From update of attachment 95204 [details])
> This should properly handle and test characters with Unicode codes > 255. And the interesting question is what character encoding to use!

Consumers of the resulting encoded user and host must assume Unicode in utf-8 when supplied from JS, I reckon.  The encoding and decoding implemented will preserve the UCS2 needs of JS.

[Alexey Proskuryakov]

Who are the consumers? With most authentication schemes (every one besides Basic), the server never even gets to see the plaintext password.

The code that's changed here is in KURL, but the primary use of the credentials is not in URL, but in HTTP headers. We could try to reverse engineer other browsers behavior by looking at URL handling though.

[Rob Walker]

(In reply to comment #10)
> Who are the consumers? With most authentication schemes (every one besides Basic), the server never even gets to see the plaintext password.

I was referring to callers of the KURL user() and password() methods, as well as auth-basic, though I have to admit I don't know what charset conversion (if any) might go on beyond user() and password() in that area of the code.

[Anne van Kesteren]

This has been changed a few times over the past decade+.