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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jun 4 19:31:36 PDT 2016


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

            Bug ID: 158389
           Summary: upgrade-insecure-requests does not upgrade HTTP URI's
                    after being redirected (maybe)
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          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

Created attachment 280540
  --> https://bugs.webkit.org/attachment.cgi?id=280540&action=review
Redirect and upgrade flow

Apologies if this is not truly a bug yet, but wanted to document this as work on upgrade-insecure-requests (UIR) progresses. It is entirely possible that after [158388](https://bugs.webkit.org/show_bug.cgi?id=158388) is resolved, this will be a moot point.

It is possible that when URI's are upgraded via UIR and redirected to an HTTP URI, the resource is not upgraded (see attachment for clarity). We need to ensure that UIR handles this case.

At present, I cannot validate whether this bug exists or not due to #158388.

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 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. Load the page.

Expected behavior:

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

What happened:

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

[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.

In Firefox, on Nightly and Stable, the upgrade works. I get the following Console output:

Content Security Policy: Upgrading insecure request 'http://domain.com/asset.png' to use 'https'
Content Security Policy: Upgrading insecure request 'http://domain.com/redirected.png' to use 'https'

I've also filed this bug in Chrome as the bug exists there as well and Mike West indicated that it was a bug.

-- 
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/20160605/83f9ff0a/attachment-0001.html>


More information about the webkit-unassigned mailing list