Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security issue - can kill server by using a malformed operations header #154

Closed
juona opened this issue Jun 12, 2019 · 4 comments
Closed
Labels

Comments

@juona
Copy link

juona commented Jun 12, 2019

Hello,

There have been issues like this one in the past, here's a new one I have found.

When sending a multipart request using some arbitrary REST client I can kill the express server. Namely, if the variants field in the operations header has a value other than an object, the server dies. A normal operations header would look something like this:

{"operationName": null, "variables": {"images": [null, null]}, "query": "mutation ($images: [Upload!]!) { uploadImages(images: $images) { id image } }"}

If you change the value of variables ({"images": [null, null]}) to any of the following, sending such request will kill the server:

  • any string value - "whateverXYZ214213"
  • any number - 123
  • null

Array [] and object {} work fine. The error that is thrown is this:

[0] TypeError: Cannot create property 'images' on string '123'
[0]     at set (/home/juona/dev/podbase/node_modules/object-path/index.js:118:28)
[0]     at set (/home/juona/dev/podbase/node_modules/object-path/index.js:124:14)
[0]     at set (/home/juona/dev/podbase/node_modules/object-path/index.js:104:16)
[0]     at Function.objectPath.set (/home/juona/dev/podbase/node_modules/object-path/index.js:157:14)
[0]     at Busboy.parser.on (/home/juona/dev/podbase/node_modules/graphql-upload/lib/processRequest.js:173:30)
[0]     at Busboy.emit (events.js:182:13)
[0]     at Busboy.emit (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/busboy/lib/main.js:37:33)
[0]     at PartStream.onEnd (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/busboy/lib/types/multipart.js:262:15)
[0]     at PartStream.emit (events.js:187:15)
[0]     at Dicer.onPart (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/busboy/lib/types/multipart.js:120:13)
[0]     at Dicer.emit (events.js:182:13)
[0]     at Dicer.emit (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/dicer/lib/Dicer.js:79:35)
[0]     at Dicer._oninfo (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/dicer/lib/Dicer.js:180:12)
[0]     at SBMH.<anonymous> (/home/juona/dev/podbase/node_modules/graphql-upload/node_modules/dicer/lib/Dicer.js:126:10)
[0]     at SBMH.emit (events.js:182:13)
[0]     at SBMH._sbmh_feed (/home/juona/dev/podbase/node_modules/streamsearch/lib/sbmh.js:188:10)

@jaydenseric
Copy link
Owner

jaydenseric commented Jun 12, 2019

Thanks for the report, I think the problem is here:

https://github.com/jaydenseric/graphql-upload/blob/v8.0.6/src/processRequest.mjs#L274

It's not specifically to do with variables, as the object path could be to anywhere in the operations object.

We need to detect the path is nonsense by putting a try catch around it or something, then on error return and exit with a relevant error like this:

https://github.com/jaydenseric/graphql-upload/blob/v8.0.6/src/processRequest.mjs#L267

A test needs to be added to cover this situation.

PR would be a big help!

@jaydenseric
Copy link
Owner

Don't worry about a PR, I'm working on a fix…

@juona
Copy link
Author

juona commented Jun 12, 2019

Thank you, Jayden. I could have done a PR, you just reacted way sooner than I anticipated : ]

@jaydenseric
Copy link
Owner

Published the fix in v8.0.7 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants