Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Say that a web server supports both HTTP and HTTPS. If a browser fetches the same JavaScript with a HTTP GET and a HTTPS GET, and the JavaScript is cache-able, will the browser cache two copies of the same JavaScript?
The reason I'm asking is that if only one copy is cached, would it be possible for an attacker to first trick the victim into downloading JavaScript via HTTP and compromise it along the way, which will result in a cache poisoning attack?
Resources are cached by their URL, and the protocol (http:// or https://) is part of the URL. Since the protocol differs, the URL must also differ, and you have two separate cache entries.
It is perfectly fine if a http:// and a https:// resource provide different data, even if everything but the access method is the same. For example access to http:// will today often result in a redirect response while access to https:// provide the real content. A browser will therefore cache these resources independent from each other.
http://example.com/example.js is redirected to https://example.com/example.js, and example.js is finally fetched, will this script be cached under http://example.com or https://example.com?
Cache-Control headers, the http:… response will be cached as a redirect. The cache entry for the https:… response will then separately store the actual JS. On subsequent requests for http:…, the browser will check its cache, see a redirect, and then begin a request for the redirect target -- possibly without sending any bytes over the network. In your scenario, the browser would look for the https:… JS, which it may serve directly from cache also or go to the network. The above may also be modified by HSTS.
Summary:
http: for all insecure requests and https: for all secure requestsThe current standard for HTTP is split across multiple "RFC" documents, with RFC 7234 dedicated entirely to caching, because there is a lot of complexity involved.
In section 2, "Overview of Cache Operation", there is this summary:
The primary cache key consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.
This is more formally stated in the first bullet point in section 4, which says:
When presented with a request, a cache MUST NOT reuse a stored response, unless [...] the presented effective request URI (Section 5.5 of RFC7230) that of the stored response match [...]
Section 5.5 of RFC 7230 starts by saying
For a user agent, the effective request URI is the target URI.
A browser is a "user agent", so this is the case we're concerned with here. "Target URI" is defined in section 5.1:
A URI reference (Section 2.7) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing (RFC3986, Section 3.5).
The generic definition of a URI is in RFC 3986, and HTTP-specific concerns take up three pages of RFC 7230. The most relevant part for our purposes is RFC 3986 section 4.1 which defines this grammar for Absolute URIs:
absolute-URI = scheme ":" hier-part [ "?" query ]
Crucially, note that scheme is a mandatory part of any Absolute URI. Since HTTP URIs always use the scheme http and HTTPS URIs always use the scheme https, this means that their absolute URIs, and thus their "primary cache keys" in a browser, can never collide.
Other answers have mentioned ports. RFC 7230, Section 2.7.1 defines http URIs as including an "authority" section, which is defined in [RFC 3986, Section 3.2]:
authority = [ userinfo "@" ] host [ ":" port ]
The port is optional, with RFC 7230, Section 2.7.1 defining the default for the http URI Scheme:
If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default.
And the following section defining the default for "https":
All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that TCP port 443 is the default if the port subcomponent is empty or not given, and ...
It then follows that:
Thus these URIs would all be cached separately:
The only thing I'm not clear on is whether the browser should, may, or must normalise URIs which explicitly mention the port which would be the default anyway. In other words, whether these two URIs would be cached separately or not:
I can't think of any practical consequence of normalising these to the same cache key, because by the definitions above they are guaranteed to represent the same resource.
http://example.com:80/path to http://example.com/path, but seem to stop short of saying that they must do so for the purposes of caching.
Dec 13, 2019 at 19:19
Leaving aside the fact that the spec is quite clear that different URLs should be treated as different resources, don't you think that someone might have noticed and exploited this by now if it were not the case? After all the issues exposed by cookies (and addressed by the "secure" flag) have been known about for 20 years or more.
So the browser must retrieve both URLs. It is conceivable that a cache might retain a single copy of a file downloaded from different sources but accessed via different keys - or that this de-duplication might occur deeper in the filesystem (de-duplication). But this would only happen after the cache (or the filesystem) had determined that the files were the same.
Yes, because they are different network destinations. The tcp port is not shown in the location bar when using the standard port.
Http defaults to tcp port 80. Www.example.com:80
Https defaults to tcp port 443 Www.example.com:443
Even if the domain and ip are the same, the ports are not. From the browser perspective, the browser is communicating with different sites.
UPDATE
The network doesn't affect it as much as the S does in the https. It's a different URI, too.
From a server-side perspective the same URL (eg. www.test.com) on different protocols (eg. HTTP vs HTTPS) can use a different file source. So a URL with TLS can output a completely different website than the URL without TLS. This alone makes me think that browsers won't use the same cache for both files.
Yes, these are different origins. While it's very likely they would serve the same content, they can technically serve entirely different content. For this reason, the browser is not allowed to treat them as the same resource.
