Added additional CSP contents to enable videojs and ipcamera binding

[digitaldan]

Signed-off-by: Dan Cunningham dan@digitaldan.com

i was not able to load m3u8/ts content from our ipcamera binding with the new video widget as the CSP policy was blocking the media being loaded as well as blocking a web worker from doing something (might be in the videojs library?) .

The camera binding runs the HLS stream for cameras on different ports, so camera 1 might have a http dash stream on 10001, camera2 on 10002, and so on , which the browser will treat as different domains i believe. I'm no expert on CSP policy so i don't know if the exceptions in this PR create a meaningful security hole.

I personally would rather have a bit more relaxed CSP policy to load external content since the UI is not normally exposed unauthenticated (by firewall, the cloud service, etc..)

[ghys]

Thanks for the investigation!
What I don't understand is that according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src the allowed sources are used for directives that aren't specified explicitly, including media-src and worker-src, so this shouldn't be necessary in theory as the default-src is already pretty lax... I have been able to use videos on random websites in the video widget and never got CSP issues.

[digitaldan]

Here is my setup and the exact error i get without the additional csp content

 - component: oh-video-card
          config:
            type: application/x-mpegurl
            title: Front Drive
            item: CameraFrontDrivewayHLS

the item CameraFrontDrivewayHLS is set to: http://192.168.100.15:11002/ipcamera.m3u8

when the page loads i get these in the log, and the video never loads:

Refused to create a worker from 'blob:http://oh:8080/55741f13-85e1-4327-8674-93e844e6efbc' because it violates the following Content Security Policy directive: "default-src * 'self' 'unsafe-inline' 'unsafe-eval' data: gap: content:". Note that 'worker-src' was not explicitly set, so 'default-src' is used as a fallback.

Refused to load media from 'blob:<URL>' because it violates the following Content Security Policy directive: "default-src * 'self' 'unsafe-inline' 'unsafe-eval' data: gap: content:". Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.

VIDEOJS: ERROR: (CODE:4 MEDIA_ERR_SRC_NOT_SUPPORTED) The media could not be loaded, either because the server or network failed or because the format is not supported. zi {code: 4, message: "The media could not be loaded, either because the …rk failed or because the format is not supported."}

after adding the additional CSP tags, the content loads as expected.

Thanks!

[ghys]

Interesting, must be a video.js implementation technique to use blob: urls sometimes but not always. So maybe simply adding blob: to the default-src part would be enough?

[ghys]

Does this work?

Suggested change

	<meta http-equiv="Content-Security-Policy" content="default-src * 'self' 'unsafe-inline' 'unsafe-eval' data: gap: content:; media-src * blob:; worker-src * blob:">
	<meta http-equiv="Content-Security-Policy" content="default-src * 'self' 'unsafe-inline' 'unsafe-eval' data: gap: content: blob:">

Perhaps allowing blob: could also be valuable for images and so on so no harm in allowing them by default.
At some point I'll probably look after having a same-origin policy for scripts and CSS to mitigate importing malicious external libraries, maybe disable unsafe-eval too if it's not required.

[digitaldan]

Yes, that works! I updated the PR with your change.

[ghys]

Thanks!