Firefox 108 issues with IDP 4.x w/ strict CSP

[Dan McLaughlin]

Correction to the last sentence... "if 'unsafe-inline' is NOT in the
CSP and there is any embedded javascript,
you must not load the script."

--

Thanks,

Dan


On Wed, Dec 21, 2022 at 8:13 AM Dan McLaughlin
<dmclaughlin at tech-consortium.com> wrote:
>
> I did some more research this morning, and the problem is that Firefox
> 108 has broken 'unsafe-hashes'; it's actually just ignoring the
> 'unsafe-hashes'.  We already had 'unsafe-hashes'
> 'sha256-ePniVEkSivX/c7XWBGafqh8tSpiRrKiqYeqbG7N1TOE=' which works for
> every browser except Firefox 108, and we've had it like this for over
> a year.  I've had to re-enable 'unsafe-inline' for now.  Luckily IDP 5
> works regardless, so this won't be an issue in the coming IDP 5
> release.  I'm going to open a bug report against Firefox 108, letting
> them know they broke 'unsafe-hashes'.   My interpretation of the fix
> they put in leads me to believe that they don't care that they broke
> it because they quote the CSP specification, which apparently states
> if 'unsafe-inline' is in the CSP and there is any embedded javascript,
> you must not load the script.
>
> --
>
> Thanks,
>
> Dan
>
>
> On Wed, Dec 21, 2022 at 7:29 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
> >
> > Trying to support CSP would mean trying to exbed all the Javascript (inline won't really work), and there are no portable/tractable ways to do that. The code turns into a giant mess of different event handling in different browsers. So that's why there are no Javascript-related CSP headers configured into it by default.
> >
> > Obviously the templates are fully overrideable (even the eventual SAML binding template, remember that also includes Javascript), so if somebody wants to go nuts, it's not prevented.
> >
> > -- Scott
> >
> >