Bug 234159

Summary: CSP: Always use UTF-8 encoded content when checking hashes
Product: WebKit Reporter: Patrick Griffis <pgriffis>
Component: WebCore Misc.Assignee: Patrick Griffis <pgriffis>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, ews-watchlist, katherine_cheney, mkwst, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=234518
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Patrick Griffis
Reported 2021-12-10 11:18:50 PST
CSP: Always use UTF-8 encoded content when checking hashes
Attachments
Patch (4.31 KB, patch)
2021-12-10 11:19 PST, Patrick Griffis 		no flags
DetailsFormatted DiffDiff
Patch (11.60 KB, patch)
2021-12-11 14:58 PST, Patrick Griffis 		no flags
DetailsFormatted DiffDiff
Patch (11.17 KB, patch)
2021-12-11 14:59 PST, Patrick Griffis 		no flags
DetailsFormatted DiffDiff
Patch (12.56 KB, patch)
2021-12-12 10:23 PST, Patrick Griffis 		no flags
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
Patrick Griffis
Comment 1 2021-12-10 11:19:43 PST
Created attachment 446767 [details] Patch
Patrick Griffis
Comment 2 2021-12-10 11:21:32 PST Comment hidden (obsolete)
Patrick Griffis
Comment 3 2021-12-11 14:58:07 PST
Created attachment 446903 [details] Patch
Patrick Griffis
Comment 4 2021-12-11 14:59:07 PST
Created attachment 446904 [details] Patch
Patrick Griffis
Comment 5 2021-12-11 15:00:01 PST
Still not sure why running the browser directly has different results, however this certainly is more in-line with the spec and passes more WPT tests.
Patrick Griffis
Comment 6 2021-12-12 10:23:11 PST
Created attachment 446935 [details] Patch
Patrick Griffis
Comment 7 2021-12-12 11:49:16 PST
The test failure really only happens when running via WebKit's HTTP server. For example: `hash-always-converted-to-utf-8/iso-8859-1.html` - `wpt serve` succeeds. - https://wpt.live succeeds. - `run-webkit-httpd` fails. So its something specific to how the tests are run. I would assume its not specific to the HTTP server as macOS and GTK have different servers that both fail.
Patrick Griffis
Comment 8 2021-12-12 11:53:31 PST
> So its something specific to how the tests are run. I would assume its not > specific to the HTTP server as macOS and GTK have different servers that > both fail. Sorry forgot to mention that the issue is in the raw data received at the HTTP layer. libsoup logs this as incoming HTTP data: `run-webkit-httpd`: > <!-- ? (micro sign) has the value of 0xB5 in latin-1 and of 0xC2B5 in utf-8 but the hash value should be the same as the utf-8 computed one --> https://wpt.live: > <!-- \xb5 (micro sign) has the value of 0xB5 in latin-1 and of 0xC2B5 in utf-8 but the hash value should be the same as the utf-8 computed one --> So the browser gets already invalid data from the HTTP server.
Radar WebKit Bug Importer
Comment 9 2021-12-17 11:19:17 PST
<rdar://problem/86643075>
Kate Cheney
Comment 10 2021-12-20 10:44:49 PST
Comment on attachment 446935 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=446935&action=review r=me. Could you file a bug about the unexpected http server results? > Source/WebCore/page/csp/ContentSecurityPolicy.cpp:-371 > - // FIXME: Compute the digest with respect to the raw bytes received from the page. We should remember to mark this bug resolved once this patch lands.
EWS
Comment 11 2021-12-20 12:14:07 PST
Committed r287270 (245426@main): <https://commits.webkit.org/245426@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 446935 [details].
Brent Fulgham
Comment 12 2022-02-08 15:50:28 PST
This change should be present in STP 139, iOS 15.4 Beta, and macOS 12.3 Beta.
Note You need to log in before you can comment on or make changes to this bug.