8000 WebProfiler CSP can be broken by 3.4.40 · Issue #36643 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

WebProfiler CSP can be broken by 3.4.40 #36643

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
cs278 opened this issue Apr 30, 2020 · 3 comments
Closed

WebProfiler CSP can be broken by 3.4.40 #36643

cs278 opened this issue Apr 30, 2020 · 3 comments
Labels
Bug Status: Needs Review WebProfilerBundle

Comments

@cs278
Copy link
Contributor
cs278 commented Apr 30, 2020 •
edited
Loading

Symfony version(s) affected: 3.4.40

Description
A change introduced in 3.4.40, can break content security policy when using the toolbar: #36315

The problem is that Symfony now sets {script,style}-src-elem which overrides {script,style}-src, I'll stick with referencing styles but the same problem exists from scripts.

How to reproduce

Given a simple policy of default-src https://example.com; style-src 'self', this permits CSS to be loaded from a file on the same origin.

$response->headers->set('Content-Security-Policy', "default-src https://example.com; style-src 'self'");

When the toolbar is enabled Symfony changes the policy to (I removed the script policies for simplicity):

default-src https://google.com; style-src 'self' 'unsafe-inline' 'nonce-123'; style-src-elem https://google.com 'unsafe-inline' 'nonce-123'

This now blocks CSS being loaded as style-src-elem overrides style-src and does not permit 'self'.

Possible Solution

If style-src-elem does not exist and style-src exists either:

  • Do not create it
  • Copy the style-src directives like is done from default-src

And apply the same fix for scripts.

Additional context

Whilst investigating this I found another bug with the way the 'none' token is handled: #36645
@cs278 cs278 added the Bug label Apr 30, 2020
@cs278 cs278 mentioned this issue Apr 30, 2020
Closed
@stof
Copy link
Member
stof commented Apr 30, 2020

We should indeed not create the new *-elem rules if they don't exist. Browsers will fallback from them to the older ones.

@nicolas-grekas nicolas-grekas mentioned this issue May 1, 2020
Closed
@nicolas-grekas
Copy link
Member

@cs278 up for a PR? Anyone else? @ampaze maybe? Same for #36645

This was referenced May 4, 2020
Open
Merged
@ndench
Copy link
Contributor
ndench commented May 4, 2020

@nicolas-grekas I've done up a quick PR for this #36678

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Status: Needs Review WebProfilerBundle
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@cs278 @nicolas-grekas @stof @xabbuh @ndench @carsonbot
0