RESOLVED FIXED 185380
CSP referrer incorrect for document blocked due to violation of its frame-ancestors directive 
https://bugs.webkit.org/show_bug.cgi?id=185380
Summary CSP referrer incorrect for document blocked due to violation of its frame-anc...
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
DetailsFormatted DiffDiff
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.