Bug 193155

Summary: Parsed protocol of javascript URLs with embedded newlines and carriage returns do not match parsed protocol in Chrome and Firefox
Product: WebKit Reporter: Daniel Bates <dbates>
Component: DOMAssignee: Brent Fulgham <bfulgham>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, bfulgham, cdumez, commit-queue, esprehn+autocc, ews-watchlist, gyuyoung.kim
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Test
none
Patch
none
Patch for landing none

Description Daniel Bates 2019-01-04 13:19:51 PST
Created attachment 358355 [details]
Test

Behavior of URLUtils.protocol() for some JavaScript URLs disagrees with the behavior in Chrome version 71.0.3578.98 and Firefox version 64.0. For instance, the URLUtils.protocol() for "javascript://:%0aalert(2)" and "javascript://:%0dalert(3)" returns ":" instead of "javascript:".

See attached test case.
Comment 2 Chris Dumez 2019-01-04 13:22:48 PST
URLUtils is our implementation of https://html.spec.whatwg.org/multipage/links.html#htmlhyperlinkelementutils which relies on URL parsing.
Comment 3 Chris Dumez 2019-01-04 13:56:35 PST
diff --git a/Source/WebCore/html/URLUtils.h b/Source/WebCore/html/URLUtils.h
index 3a8d5413f93..a957910aacd 100644
--- a/Source/WebCore/html/URLUtils.h
+++ b/Source/WebCore/html/URLUtils.h
@@ -90,6 +90,8 @@ String URLUtils<T>::origin() const
 template <typename T>
 String URLUtils<T>::protocol() const
 {
+    if (WTF::protocolIsJavaScript(url))
+        return "javascript:"_s;
     return makeString(href().protocol(), ':');
 }

?
Comment 4 Chris Dumez 2019-01-04 13:57:16 PST
(In reply to Chris Dumez from comment #3)
> diff --git a/Source/WebCore/html/URLUtils.h b/Source/WebCore/html/URLUtils.h
> index 3a8d5413f93..a957910aacd 100644
> --- a/Source/WebCore/html/URLUtils.h
> +++ b/Source/WebCore/html/URLUtils.h
> @@ -90,6 +90,8 @@ String URLUtils<T>::origin() const
>  template <typename T>
>  String URLUtils<T>::protocol() const
>  {
> +    if (WTF::protocolIsJavaScript(url))
> +        return "javascript:"_s;
>      return makeString(href().protocol(), ':');
>  }
> 
> ?

Meant:
--- a/Source/WebCore/html/URLUtils.h
+++ b/Source/WebCore/html/URLUtils.h
@@ -90,6 +90,8 @@ String URLUtils<T>::origin() const
 template <typename T>
 String URLUtils<T>::protocol() const
 {
+    if (WTF::protocolIsJavaScript(href()))
+        return "javascript:"_s;
     return makeString(href().protocol(), ':');
 }
Comment 5 Brent Fulgham 2019-01-04 14:23:51 PST
<rdar://problem/40230982>
Comment 6 Brent Fulgham 2019-01-04 14:24:54 PST
Created attachment 358371 [details]
Patch
Comment 7 Chris Dumez 2019-01-04 14:27:28 PST
Comment on attachment 358371 [details]
Patch

r=me if the bots are happy. Note that it'd be nice if the test checked that the javascript ran without the filter.
Comment 8 Brent Fulgham 2019-01-04 14:52:41 PST
Created attachment 358376 [details]
Patch for landing
Comment 9 WebKit Commit Bot 2019-01-04 15:41:45 PST
The commit-queue encountered the following flaky tests while processing attachment 358376 [details]:

http/wpt/css/css-animations/start-animation-001.html bug 190903 (authors: dino@apple.com, fred.wang@free.fr, and graouts@apple.com)
The commit-queue is continuing to process your patch.
Comment 10 WebKit Commit Bot 2019-01-04 15:42:40 PST
Comment on attachment 358376 [details]
Patch for landing

Clearing flags on attachment: 358376

Committed r239642: <https://trac.webkit.org/changeset/239642>
Comment 11 WebKit Commit Bot 2019-01-04 15:42:42 PST
All reviewed patches have been landed.  Closing bug.