webRequest: CSP report requests have tab/frame ID -1
Reported by
ch...@chrisn.me.uk,
Aug 11 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Install the demo extension (files attached), which prints webRequest events to the console. 2. Open the extension's background page. 3. Visit the MWE at https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/ - this page contains an image whose loading is blocked because it violates the document's Content-Security-Policy HTTP header, and a violation report is sent to csp-report.cgi. 4. Note that the webRequest event data for the request to csp-report.cgi is missing tab and frame ID information: webRequest.onBeforeRequest: {"0":{"frameId":-1,"method":"POST","parentFrameId":-1,"requestId":"188","tabId":-1,"timeStamp":1470938753548.9832,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} What is the expected behavior? The webRequest event data for the request to csp-report.cgi should have non-negative tab and frame IDs. What went wrong? A CSP violation occurs because of disallowed resource-loading activity in a particular frame. The CSP itself is defined in the HTTP header of a response that served the document displayed in that frame; it therefore makes sense that the webRequest activity for any CSP violation report should be annotated with the IDs of the tab and frame from which the violation originated. Did this work before? No Chrome version: 52.0.2743.116 Channel: stable OS Version: Flash Version: Shockwave Flash 22.0 r0 The webRequest resource type for the CSP report is currently "ping" - it'd be nice if this string could be more specific ("csp_report", perhaps?), since the resource type "ping" is also used for requests for completely different resources such as trackback requests for <a ping>.
,
Aug 14 2016
Type "ping" is unexpected, it should have been "other", I opened issue 637577 for that. But frameId and tabId are set, as expected (the underlying logic is the same for ping and beacon requests, which was implemented in bug 522124 ). And because of the same logic, bug 522129 also applies to CSP violation reports. webRequest.onBeforeRequest: {"0":{"frameId":0,"method":"POST","parentFrameId":-1,"requestId":"62","tabId":7,"timeStamp":1471138593229.511,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} background.js:4 webRequest.onBeforeSendHeaders: {"0":{"frameId":0,"method":"POST","parentFrameId":-1,"requestId":"62","tabId":7,"timeStamp":1471138593229.6702,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} background.js:4 webRequest.onSendHeaders: {"0":{"frameId":0,"method":"POST","parentFrameId":-1,"requestId":"62","tabId":7,"timeStamp":1471138593229.7202,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} background.js:4 webRequest.onHeadersReceived: {"0":{"frameId":0,"method":"POST","parentFrameId":-1,"requestId":"61","statusCode":204,"statusLine":"HTTP/1.1 204 No Content","tabId":7,"timeStamp":1471138593423.497,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} background.js:4 webRequest.onResponseStarted: {"0":{"frameId":0,"fromCache":false,"ip":"146.169.13.11","method":"POST","parentFrameId":-1,"requestId":"61","statusCode":204,"statusLine":"HTTP/1.1 204 No Content","tabId":7,"timeStamp":1471138593423.6282,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} background.js:4 webRequest.onCompleted: {"0":{"frameId":0,"fromCache":false,"ip":"146.169.13.11","method":"POST","parentFrameId":-1,"requestId":"61","statusCode":204,"statusLine":"HTTP/1.1 204 No Content","tabId":7,"timeStamp":1471138593423.898,"type":"ping","url":"https://www.doc.ic.ac.uk/~cnovakov/chromium/webrequest_csp_violation/csp-report.cgi"}} |
||
►
Sign in to add a comment |
||
Comment 1 by tkonch...@chromium.org
, Aug 12 2016