4 ms·

I haven't opened the ReportURI webpage, but I would assume their value added compared to DIY is exactly in spam-filtering and solving (or mitigating) all the se

I haven't opened the ReportURI webpage, but I would assume their value added compared to DIY is exactly in spam-filtering and solving (or mitigating) all the security issues that report-uri (the header) inserts itself. Call me cynical, but I believe reporting causes more harm than good, by exposing new attack surface. Why not just deploy a crawler that detects CSP errors and reports them in a static report for the site owner?

johnlbevan2 9y ago
Good point on ReportURI having better abilities to detect false reports. It's not mentioned (at least, not on the front page; I've not delved), but definitely their larger dataset will make it much simpler to blacklist IPs suspected of sending faked reports / spotting patterns to remove false data. I believe the benefit of having users' browsers report this over a crawler is for scenarios where pages attempt to display your content from another site (e.g. in an iframe behind an overlay for a click-jacking attack). You'd never know to monitor that URL / wouldn't know that the site was hosting your content from any of your metrics; but the users browsers would report it. In terms of "why report it if they know to block it anyway", I believe the idea is to improve security for others; i.e. we're no longer relying on users having the latest browser to be protected; so long as one user had a browser good enough to spot the issue, we can be made aware that there's a risk out there.
Ajedi32 9y ago
CSP violations (such as XSS vulnerabilities) can manifest themselves on non-public pages, where they'd be difficult to detect with a crawler. In addition, the Web Reporting API covers more than just CSP. It can also report various types of certificate errors, such as those triggered by violations of the Expect-CT and Expect-Staple headers (such violations might occur if your users are under attack by a MITM).
- dullgiulio 9y ago
  I imagine you realize that a user under MITM would have the report POST request tampered? It's false security. On the other hand, you are right that the crawler wouldn't catch everything.
  - pfg 9y ago
    I'm not certain what the implementation status is in various browsers, but the relevant RFCs (e.g. for HPKP) typically recommend that user agents retry the submission of reports. The report URIs themselves may also use HPKP to prevent them from being intercepted (as opposed to just DoSing the submission). There are certainly scenarios where an attacker can only temporarily MitM the victim and the reporting mechanism would still be of use eventually. The reporting itself is not the enforcing mechanism, so timely submission is not the most important thing in the event of an attack. That said, it's true that the biggest practical use people get out of report-uri is to test the roll-out of these headers and to detect issues they might cause.

johnlbevan2 9y ago

Good point on ReportURI having better abilities to detect false reports. It's not mentioned (at least, not on the front page; I've not delved), but definitely their larger dataset will make it much simpler to blacklist IPs suspected of sending faked reports / spotting patterns to remove false data. I believe the benefit of having users' browsers report this over a crawler is for scenarios where pages attempt to display your content from another site (e.g. in an iframe behind an overlay for a click-jacking attack). You'd never know to monitor that URL / wouldn't know that the site was hosting your content from any of your metrics; but the users browsers would report it. In terms of "why report it if they know to block it anyway", I believe the idea is to improve security for others; i.e. we're no longer relying on users having the latest browser to be protected; so long as one user had a browser good enough to spot the issue, we can be made aware that there's a risk out there.

Ajedi32 9y ago

CSP violations (such as XSS vulnerabilities) can manifest themselves on non-public pages, where they'd be difficult to detect with a crawler. In addition, the Web Reporting API covers more than just CSP. It can also report various types of certificate errors, such as those triggered by violations of the Expect-CT and Expect-Staple headers (such violations might occur if your users are under attack by a MITM).

dullgiulio 9y ago
I imagine you realize that a user under MITM would have the report POST request tampered? It's false security. On the other hand, you are right that the crawler wouldn't catch everything.
- pfg 9y ago
  I'm not certain what the implementation status is in various browsers, but the relevant RFCs (e.g. for HPKP) typically recommend that user agents retry the submission of reports. The report URIs themselves may also use HPKP to prevent them from being intercepted (as opposed to just DoSing the submission). There are certainly scenarios where an attacker can only temporarily MitM the victim and the reporting mechanism would still be of use eventually. The reporting itself is not the enforcing mechanism, so timely submission is not the most important thing in the event of an attack. That said, it's true that the biggest practical use people get out of report-uri is to test the roll-out of these headers and to detect issues they might cause.