1271377 - Missing Upgrade-Insecure-Requests header field when loading image from upgraded url

Status: RESOLVED INVALID

(Core :: DOM: Security, defect, P3)

Description

[Takashi]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160508030214

Steps to reproduce:

1.  Go to page which is enabled  "Content-Security-Policy: upgrade-insecure-requests"

2.  Image will be loaded without sending upgrade-insecure-requests field


Actual results:

Image will be loaded without sending upgrade-insecure-requests field


Expected results:

Expected result:

When I submit a form witch "action" = http url,  Firefox will send a https request with Upgrade-Insecure-Requests header field. I think this is the solution.

W3C specification stated....

----------------------------------------

3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field 

2. User agents MUST send an Upgrade-Insecure-Requests header field along with requests for potentially secure URLs whose url’s host is not a preloadable HSTS host.


Source: http://www.w3.org/TR/upgrade-insecure-requests/#preference

-----------------------------------------

Comment 1

[Takashi]

I uploaded my poc on google drive. Please watch it.

https://drive.google.com/open?id=0B1vJ77JB-Beod3NaR2t5b09NOTQ

Comment 2

[Christoph Kerschbaumer [:ckerschb}]

Takashi, thanks for filing. Please note that we decided to set the Upgrade-Insecure-Requests header field only for navigational requests [1]. For further information see [2].

Richard, I think we should continue to only send the header for navigational requests, but I wanted to hear your opinion as well. That do you think?

[1] https://hg.mozilla.org/mozilla-central/rev/e769e96e8680#l1.12
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1243586#c3

Comment 3

[Takashi]

While I was reading W3C spec, I wondered why header should be included.

If I load iframe, Firefox will send header field. I think the reason is Policy Inheritance.

Source: http://www.w3.org/TR/upgrade-insecure-requests/#nesting


So the question is....  Why image needs header? In my opinion, the answer could be server configuration.

Source: http://www.w3.org/TR/upgrade-insecure-requests/#recommendations

If Firefox sends Upgrade-Insecure-Requests header to a server, web site author can configure his response depending on the situation. 

What do you think?

Comment 4

[Christoph Kerschbaumer [:ckerschb}]

(In reply to Takashi from comment #3)
> What do you think?

The directive upgrade-insecure-requests in general does not apply to third party navigations (top-level and also frame navigation). Makes sense, because if the new site is not set up to be delivered over https, then the link would break. By sending the upgrade-insecure-requests header for navigational requests, the server sees that the browser supports the directive and can answer differently then it would for a browser not indicating that it supports the directive upgrade-insecure-requests.

To me, sending the header for every request is overkill and does not support any purpose.

Comment 5

[Christoph Kerschbaumer [:ckerschb}]

Putting this in the backlog for now.

Comment 6

[Richard Barnes [:rbarnes]]

> Richard, I think we should continue to only send the header for navigational requests, but I wanted to hear your opinion as well. That do you think?

The spec is phrased in terms of requests, not navigations, so if we want to have this policy, we should get the spec changed to match.

However, what resource are we conserving here?  A few octets of header, which you can save with h2+HPACK anyway?

Comment 7

[Tom Ritter [:tjr] (OOTO until April)]

Spec Question....

Comment 8

[Anne (:annevk)]

Per https://www.w3.org/TR/2015/CR-upgrade-insecure-requests-20151008/#upgrade-request the header is only injected for navigation.