6 ms·

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, magic

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/ 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.

lstamour 9y ago
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. For the details, see https://www.w3.org/TR/CSP3/#report-violation https://www.w3.org/TR/CSP3/#report-violation 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.
johnlbevan2 9y ago
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_directive 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.
- johnlbevan2 9y ago
  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 https://github.com/seek-oss/csp-server (and more: https://github.com/search?utf8=%E2%9C%93&q=csp+report-to https://github.com/search?utf8=%E2%9C%93&q=csp+report-to). Specifics and examples of what `report-to` looks like here: https://wicg.github.io/reporting/#examples https://wicg.github.io/reporting/#examples There's also a nice blog about implementing the old `report-uri` header here: https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-with-content-security-policy-on-gov-uk/ https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-w...
  - johnlbevan2 9y ago
    Here's a nice example of what the report packet looks like: { "@timestamp": "2016-07-07T12:01:03.044Z", "csp-report": { "document-uri": "http://example.com/signup.html", "referrer": "", "blocked-uri": "http://example.com/css/style.css", "violated-directive": "style-src cdn.example.com", "original-policy": "default-src \u0027none\u0027; style-src cdn.example.com; report-uri /_/csp-reports" } } Ref: https://github.com/seek-oss/csp-server/blob/master/example/csp-report-example.json https://github.com/seek-oss/csp-server/blob/master/example/c... 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).
    - 9y ago
s_dev 9y ago
>I'm not trying to be snarky, I'm considering to become a customer. Why would you consider being a customer if you've no idea what they do?
- skrebbel 9y ago
  Because the idea of getting notified every time someone XSS'es my app appeals to me.
js2 9y ago
It's a website for monitoring CSP reports. It is described in step 6 here - https://www.troyhunt.com/the-6-step-happy-path-to-https/ https://www.troyhunt.com/the-6-step-happy-path-to-https/
wietze 9y ago
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. 1: https://tools.ietf.org/html/rfc7469#section-2.1.4 https://tools.ietf.org/html/rfc7469#section-2.1.4 2: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers https://www.owasp.org/index.php/OWASP_Secure_Headers_Project...

lstamour 9y ago

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. For the details, see https://www.w3.org/TR/CSP3/#report-violation https://www.w3.org/TR/CSP3/#report-violation 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.

johnlbevan2 9y ago

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_directive 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.

johnlbevan2 9y ago
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 https://github.com/seek-oss/csp-server (and more: https://github.com/search?utf8=%E2%9C%93&q=csp+report-to https://github.com/search?utf8=%E2%9C%93&q=csp+report-to). Specifics and examples of what `report-to` looks like here: https://wicg.github.io/reporting/#examples https://wicg.github.io/reporting/#examples There's also a nice blog about implementing the old `report-uri` header here: https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-with-content-security-policy-on-gov-uk/ https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-w...
- johnlbevan2 9y ago
  Here's a nice example of what the report packet looks like: { "@timestamp": "2016-07-07T12:01:03.044Z", "csp-report": { "document-uri": "http://example.com/signup.html", "referrer": "", "blocked-uri": "http://example.com/css/style.css", "violated-directive": "style-src cdn.example.com", "original-policy": "default-src \u0027none\u0027; style-src cdn.example.com; report-uri /_/csp-reports" } } Ref: https://github.com/seek-oss/csp-server/blob/master/example/csp-report-example.json https://github.com/seek-oss/csp-server/blob/master/example/c... 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).
  - 9y ago

s_dev 9y ago

>I'm not trying to be snarky, I'm considering to become a customer. Why would you consider being a customer if you've no idea what they do?

skrebbel 9y ago
Because the idea of getting notified every time someone XSS'es my app appeals to me.

js2 9y ago

It's a website for monitoring CSP reports. It is described in step 6 here - https://www.troyhunt.com/the-6-step-happy-path-to-https/ https://www.troyhunt.com/the-6-step-happy-path-to-https/

wietze 9y ago

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. 1: https://tools.ietf.org/html/rfc7469#section-2.1.4 https://tools.ietf.org/html/rfc7469#section-2.1.4 2: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers https://www.owasp.org/index.php/OWASP_Secure_Headers_Project...