[Webkit-unassigned] [Bug 159118] New: upgrade-insecure-requests does not upgrade HTTP URI's after being redirected

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jun 25 11:57:45 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=159118

            Bug ID: 159118
           Summary: upgrade-insecure-requests does not upgrade HTTP URI's
                    after being redirected
    Classification: Unclassified
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: tollmanz at gmail.com
                CC: bfulgham at webkit.org, tollmanz at gmail.com

Created attachment 282080
  --> https://bugs.webkit.org/attachment.cgi?id=282080&action=review
Flowchart to describe expected and actual upgrades

Steps to reproduce the problem:

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 step 1, that contains an `img` tag with a `src` attribute pointing to an HTTP asset (request A), that can successfully be upgraded to an HTTPS (request B) asset via `upgrade-insecure-requests`. This HTTPS asset should then redirect, via the server, to an HTTP asset (request C). Note that this HTTP asset should work as an HTTP or HTTPS request, but the redirect should specifically be to the HTTP version of the asset.
3. Remove, and possibly flush, any HSTS headers set for the test domain.

You can view a test case here: https://test-run-dot-csp-unit.appspot.com/tests/bdfab057-5f90-466f-afdd-0d67ca9c5458.

In the test case, http://goo.gl/fDn2aT is upgraded to https://goo.gl/fDn2aT, which redirects to http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150, but *is not* upgraded to https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 as I would expect.

What is the expected behavior?

It is expected that request C should be upgraded to an HTTPS request via `upgrade-insecure-requests`.

What went wrong?

Request C is not upgraded via `upgrade-insecure-requests` and subsequently blocked by the `default-src https:` CSP directive:

Refused to load http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160625/f6f86136/attachment-0001.html>


More information about the webkit-unassigned mailing list