Bug 158388

Summary: upgrade-insecure-requests is applied after other CSP directives potentially blocking resource before upgrade is applied
Product: WebKit Reporter: Zack Tollman <tollmanz>
Component: New BugsAssignee: Brent Fulgham <bfulgham>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: bfulgham, dbates, mcatanzaro, mike, scotthelme, tollmanz, wilander
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Simple test case none

Zack Tollman
Reported 2016-06-04 19:16:41 PDT
With the implementation of `upgrade-insecure-requests` in r201679, the `upgrade-insecure-requests` directive appears to be applied *after* other directives are applied, potentially blocking resources before the upgrade can be applied. To reproduce: 1. Generate a page with the following CSP header: `default-src https:; upgrade-insecure-requests` 2. Create a HTML page, protected by the CSP in step1, that contains an `img` tag with a `src` attribute pointing to an HTTP resource, that can successfully be upgraded to an HTTPS resource via `upgrade-insecure-requests`. The following HTML document meets these requirements: ``` <html> <head> </head> <body> <img src="http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150" /> </body> </html> ``` 3. Load this page in Webkit Nightly Build and observe results 4. Change the CSP header to `upgrade-insecure-requests` 5. Load this page in Webkit Nightly Build and observe results Expected behavior: The `http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150` resource should be upgraded to `https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150` and displayed without warning. Observing this test in stable Chrome and Firefox results in the desired upgrade behavior. What happened: The image is not displayed on the page at step #3, but is displayed for step #5, suggesting that UIR is working and is applied only after the `default-src` (and presumably other directives) are applied, leading to blocking the resource. The following errors are shown in the console in step #3: [Error] Unrecognized Content-Security-Policy directive 'upgrade-insecure-requests'. Refused to load the image 'http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150' because it violates the following Content Security Policy directive: "default-src https:". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback. Note that the "Unrecognized CSP..." error displays on some loads, but not others. If you continually refresh, you should be able to observe it; however, the image is always blocked.
Attachments
Simple test case (233 bytes, text/html)
2016-06-05 14:57 PDT, Brent Fulgham 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Brent Fulgham
Comment 1 2016-06-05 14:57:20 PDT
Created attachment 280561 [details] Simple test case
Brent Fulgham
Comment 2 2016-06-05 14:58:15 PDT
I'm not able to reproduce the behavior you are describing using the attached test case, where the CSP rules are in a <meta> tag. Are you performing your tests by modifying the actual server headers?
Zack Tollman
Comment 3 2016-06-05 15:18:30 PDT
Yep. My testing used response headers to set the CSP. I double checked and still can produce the issue with the latest nightly (r201698). I can also reproduce the issue using the test case you uploaded.
Brent Fulgham
Comment 4 2016-06-05 15:20:09 PDT
I can't reproduce with these changes to our test Apache configuration: Index: apache2.4-httpd.conf =================================================================== --- apache2.4-httpd.conf (revision 201701) +++ apache2.4-httpd.conf (working copy) @@ -37,6 +37,7 @@ ServerName 127.0.0.1 <Directory /> + Header set Content-Security-Policy "default-src https:; upgrade-insecure-requests" Options Indexes FollowSymLinks MultiViews ExecCGI Includes AllowOverride All Order allow,deny @@ -144,6 +145,7 @@ <VirtualHost *:8443> ServerName 127.0.0.1 SSLEngine On + Header set Content-Security-Policy "default-src https:; upgrade-insecure-requests" </VirtualHost> #
Brent Fulgham
Comment 5 2016-06-05 15:40:04 PDT
(In reply to comment #3) > Yep. My testing used response headers to set the CSP. I double checked and > still can produce the issue with the latest nightly (r201698). > > I can also reproduce the issue using the test case you uploaded. Do you have a test server I could connect to? I'm having no luck reproducing things, but it's very possible I don't have things set up properly in my test environment.
Brent Fulgham
Comment 6 2016-06-05 15:42:38 PDT
(In reply to comment #0) > [Error] Unrecognized Content-Security-Policy directive > 'upgrade-insecure-requests'. This is very surprising if you are running a correct nightly. I would expect it to either always fail, or always succeed! [...] > Note that the "Unrecognized CSP..." error displays on some loads, but not > others. If you continually refresh, you should be able to observe it; > however, the image is always blocked. So strange! Are you reproducing this by simply pressing the "reload" button on the URL bar?
Zack Tollman
Comment 7 2016-06-05 15:47:51 PDT
> Do you have a test server I could connect to? I'm having no luck reproducing things, but it's very possible I don't have things set up properly in my test environment. Brent - you can test here: https://test-run-dot-csp-unit.appspot.com/tests/1f98bd31-e227-444c-b4b6-1ac98df19dd3. Note that this test case will work right now, but may not be available in the future. I think you are actively working on this right now, so hopefully you can test. > This is very surprising if you are running a correct nightly. I would expect it to either always fail, or always succeed! To be clear, I *always* get the failure, but only sometimes am I seeing the console notice about UIR. > So strange! Are you reproducing this by simply pressing the "reload" button on the URL bar? Yes. It is definitely weird. Just to doublecheck that I'm reviewing the correct software, is this the correct URL to download the latest nightly: r201698.dmg">http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r201698.dmg?
Brent Fulgham
Comment 8 2016-06-05 16:30:18 PDT
(In reply to comment #7) > Just to doublecheck that I'm reviewing the correct software, is this the > correct URL to download the latest nightly: > r201698.dmg">http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r201698.dmg? That should be correct. However, I'm having trouble running any nightlies at the moment for some reason. I'll see if I can figure out whats going on.
Brent Fulgham
Comment 9 2016-06-06 09:02:54 PDT
(In reply to comment #7) > > Do you have a test server I could connect to? I'm having no luck reproducing things, but it's very possible I don't have things set up properly in my test environment. > > Brent - you can test here: > https://test-run-dot-csp-unit.appspot.com/tests/1f98bd31-e227-444c-b4b6- > 1ac98df19dd3. Note that this test case will work right now, but may not be > available in the future. I think you are actively working on this right now, > so hopefully you can test. I tried this on a fresh El Capitain (10.11.5) OS install with the nightly based on r201707, and still cannot reproduce. Are you perhaps using a different base OS? Maybe I have an OS-specific issue?
Brent Fulgham
Comment 10 2016-06-06 09:13:29 PDT
(In reply to comment #9) > Are you perhaps using a different base OS? Maybe I have an OS-specific issue? Just to answer myself: I suspect not, since I don't believe nightlies run on anything but El Capitain.
Zack Tollman
Comment 11 2016-06-06 09:25:47 PDT
(In reply to comment #9) > (In reply to comment #7) > > > Do you have a test server I could connect to? I'm having no luck reproducing things, but it's very possible I don't have things set up properly in my test environment. > > > > Brent - you can test here: > > https://test-run-dot-csp-unit.appspot.com/tests/1f98bd31-e227-444c-b4b6- > > 1ac98df19dd3. Note that this test case will work right now, but may not be > > available in the future. I think you are actively working on this right now, > > so hopefully you can test. > > I tried this on a fresh El Capitain (10.11.5) OS install with the nightly > based on r201707, and still cannot reproduce. > > Are you perhaps using a different base OS? Maybe I have an OS-specific issue? I'm running 10.11.4. I'll test on a colleague's computer today and see if I can still reproduce. It is also possible that I have an issue specific to my computer that is causing this problem. Just to be clear, you tried my test URL, right?
Brent Fulgham
Comment 12 2016-06-06 09:39:32 PDT
(In reply to comment #11) > I'm running 10.11.4. I'll test on a colleague's computer today and see if I > can still reproduce. It is also possible that I have an issue specific to my > computer that is causing this problem. > > Just to be clear, you tried my test URL, right? Yes -- I wanted to rule out any local settings that might be masking the problem for me.
Zack Tollman
Comment 13 2016-06-06 11:10:27 PDT
Had a colleague test with the latest nightly using this URL: https://test-run-dot-csp-unit.appspot.com/tests/203e0152-9fa0-44e1-8e37-82530ef0d0ec (same content as old URL; old one isn't working ATM). My colleague is also on 10.11.4. My colleague was able to reproduce the issue.
Brent Fulgham
Comment 14 2016-06-06 11:14:14 PDT
(In reply to comment #13) > Had a colleague test with the latest nightly using this URL: > https://test-run-dot-csp-unit.appspot.com/tests/203e0152-9fa0-44e1-8e37- > 82530ef0d0ec (same content as old URL; old one isn't working ATM). My > colleague is also on 10.11.4. My colleague was able to reproduce the issue. Thank you for trying this again. We think this might be due to the Preload scanner kicking in for you at a different point than it is for me. I'm trying to investigate this now.
Brent Fulgham
Comment 15 2016-06-06 12:44:06 PDT
(In reply to comment #14) > (In reply to comment #13) > > Had a colleague test with the latest nightly using this URL: > > https://test-run-dot-csp-unit.appspot.com/tests/203e0152-9fa0-44e1-8e37- > > 82530ef0d0ec (same content as old URL; old one isn't working ATM). My > > colleague is also on 10.11.4. My colleague was able to reproduce the issue. I spun up a new 10.11.4 test machine. With the current nightly build I cannot reproduce with your appspot test content. Is it possible you have any interesting plugins or other customizations that might be affecting load behavior? I am using a completely "unconfigured" setup, so there may be settings or preferences you have set that I need to replicate to figure this out.
Brent Fulgham
Comment 16 2016-06-06 13:28:13 PDT
(In reply to comment #14) > Thank you for trying this again. We think this might be due to the Preload > scanner kicking in for you at a different point than it is for me. I'm > trying to investigate this now. For those playing along at home: we reviewed the Preload scanner code, and it properly upgrades before preload, so this is not an issue.
Zack Tollman
Comment 17 2016-06-06 13:35:22 PDT
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > Had a colleague test with the latest nightly using this URL: > > > https://test-run-dot-csp-unit.appspot.com/tests/203e0152-9fa0-44e1-8e37- > > > 82530ef0d0ec (same content as old URL; old one isn't working ATM). My > > > colleague is also on 10.11.4. My colleague was able to reproduce the issue. > > I spun up a new 10.11.4 test machine. With the current nightly build I > cannot reproduce with your appspot test content. > > Is it possible you have any interesting plugins or other customizations that > might be affecting load behavior? I am using a completely "unconfigured" > setup, so there may be settings or preferences you have set that I need to > replicate to figure this out. I don't *think* think that I do. I installed the nightly for the first time to review the UIR work. Does the nightly inherit any settings/config from stable Safari?
Zack Tollman
Comment 18 2016-06-06 19:00:09 PDT
This is interesting...updated my computer to 10.11.5 and tested with the latest nightly and I *cannot* reproduce the issue. My colleague, who reproduced the issue, was on 10.11.4. I reproduced it on 10.11.4 as well. Any ideas what that might be all about? Can you try to reproduce under those circumstances?
Michael Catanzaro
Comment 19 2018-11-13 16:21:21 PST
So, er, fixed in 10.11.5?
Note You need to log in before you can comment on or make changes to this bug.