-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
fix(create-docusaurus): potential security issue with command injection #7507
Conversation
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
⚡️ Lighthouse report for the deploy preview of this PR
|
Size Change: 0 B Total Size: 796 kB ℹ️ View Unchanged
|
expect(escapeShellArg('hello')).toBe("'hello'"); | ||
expect(escapeShellArg('*')).toBe("'*'"); | ||
expect(escapeShellArg('hello world')).toBe("'hello world'"); | ||
expect(escapeShellArg("'hello'")).toBe("\\''hello'\\'"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need more tests with unpaired quotes and attempts of injection
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be deleted after moving to Execa. I think those temporary tests are good enough for the small amount of escaping we'll do manually. Now if you want to add tests or provide a better implementation, go ahead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM👍
I doubt if it really happens in practice that users have unpaired quotes in their path names, and less so that it leads to command injection. But I've thought about the same.
As for execa vs. shelljs, I think our very simple approach to sanitize the input will suffice. All input is from the user and we should trust that there's no intentionally constructed injection. But it seems execa is also more lightweight (half the install size of shelljs in a fresh repo, not sure how much it would be in our monorepo). As long as there's feature parity, I'm okay for a switch.
@@ -23,6 +23,7 @@ | |||
"license": "MIT", | |||
"dependencies": { | |||
"@docusaurus/logger": "2.0.0-beta.20", | |||
"@docusaurus/utils": "2.0.0-beta.20", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it's already very bloated, but I'd like to point out that a bare install of create-docusaurus
is 8.1M, which is a bit too much for a scaffolding utility. I'd like to lower its size gradually, like avoiding lodash and @docusaurus/utils
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, but it will be removed after migrating to Execa so I'd rather increase this temporarily rather than creating a temporary smaller package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I agree!
I think the install size of |
The line is a bit blurry here 🤪 if users paste bad code in their terminal, obviously it's a bad idea. A hidden command can more easily sneak into a template URL. This security issue was reported. I don't think we should fix "deploy" for example, even though you can hack yourself through a malicious env variable or site config...
Yes Also only Crowdin still use shelljs today in our monorepo so users could just dl execa if we migrate to it @zpao already attempted a migration here: https://gist.github.com/zpao/7bbb58f2d44b553cf37581d338c826a4 That doesn't look like too complex considering we only have 3 files using shelljs. What annoys me is that we don't have good automated tests to cover these things. I wonder if we shouldn't introduce first a way to test the deployment script for example. This PR is a good enough solution to the security issue, we'll do the cleanup later |
I'm particularly surprised that execa is 1/3 the install size of shelljs... I always considered shelljs as just a thin wrapper. |
Pre-flight checklist
Motivation
ShellJS args must be escaped to prevent possible malicious command injections in create-docusaurus
Test Plan
unit + locally
These 3 should work fine:
But these should not allow executing malicious input:
Before the change, all these 3 commands would say hello or send currentUser to the remote endpoint. Now it's fixed.
Related issues/PRs
We removed Execa here: #5904
I think we should rather migrate from shelljs to execa, because apparently Execa automatically handle such security concerns better (even according to ShellJS security doc: https://github.com/shelljs/shelljs/wiki/Security-guidelines) + it's more used and maintained