The default landing page contained HTML to display a sample curl command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from window.location.href. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript.
This only affects Apollo Server with the default landing page enabled. Old browsers visiting your server may be affected if ANY of these apply:
You do not pass any landing page plugin to the plugins option of new ApolloServer.
You pass ApolloServerPluginLandingPageLocalDefault() or ApolloServerPluginLandingPageProductionDefault() to the plugins option of new ApolloServer.
Browsers visiting your server are NOT affected if ANY of these apply:
You pass ApolloServerPluginLandingPageDisabled() to the plugins option of new ApolloServer.
You pass ApolloServerPluginLandingPageGraphQLPlayground() to the plugins option of new ApolloServer.
You pass a custom plugin implementing the renderLandingPage hook to the plugins option of new ApolloServer.
This issue was introduced in v3.0.0 when the landing page feature was added.
Patches
To avoid this, the sample curl command has been removed in release 3.10.1.
Workarounds
Disabling the landing page removes the possibility of exploit:
import { ApolloServerPluginLandingPageDisabled } from 'apollo-server-core';
new ApolloServer({
plugins: [ApolloServerPluginLandingPageDisabled()],
// ...
});
In Apollo Server 3 and 4, the cache-control HTTP response header may not reflect the cache policy that should apply to an HTTP request when that HTTP request contains multiple operations using HTTP batching. This could lead to data being inappropriately cached and shared.
Apollo Server allows clients to send multiple operations in a single HTTP request. The results of these operations are returned in a single HTTP response, with a single set of headers. Apollo Client Web and Apollo Kotlin both have opt-in features to use batched requests.
Apollo Server has several features relating to caching. This advisory is about the ability to set the cache-control response header based on field- and operation-specific cache hints. (It is not about the "response cache plugin".) This header can be interpreted by a reverse proxy such as a CDN in front of your server, or by a browser.
In Apollo Server 2, plugins such as the cache control plugin could not control the HTTP headers of responses to batch requests. This meant that batch requests never got the cache-control response header.
In Apollo Server 3 and 4, plugins can set HTTP response headers. But for batched requests, plugins essentially assemble a separate set of response headers in parallel for each operation, and then the header sets are merged together. If plugins set the same header on multiple operations, one value is chosen arbitrarily.
This meant that if a client sent a batched HTTP request with two operations with different cache policies, Apollo Server 3 and 4 would return a cache-control header that only applies to one of the operations. If one operation is allowed to be cached and the other operation is not allowed to be cached, the full response including both results could still end up being cached in a CDN or other reverse proxy cache.
Note that valid batched requests must be POST requests. (There's no defined format for sending batched requests over GET.) So in order for this incorrect cache-control header to have a harmful effect, a cache must allow caching POST requests. This means this bug is unlikely to cause incorrect caching in browser or mobile client caches, or in many reverse proxy/CDN caches.
This issue could lead to cache poisoning attacks. For example, if a client app regularly sends an operation that should not be cached due to its dependency on session-specific information in the same HTTP request as an operation that can be cached in a shared cache, an attacker could send its own version of the request to the server and manage to get the response to its request stored in the shared cache; other users would then see the response specific to the attacker for the first operation rather than the response for their own session. That said, we expect that in a system where this cache poisoning attack is feasible, normal operation would also run into the issue and users may have already disabled one of the features in order for their system to function properly.
Patches
This issue is patched in Apollo Server v3.11.0 and v4.1.0. The issue resolved differently in the two versions.
If you are using Apollo Server 3, upgrade the package you depend on (eg apollo-server or apollo-server-express) to v3.11.0. This will restore the Apollo Server 2 behavior where the cache control plugin never sets the cache-control HTTP response header on batched requests. (Other cache-related features, like the response cache plugin, still function.)
If you are using Apollo Server 4, upgrade @apollo/server to v4.1.0. This upgrade makes the response HTTP header object seen by plugins shared among all plugins processing all operations on a request, and makes the cache control plugin merge cache-control header values across operations in a request. (Note that if you set the cache-control response header in your own plugin, Apollo Server v4.1.0's cache control plugin will not try to overwrite the value you set.)
Workarounds
As a workaround, you can disable either the HTTP batching feature or the cache-control header feature.
To disable HTTP batching in Apollo Server 3 (v3.5.0 or newer), pass allowBatchedHttpRequests: false to new ApolloServer.This is the default behavior for Apollo Server 4; in AS4, just make sure you're not passing allowBatchedHttpRequests: true. (You cannot disable batching in versions of Apollo Server 3 older than v3.5.0.)
To disable the cache-control header feature, add ApolloServerPluginCacheControl({ calculateHttpHeaders: false }) to the plugins list in new ApolloServer().
For more information
If you have any questions or comments about this advisory:
Apollo Server can log sensitive information (Studio API keys) if they are passed incorrectly (with leading/trailing whitespace) or if they have any characters that are invalid as part of a header value.
Who is impacted?
Users who (all of the below):
use either the schema reporting or usage reporting feature
use an Apollo Studio API key which has invalid header values
use the default fetcher (node-fetch) or configured their own node-fetch fetcher
The following node snippet can test whether your API key has invalid header values. This code is taken directly from node-fetch@2's header value validation code.
If the provided API key is not a valid header value, whenever Apollo Server uses that API key in a request (to Studio, for example), node-fetch will throw an error which contains the header value. This error is logged in various ways depending on the user's configuration, but most likely the console or some configured logging service.
Patches
This problem is patched in the latest version of Apollo Server as soon as this advisory is published.
Workarounds
Try retrieving a new API key from Studio. Note: this may not work if the invalid character is not part of the secret (it may be derived from identifiers like graph name, user name).
Override the fetcher
Disable schema reporting and/or usage reporting
Solution
Apollo Server will now call .trim() on incoming API keys in order to eliminate leading/trailing whitespace and log a warning when it does so.
Apollo Server will now perform the same validation of API keys as node-fetch@2 performs on header values on startup. Apollo Server will throw an error on startup (i.e., fail to start completely) and notify the user their API key is invalid along with the offending characters.
This is a special PR that replaces apollo-server-core with the community suggested minimal stable replacement version.
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, check this box
This PR contains the following updates:
^3.9.0->^4.0.0GitHub Vulnerability Alerts
GHSA-2fvv-qxrq-7jq6
Impact
The default landing page contained HTML to display a sample
curlcommand which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser fromwindow.location.href. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript.This only affects Apollo Server with the default landing page enabled. Old browsers visiting your server may be affected if ANY of these apply:
pluginsoption ofnew ApolloServer.ApolloServerPluginLandingPageLocalDefault()orApolloServerPluginLandingPageProductionDefault()to thepluginsoption ofnew ApolloServer.Browsers visiting your server are NOT affected if ANY of these apply:
ApolloServerPluginLandingPageDisabled()to thepluginsoption ofnew ApolloServer.ApolloServerPluginLandingPageGraphQLPlayground()to thepluginsoption ofnew ApolloServer.renderLandingPagehook to thepluginsoption ofnew ApolloServer.This issue was introduced in v3.0.0 when the landing page feature was added.
Patches
To avoid this, the sample
curlcommand has been removed in release 3.10.1.Workarounds
Disabling the landing page removes the possibility of exploit:
See also
A similar issue exists in the landing page of Apollo Router. See the corresponding Apollo Router security advisory.
For more information
If you have any questions or comments about this advisory:
Credits
This issue was discovered by Adrian Denkiewicz of Doyensec.
GHSA-8r69-3cvp-wxc3
Impact
In Apollo Server 3 and 4, the
cache-controlHTTP response header may not reflect the cache policy that should apply to an HTTP request when that HTTP request contains multiple operations using HTTP batching. This could lead to data being inappropriately cached and shared.Apollo Server allows clients to send multiple operations in a single HTTP request. The results of these operations are returned in a single HTTP response, with a single set of headers. Apollo Client Web and Apollo Kotlin both have opt-in features to use batched requests.
Apollo Server has several features relating to caching. This advisory is about the ability to set the
cache-controlresponse header based on field- and operation-specific cache hints. (It is not about the "response cache plugin".) This header can be interpreted by a reverse proxy such as a CDN in front of your server, or by a browser.In Apollo Server 2, plugins such as the cache control plugin could not control the HTTP headers of responses to batch requests. This meant that batch requests never got the
cache-controlresponse header.In Apollo Server 3 and 4, plugins can set HTTP response headers. But for batched requests, plugins essentially assemble a separate set of response headers in parallel for each operation, and then the header sets are merged together. If plugins set the same header on multiple operations, one value is chosen arbitrarily.
This meant that if a client sent a batched HTTP request with two operations with different cache policies, Apollo Server 3 and 4 would return a
cache-controlheader that only applies to one of the operations. If one operation is allowed to be cached and the other operation is not allowed to be cached, the full response including both results could still end up being cached in a CDN or other reverse proxy cache.Note that valid batched requests must be POST requests. (There's no defined format for sending batched requests over GET.) So in order for this incorrect
cache-controlheader to have a harmful effect, a cache must allow caching POST requests. This means this bug is unlikely to cause incorrect caching in browser or mobile client caches, or in many reverse proxy/CDN caches.This issue could lead to cache poisoning attacks. For example, if a client app regularly sends an operation that should not be cached due to its dependency on session-specific information in the same HTTP request as an operation that can be cached in a shared cache, an attacker could send its own version of the request to the server and manage to get the response to its request stored in the shared cache; other users would then see the response specific to the attacker for the first operation rather than the response for their own session. That said, we expect that in a system where this cache poisoning attack is feasible, normal operation would also run into the issue and users may have already disabled one of the features in order for their system to function properly.
Patches
This issue is patched in Apollo Server v3.11.0 and v4.1.0. The issue resolved differently in the two versions.
If you are using Apollo Server 3, upgrade the package you depend on (eg
apollo-serverorapollo-server-express) to v3.11.0. This will restore the Apollo Server 2 behavior where the cache control plugin never sets thecache-controlHTTP response header on batched requests. (Other cache-related features, like the response cache plugin, still function.)If you are using Apollo Server 4, upgrade
@apollo/serverto v4.1.0. This upgrade makes the response HTTP header object seen by plugins shared among all plugins processing all operations on a request, and makes the cache control plugin mergecache-controlheader values across operations in a request. (Note that if you set thecache-controlresponse header in your own plugin, Apollo Server v4.1.0's cache control plugin will not try to overwrite the value you set.)Workarounds
As a workaround, you can disable either the HTTP batching feature or the
cache-controlheader feature.To disable HTTP batching in Apollo Server 3 (v3.5.0 or newer), pass
allowBatchedHttpRequests: falsetonew ApolloServer.This is the default behavior for Apollo Server 4; in AS4, just make sure you're not passingallowBatchedHttpRequests: true. (You cannot disable batching in versions of Apollo Server 3 older than v3.5.0.)To disable the
cache-controlheader feature, addApolloServerPluginCacheControl({ calculateHttpHeaders: false })to thepluginslist innew ApolloServer().For more information
If you have any questions or comments about this advisory:
apollo-serverrepositoryGHSA-j5g3-5c8r-7qfx
Impact
What kind of vulnerability is it?
Apollo Server can log sensitive information (Studio API keys) if they are passed incorrectly (with leading/trailing whitespace) or if they have any characters that are invalid as part of a header value.
Who is impacted?
Users who (all of the below):
node-fetch) or configured their ownnode-fetchfetcherThe following node snippet can test whether your API key has invalid header values. This code is taken directly from
node-fetch@2's header value validation code.If the provided API key is not a valid header value, whenever Apollo Server uses that API key in a request (to Studio, for example),
node-fetchwill throw an error which contains the header value. This error is logged in various ways depending on the user's configuration, but most likely the console or some configured logging service.Patches
This problem is patched in the latest version of Apollo Server as soon as this advisory is published.
Workarounds
fetcherSolution
.trim()on incoming API keys in order to eliminate leading/trailing whitespace and log a warning when it does so.node-fetch@2performs on header values on startup. Apollo Server will throw an error on startup (i.e., fail to start completely) and notify the user their API key is invalid along with the offending characters.This is a special PR that replaces
apollo-server-corewith the community suggested minimal stable replacement version.Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.