This repository has been archived by the owner on Jul 29, 2022. It is now read-only.
Update dependency graphiql to 1.4.7 [SECURITY] #176
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.0.3
->1.4.7
GitHub Vulnerability Alerts
CVE-2021-41248
This is a security advisory for an XSS vulnerability in
graphiql
.A similar vulnerability affects
graphql-playground
, a fork ofgraphiql
. There is a correspondinggraphql-playground
advisory and Apollo Server advisory.1. Impact
All versions of
graphiql
older than[email protected]
are vulnerable to compromised HTTP schema introspection responses orschema
prop values with malicious GraphQL type names, exposing a dynamic XSS attack surface that can allow code injection on operation autocomplete.In order for the attack to take place, the user must load a vulnerable schema in
graphiql
. There are a number of ways that can occur.By default, the schema URL is not attacker-controllable in
graphiql
or in its suggested implementations or examples, leaving only very complex attack vectors.If a custom implementation of
graphiql
'sfetcher
allows the schema URL to be set dynamically, such as a URL query parameter like?endpoint=
ingraphql-playground
, or a database provided value, then this customgraphiql
implementation is vulnerable to phishing attacks, and thus much more readily available, low or no privelege level xss attacks. The URLs could look like any generic looking graphql schema URL.Because this exposes an XSS attack surface, it would be possible for a threat actor to exfiltrate user credentials, data, etc. using arbitrary malicious scripts, without it being known to the user.
2. Scope
This advisory describes the impact on the
graphiql
package. The vulnerability also affects other projects forked fromgraphiql
such asgraphql-playground
and thegraphql-playground
fork distributed by Apollo Server. The impact is more severe in thegraphql-playground
implementations; see thegraphql-playground
advisory and Apollo Server advisory for details.This vulnerability does not impact
codemirror-graphql
,monaco-graphql
or other dependents, as it exists inonHasCompletion.ts
ingraphiql
. It does impact all forks ofgraphiql
, and every released version ofgraphiql
.It should be noted that desktop clients such as Altair, Insomnia, Postwoman, do not appear to be impacted by this.
3. Patches
[email protected]
addresses this issue via defense in depth.HTML-escaping text that should be treated as text rather than HTML. In most of the app, this happens automatically because React escapes all interpolated text by default. However, one vulnerable component uses the unsafe
innerHTML
API and interpolated type names directly into HTML. We now properly escape that type name, which fixes the known vulnerability.Validates the schema upon receiving the introspection response or schema changes. Schemas with names that violate the GraphQL spec will no longer be loaded. (This includes preventing the Doc Explorer from loading.) This change is also sufficient to fix the known vulnerability. You can disable this validation by setting
dangerouslyAssumeSchemaIsValid={true}
, which means you are relying only on escaping values to protect you from this attack.Ensuring that user-generated HTML is safe. Schemas can contain Markdown in
description
anddeprecationReason
fields, and the web app renders them to HTML using themarkdown-it
library. As part of the development of[email protected]
, we verified that our use ofmarkdown-it
prevents the inclusion of arbitrary HTML. We usemarkdown-it
without settinghtml: true
, so we are comfortable relying onmarkdown-it
's HTML escaping here. We considered running a second level of sanitization over all rendered Markdown using a library such asdompurify
but believe that is unnecessary asmarkdown-it
's sanitization appears to be adequate.[email protected]
does update to the latest version ofmarkdown-it
(v12, from v10) so that any security fixes in v11 and v12 will take effect.3.1 CDN bundle implementations may be automatically patched
Note that if your implementation is depending on a CDN version of
graphiql
, and is pointed to thelatest
tag (usually the default for most cdns if no version is specified) then this issue is already mitigated, in case you were vulnerable to it before.4. Workarounds for Older Versions
If you cannot use
[email protected]
or laterAlways use a static URL to a trusted server that is serving a trusted GraphQL schema.
If you have a custom implementation that allows using user-provided schema URLs via a query parameter, database value, etc, you must either disable this customization, or only allow trusted URLs.
5. How to Re-create the Exploit
You can see an example on codesandbox. These are both fixed to the last
graphiql
release1.4.6
which is the last vulnerable release; however it would work with any previous release ofgraphiql
.Both of these examples are meant to demonstrate the phishing attack surface, so they are customized to accept a
url
parameter. To demonstrate the phishing attack, add?url=https://graphql-xss-schema.netlify.app/graphql
to the in-codesandbox browser.Erase the contents of the given query and type
{u
. You will see an alert window open, showing that attacker-controlled code was executed.Note that when React is in development mode, a validation exception is thrown visibly; however that exception is usually buried in the browser console in a production build of
graphiql
. This validation exception comes fromgetDiagnostics
, which invokesgraphql
validate()
which in turn willassertValidSchema()
, asapollo-server-core
does on executing each operation. This validation does not prevent the exploit from being successful.Note that something like the
url
parameter is not required for the attack to happen ifgraphiql
'sfetcher
is configured in a different way to communicate with a compromised GraphQL server.6. Credit
This vulnerability was discovered by @Ry0taK, thank you! 🥇
Others who contributed:
7. References
The vulnerability has always been present
In the first commit
And later moved to onHasCompletion.js in 2016 (now
.ts
after the typescript migration)8. For more information
If you have any questions or comments about this advisory:
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 has been generated by Mend Renovate. View repository job log here.