Bug 185380

Summary:

CSP referrer incorrect for document blocked due to violation of its frame-ancestors directive

Product:

WebKit

Reporter:

Daniel Bates <dbates>

Component:

WebCore Misc.

Assignee:

Daniel Bates <dbates>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bfulgham, cdumez, ews-watchlist, japhet, mkwst, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

All

OS:

All

See Also:

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

Bug Depends on:

185367

Bug Blocks:

185393

Attachments:

Description	Flags
Patch	none
Archive of layout-test-results from ews206 for win-future	none

Daniel Bates

Reported 2018-05-07 09:59:53 PDT

Similar to bug #185366, the referrer field in the CSP report should be the referrer for the protected document regardless of whether that document was blocked because its frame-ancestors directive was violated.

Attachments
Patch (14.29 KB, patch) 2018-05-07 10:06 PDT, Daniel Bates	no flags	Details Formatted Diff Diff
Archive of layout-test-results from ews206 for win-future (12.75 MB, application/zip) 2018-05-07 12:51 PDT, EWS Watchlist	no flags	Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Daniel Bates

Comment 1 2018-05-07 10:00:34 PDT

Currently whenever we send a CSP report we ask the document's loader (Document::loader()) for the referrer for the last request. Document::loader() returns the loader for the last committed document in its frame. For a frame-ancestors violation, a CSP report is sent before the document that had the frame-ancestors directive has been committed and after it has been associate with a frame. As a result we are in a transient transition state for the frame and hence the last request for the new document's loader (Document::loader()) is actually the last request of the previously loaded document in the frame. Instead we need to take care to tell CSP about the referrer for the request associated with the document the CSP came from.

Daniel Bates

Comment 2 2018-05-07 10:06:15 PDT

Created attachment 339728 [details] Patch This patch depends on the refactoring done in bug #185367.

EWS Watchlist

Comment 3 2018-05-07 12:51:21 PDT

Comment on attachment 339728 [details] Patch Attachment 339728 [details] did not pass win-ews (win): Output: http://webkit-queues.webkit.org/results/7597100 New failing tests: http/tests/security/contentSecurityPolicy/userAgentShadowDOM/allow-audio.html

EWS Watchlist

Comment 4 2018-05-07 12:51:33 PDT

Created attachment 339740 [details] Archive of layout-test-results from ews206 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews206 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

Daniel Bates

Comment 5 2018-05-07 13:52:58 PDT

(In reply to Build Bot from comment #3) > Comment on attachment 339728 [details] > Patch > > Attachment 339728 [details] did not pass win-ews (win): > Output: http://webkit-queues.webkit.org/results/7597100 > > New failing tests: > http/tests/security/contentSecurityPolicy/userAgentShadowDOM/allow-audio.html Similar to my remark in bug 185366, comment 6, I am unclear how this change could cause this failure and the results.html page in the attached archive categorizes this failure as a crash, but no crash log is in the archive.

Brent Fulgham

Comment 6 2018-05-07 16:17:54 PDT

Comment on attachment 339728 [details] Patch r=me.

Daniel Bates

Comment 7 2018-05-07 16:21:16 PDT

Comment on attachment 339728 [details] Patch Clearing flags on attachment: 339728 Committed r231461: <https://trac.webkit.org/changeset/231461>

Daniel Bates

Comment 8 2018-05-07 16:21:17 PDT

All reviewed patches have been landed. Closing bug.

Radar WebKit Bug Importer

Comment 9 2018-05-07 16:23:23 PDT

<rdar://problem/40041421>

Note You need to log in before you can comment on or make changes to this bug.