5

Right now, I maintain the Content-Security-Policy for https://www.lidl.de, which is:

Content-Security-Policy: frame-ancestors 'self'; block-all-mixed-content; report-uri https://lidlcsp.report-uri.io/r/default/csp/enforce;

The part with frame-ancestors is to protect against clickjacking.

When going through the violation reports sent to report-uri.io, the number one is the following,

{
    "csp-report": {
        "blocked-uri": "",
        "document-uri": "https://www.lidl.de/",
        "original-policy": "frame-ancestors https://www.lidl.de; block-all-mixed-content; report-uri https://lidlcsp.report-uri.io/r/default/csp/enforce",
        "violated-directive": "frame-ancestors https://www.lidl.de"
    }
}

which is sent from Firefox (as report-uri.io shows). I'm puzzled on two things here:

  1. Why is this report sent? I can't reproduce it.
  2. Why is the "original policy" altered ('self' vs. https://www.lidl.de)? Does this make any difference?
  3. (EDIT) Why is https://www.lidl.de/ blocked in the following report? The csp explicitly allows iframes on the same site via 'self'.

EDIT: To make the third question a bit clearer I add another csp-report:

{
    "csp-report": {
        "document-uri": "https://www.lidl.de/",
        "effective-directive": "frame-ancestors",
        "original-policy": "frame-ancestors 'self'; block-all-mixed-content; report-uri https://lidlcsp.report-uri.io/r/default/csp/enforce;",
        "blocked-uri": "https://www.lidl.de/"
    }
}

If you can reproduce the CSP violation or can trigger other violations I would be happy to learn about them.

HorstKevin
  • 1,328
  • 2
  • 14
  • 27

1 Answers1

4

Why is the "original policy" altered ('self' vs. https://www.lidl.de)? Does this make any difference?

'self' in the CSP actually stands for "same domain". It is just a placeholder, so this is evaluated by browsers to, in your case, https://www.lidl.de. That's exactly what you say the directive should do, it is just written in another way. So no, it does not make a difference.

Why is this report sent? I can't reproduce it.

I am nearly sure that in 90% of these cases the answer is: browser add-ons. If you really cannot reproduce it with a clean profile and same browser/same site, it is very likely just a browser extension injecting respectively trying to inject some stuff. That is a very common source/trigger for CSP reports.

However, as it is the frame-ancestors directive in your case, you may easily be able to reproduce it. Just create an iframe trying to embed your site:

<iframe height="500" width="500" src="https://www.lidl.de"></iframe>

That should fail, and trigger the CSP report. Because that is what clickjacking is about: Your site getting embedded in another site, in such a way the user does not see it and clicks on things, the user did not want to click on.

I know Report-URI has some filters to prevent such reports caused by browser add-ons, but they still cannot catch all of them.


BTW:

The part with frame-ancestors is to protect against clickjacking.

It does, but you may actually (better, or, even better: additionally) use the header X-Frame-Options for that purpose. This header was designed for that, and also works with browsers, who do not support CSP (it is older, in any case). See the security headers scan from the same author as Report-URI for more details. While you are at it, you may also have a look at the other security headers.

HorstKevin
  • 1,328
  • 2
  • 14
  • 27
rugk
  • 1,237
  • 1
  • 13
  • 25
  • Thanks for your answer! I added another csp report to clarify one question I still have. To me it looks like https://www.lidl.de is trying to load content from https://www.lidl.de but this should be allowed by `frame-ancestors 'self'`. – HorstKevin Nov 07 '17 at 06:40
  • Please don't add new sub-questions via edits. If your question is answered, mark the answer and open a new question. – Tom K. Nov 07 '17 at 12:09
  • You are correct. Given your CSP, the site should allow embedding on itself. I tested this on the homepage using the mentioned iframe sample and the URL `https://www.lidl.de/somesite` (which, of course, 404s, but is displayed); Screen: https://i.imgur.com/fCQY2IF.png Embeeding it on `https://www.test.de` did not work and was blocked by the CSP: https://i.imgur.com/nQkRRkU.png So why you got this other strange CSP report is not clear to me. Maybe arcane add-on/browser combinations. At least the CSP works as expected in my tests. – rugk Nov 07 '17 at 22:36
  • BTW: On your site you also got this violation (triggered by 404 page, as it seems): `Content Security Policy: Unsichere Anfrage 'http://www.lidl.de/de/search?query=somesite&log=not_found' wird blockiert.` (2 times). – rugk Nov 07 '17 at 22:37