[Webkit-unassigned] [Bug 167093] [URL Parser] ASSERTION FAILED: url == m_string in WebCore::URL::URL

[bugzilla-daemon at webkit.org]

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

--- Comment #9 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Ms2ger from comment #8)
> I guess the question is who's encoding this string in the first place, and
> does *it* think it has a properly canonicalized URL?

We would need a full backtrace to know. The problem is somewhere in the web process, which should canonicalize the URI before sending it to the UI process (right, Alex?), but it's hard to know where the problem is because the backtrace does not show the message type. A backtrace taken with 'bt full' would show the message type, which would allow us some chance at figuring out where the underlying problem is.

That said... there is also a second bug here, which is that the untrusted web process should not be able to crash the UI process by sending a noncanonicalized URI (or any form of garbage). Since ResourceRequestBase::decodeBase is obviously message decoding code, it must assume that it has received invalid or malicious input, and not assert if input is unexpected. This implies that using ParsedURLString anywhere in a message decoder is a security bug. We should audit for this.

(In reply to Frédéric Wang (:fredw) from comment #7)
> I guess a workaround would be to put the url in canonical form:
> 
> URLParser parser(firstPartyForCookies);
> m_firstPartyForCookies = parser.result();
> 
> But is it the proper place to do such a conversion?

I believe yes, using URLParser in the decoder is proper and necessary. But it is not sufficient. There is someplace else where it is needed. Milan, I don't suppose you are still able to reproduce this issue? We'd really need a full backtrace to be able to fix this fully. Otherwise, we'll be able to fix the UI process crash by turning it into a message decode failure, but that's still a serious bug.

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