6

I am having trouble finding information on the implications of using https: and data: as a source

for the directives in a CSP.

Example:

img-src 'self' https: data:;

Could someone some context around what these two sources mean and if there are security issues with using them like this?

ck1221
  • 171
  • 4

2 Answers2

7
Content-Security-Policy: img-src 'self' https: data:;

I would read that out loud as "images can be loaded from the current domain, or any https:// url, or are data:// url".

So having https: basically means that images can be loaded by reference from any 3rd party website. In this day and age, that's basically all websites. So that sorta defeats the purpose of having this directive in the first place.

data: is a bit more subtle; this is intended if you want to embed an image directly into an HTML document; ie you don't want the page to make an external GET to fetch the image. W3Docs give this example which is the data for a 5x5 pixel red dot.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
  //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Embedding an image of any reasonable size will be much larger, for example here is my StackExchange avatar (some random site, not sure if this link will go dead at some point).

So again, allowing data: kinda defeats the whole point of this CSP directive.

What's the point of CSP: img-src anyway?

Content-Security-Policy is generally viewed as a second line of defense against XSS; say an attacker has found a bug in your UI that lets them inject arbitrary javascript into the page that users load; having a tight CSP on your page can sandbox what that malicious javascript can do.

I think the point of the img-src directive is to prevent:

  • Website defacement: embedding images into your page that are unprofessional, lead to phishing, or otherwise damage your website.
  • Exploit vulnerabilities in a client's image parser. Historically there have been, for example, buffer overflows in the Android media parser, and an attacker may be embedding a crafted jpeg on your webpage with the goal of taking over devices of your users.

You'll have to decide for yourself whether the legitimate functionality of your website needs the UI client to be able to load images from arbitrary https URLs, or to directly embed data: encoded images, but if you don't, then you should probably take out those CSP directives in order to maximize the protection you're getting from your CSP.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 1
    That link will certainly go dead (indeed, is already dead) as ezgif does not preserve image data for very long. You could use the permalink form (`https://ezgif.com/image-to-datauri?url=https://example.com/link/to/source/image.png`) instead, though that would be dependent on longevity of the source image link. Maybe `https://ezgif.com/image-to-datauri?url=https://cdn.sstatic.net/Sites/security/Img/logo.png` will last a while. – Bob May 26 '21 at 07:40
  • @Bob Weird, I swear I tried it in a private browser tab first. Oh well, thanks. Updated. – Mike Ounsworth May 26 '21 at 14:54
4

From this documentation of CSP:

<scheme-source>
A scheme such as http: or https:. The colon is required. Unlike other values below, single quotes shouldn't be used. You can also specify data schemes (not recommended).

  • data: Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.
  • ...

As for data: the documentation is already clear about the problems. http: is plain HTTP which is vulnerable to man in the middle attacks which might change the content and introduce attacks this way. https: instead is HTTPS, i.e. end-to-end communication with the server protected against sniffing and manipulation.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    +1, excellent answer, as usual. OP, see https://security.stackexchange.com/questions/94993/is-including-the-data-scheme-in-your-content-security-policy-safe/95011 for more information about the risks of using `data:`. – mti2935 May 25 '21 at 21:42