I don't get it. What does Report URI do? Their landing page doesn't say. And Troy Hunt's blog post tells me this:
* Set up CSP headers
* Somehow, magically, Report URI will tell you things
Wait what? How does that work? I feel like I'm missing a step. Unfortunately https://report-uri.com/ doesn't really explain either, or have integration docs of any kind.
I'm not trying to be snarky, I'm considering to become a customer.
To get this reporting to work, you need an HTTP header in place.
Historically (fairly short term history) this was "report-uri"; hence the name of their product... however this has since been replaced by "report-to". More information on these headers can be found here: https://developer.mozilla.org/en-US/docs/Glossary/Reporting_... (at time of writing the `report-to` documentation is pending)...
Steps:
- User's browser loads your page
- User's browser detects something which would be a violation of your CSP policies
- User's browser blocks that content...
- ...and also checks for a Report-To, Report-URI, or CSP-Report header in the HTTP Headers.
- If any of those headers exist, the user's browser makes an http post to the stated URL,
passing information about the problem.
- If the URL stated in those headers was the Report-URI.com service's URL (i.e. the service which
Troy Hunt's writing about) then their company receives this data, and can use the information
in that to determine that this report relates to your website (i.e. from the info in the
`document-uri` field), and store this information in the metrics they provide for your site.
ps. You could implement your own functionality to collect these reports. The Report-URI product (as opposed to header) is just a pre-written service to save you rolling your own. You just need to build something to receive the HTTP POST statements and do something with the data. Or you look on GitHub and find someone's done that for you: https://github.com/seek-oss/csp-server (and more: https://github.com/search?utf8=%E2%9C%93&q=csp+report-to).
I don't know what's in place (if anything) to prevent sending fake reports... i.e. presumably a hacker could read these headers from a site, then send HTTP POST messages reporting all kinds of errors from various IPs (e.g. if they have access to compromised machines), flooding your useful metrics with false data, thus hiding any useful information in there...
Better than the current protocol, you'd have your site generate an ID for every legitimate request so that any reports could be tied back to that... but even then any hacker would just need to call your site once per false report to get that ID, so this only offers a small amount of additional protection (though in doing so increases the probability of the site being targeted by a flooding / DoS attack).
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?
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).
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.
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.
To the extent that this is an issue, the server could presumably sign the document uri plus some nonce and include that signature and the nonce in the report-to uri.
A service like Report URI could trivially validate if the nonce approach were understood.
I know and I completely disagree with that decision.
HPKP has a place. Checking CA logs (via Expect-CT header) is bullshit because when the stakes are high enough some CA can get hacked or some low level sysadmin can verify domain control somehow and register a cert and some actor can MITM connections without anyone noticing for months.
With HPKP the fucking page doesn't load. Period. You need to either root the server or use a PDA to stop HTTPS in the first place, but then the browser bar isn't green. If the costs of getting MITMed are high it is better to risk lockout than it is to risk silent data loss.
At the very, very least I should be able to pin which CAs I trust so the threat vector doesn't include every CA in the world.
The Expect-CT header is good enough for most people, but HPKP should be supported if needed.
This always seemed backwards to me. If the worry is that certs are being misissued, why on earth are we assuming that such CAs are following the rulebook?
No, the browser should check the CAA record and refuse to trust certs issued by the wrong CA.
This would only make sense under the assumption that the DNS response can be trusted. For the vast majority of domains and resolvers, that would not be the case. (I'm skipping the discussion of whether you'd want to trust DNSSEC at all.)
The idea you're describing has been standardized as DANE, which has failed to gain any adoption. It would not make sense for CAA to try to do the same thing. Instead, it set out to provide a defense-in-depth mechanism for certain CA vulnerabilities that fall short of a full compromise.
I hate this, too, and would love to be able to use HPKP in the future, too.
But I’ve long accepted that Google will simply drop functionality without reason even when people still depend on it, just because they can, and that they’re deaf to all complaints.
You can set CSP headers that browsers will read for content security policy (to prevent or notice unusual content includes or sources). There can be two consequences: violations can be blocked, or they can load but get reported in console. If a URL is set in the CSP header, the browser can report the violations to another URL for inspection and tracking.
Like error tracking, the tricky bit isn’t always the reporting, it can also be learning to ignore errors caused by extensions, or grouping and alerting on issues in report-only mode such that they can be fixed in a timely fashion. That said, even knowing what to use as a CSP header can be daunting, so there’s plenty of room to make this powerful security feature easier to use.
For how Report URI works in your browser, see the original RFC [1] from 2015. The OWASP recommendation for HTTP Security Headers [2] gives some useful extra information on the how the HTTP Security headers hang together.
If you don't know who is Troy Hunt, then one thing to do right now is to signup for his great service: https://haveibeenpwned.com/
in essence, everytime(+) some massive break occurs, and your e-mail (and probably password) is among them after reaching "darknet" (meaning black market), you will get from haveibeenpwned an e-mail, urging you to some action (password change, account closure/change etc).
(+) Troy amassed over the years huge db of past breakins (so you can check your email presence also in past events) and with current respect/reputation he gots access to new ones pretty fast, informing you instantly in most cases.
> with current respect/reputation he gets access to new ones pretty fast, informing you instantly in most cases
So he has the respect of (street cred with?) the dark net/black market folks and that's how he gets them instantly? Or I suspect you meant to say something slightly different?
Report URI appears to depend on CSPs being submitted. There was recently a discussion about uBlock Origin blocking CSPs on privacy grounds. [0]
So this will only work for sites that use CSP and users who don't have uBlock Origin installed, unless uBlock Origin changes their default policy on CSPs.
ninja edit: I see uBlock Origin has changed their defaults to permit CSP submission [1]
Troy very publicly carrying water for Scott Helme/Report URI looks quite a bit different in hindsight, as the number of Report URI marketers doubles to 2.
The uBlock Origin dev compromised with an opt-out for CSP reports, even though they can be used for things like IP address leaks to 3rd party servers (similar to the as-seen-in-court Tor-busting captcha mess). Personally I would prefer only same-origin reports.
--
My biggest problem in all of this is that Scott was not careful to always document his not-quite-obvious conflict of interest, and even worse: Troy's association is only now being revealed weeks later. I do appreciate the work being done to improve the effectiveness of CSP reports in default configurations of open source tools, but can't help wondering about the motivation. Disclaimers go a long way toward keeping unsuspecting maintainers informed of both sides of an issue.
Scott was also blamed here on HN last week for his part in promoting the death of HKHP (public key pinning) apparently due to ease of misconfiguration.
Looking back now I'm left wondering how HKHP affected Report URI and Scott's other project, Security Headers. I will disclose my bias as I watch highly effective marketing of convenience (top of HN!) triumph over my personal flavor of slightly paranoid privacy yet again.
I don't understand the argument that it's bad because it leaks the IP address to a third party. So would embedding any other resource hosted on a different domain - from JavaScript CDNs to images. No one is suggesting these should be blocked, right?
I have no problem with uBlock blocking requests to the CSP report-uri if the domain in question is on the user's filter list (I'd probably consider it a bug if it didn't do that), but that's not what is happening here (before this was fixed, that is).
The Tor-captcha-thing was about leaking the origin IP of the Hidden Service, so I don't see how it's similar.
It is 100% clear to me that differences of opinion will result in drawing the line on an ad blocker's default configuration in different places.
Would you mind sharing how long your browser was sending CSP reports to 3rd parties before you knew about it? I personally was unaware [edit]this could happen to me in Chrome with uBlock Origin installed[/edit] until this issue came up, and a free pass through ad blockers to a 3rd party seems like an advertising/tracking company's dream come true.
> JavaScript CDNs to images. No one is suggesting these should be blocked, right?
Many of these [edit](specifically: tracking pixels and just straight up ad images)[/edit] are blocked by ad blockers in the default configuration.
> The Tor-captcha-thing was about leaking the origin IP of the Hidden Service, so I don't see how it's similar.
Thank you for the correction. I apparently imagined this referenced when partial VPN or Tor is insecurely used only to access specific domains, or DNS is not also routed through.
> Would you mind sharing how long your browser was sending CSP reports to 3rd parties before you knew about it?
I'm not sure what you're asking - when did I become aware of this possibility? I guess when I learned about CSP?
> I personally was unaware this was possible until this issue came up, and a free pass through ad blockers to a 3rd party seems like an advertising/tracking company's dream come true.
Adblockers block requests to things like Google Analytics by matching the domain (and other patterns). Why is this not an acceptable solution for CSP? If tracking tools start using CSP for this, they'll be added to the filter lists, just like any other tracking script. We're not asking uBlock to block all third-party requests on the off-chance it might be an ad or tracking service, so why would we do that for CSP?
> Many of these are blocked by ad blockers in the default configuration.
Do you have a source for this? This would break a large number of sites. uBlock seems to have an experimental feature that mirrors certain popular CDN URLs locally, but it doesn't seem to be enabled by default and the Wiki page hasn't been updated in over two years. AIUI, even with this feature enabled, requests to non-popular (non-local) assets would still go through.
> Why is this not an acceptable solution for CSP? If tracking tools start using CSP for this, they'll be added to the filter lists, just like any other tracking script. We're not asking uBlock to block all third-party requests on the off-chance it might be an ad or tracking service
This is a good question! When a new technology arrives that allows tracking, I prefer uBlock default to blocking it. Advertising/tracking companies pursue the bleeding edge in their cat & mouse game; this way the barn door is closed before the horse leaves (two too many animal analogies?). I do understand that others will pursue a different choice, and encourage disclosure by those doing so because money is on the line.
The discussion regarding CSP has resulted in a change in uBlock's default behavior which I will take into consideration the next time I re-evaluate which ad blocker to use.
PS. In case it's not clear, I originally commented: >Personally I would prefer only same-origin reports.
PPS. This is a much jucier target assuming it works when JavaScript is disabled.
Just a quick clarification:
uBlock Origin only blocks CSP reports if it has injected "neutered" scripts into a page - typically if the site uses some third party scripts like GA. Because these neutered scripts might create extra CSP reports, which would then leak data about the client.
If the site only uses first party scripts, CSP reports are very unlikely to be affected by any version of uBlock Origin.
Also, uBlock doesn't block any CSPs. Only some CSP reports.
Luckily, the next version of uBlock will let us block CSP reports alltogether.
If CSP reports become a reliable way to gather data, they _will_ be used for tracking. This is why we can't have nice things. And why I have to disable all nice things we do have, in my browser.
Ok... So... i just signed up, and it walked me though some steps. Verify Email: Done, Customize (change reporting URL): Done... Configure: (change some domain filters)... Done... 2FA: Done... but how do i actually set this up?! like, what do i need to put on my site to enable this?! WTF?! is this done at a page level? (HTML inserted into the page) is it at a server level (Nginx, Apache?) Or is it done somewhere else?! where do i set this up?! more digging required, but it would have been handy to have a guide for what i need to install...
But yeah, it seems like they could really use some instructions on how to set this up for people unfamiliar with how the Web Reporting API works. The documentation you're looking for is here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
> Though the report-to directive is intended to replace the deprecated report-uri directive, report-to isn’t supported in most browsers yet.
So it's deprecated, but until it's replaced by report-to (which works in a very similar way) report-uri is still the proper way to make this feature work.
I would have linked to report-to instead, but MDN doesn't have good documentation on that yet.
There was a particular domain that, when queried at most whois services, would play the harlem shake in your browser. It worked nearly everywhere that did such lookups.
I used to do this with because I found that some web performance scanners would usually forget to escape the content of the HTTP headers. After sending this domain [1] some of them would immediately execute the script. Feel free to send a HEAD request to this website so you can understand better, it's basically the same thing as with the TXT DNS records.
There's nothing to gain from exhausting someone else's quota. People will go to great lengths to exploit anything for profit, but just messing with other people without anything to gain personally -- that's not a good motivation.
Is it really a failure if X-Frame-Options header is missing on a blog? If it is a failure then why not just make it not possible to use iframes at the browser level.
Without context, this service misrepresents the real security of any given site.
To be fair, the challenge of nearly all security assessment tools, including Security Headers, is they don't understand the context of what they are assessing. X-Frame-Options on a blog isn't a big deal. X-Frame-Options on a SaaS app can be. That's why blindly scanning something and then saying "look at all these vulnerabilities" is a pretty poor way to assess the security of a service.
Is the HPKP he mentions as a security measure the same public key pinning chrome did just announce the deprecation date, because it is too risky to do; or are these different concepts?
I'm not trying to be snarky, I'm considering to become a customer.