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

More pollution protection? #104

Closed
shadowspawn opened this issue Apr 13, 2022 · 5 comments · Fixed by #106
Closed

More pollution protection? #104

shadowspawn opened this issue Apr 13, 2022 · 5 comments · Fixed by #106
Assignees
Labels
enhancement New feature or request

Comments

@shadowspawn
Copy link
Collaborator

shadowspawn commented Apr 13, 2022

Prompted by @aaronccasanova in #74 (comment), I started thinking through related pollution scenarios (#74 (comment)).

If this is something we care about, we have room for improvement. 🙊

const { parseArgs } = require('@pkgjs/parseargs');

// Somebody trampled all over prototypes...
Object.prototype.strict = false;
Object.prototype.args = ['--pollution', 'happened'];
Object.prototype.pollution = { type: 'string'};

const knownOptions = {
    with: { short: 'w', type: 'string' },
    bool: { short: 'b', type: 'boolean' }
};

console.log(parseArgs({ options: knownOptions }));
% node pollution.js --with VALUE -b
{ values: { pollution: 'happened' }, positionals: [] }
@shadowspawn shadowspawn changed the title More pollution protection More pollution protection? Apr 13, 2022
This was referenced Apr 13, 2022
@bcoe
Copy link
Collaborator

bcoe commented Apr 13, 2022

I think the bigger concern for prototype pollution is untrusted input to the CLI modifying the prototype, vs., the user having mucked with proto in their application, and this affecting our parse.

This makes me think that the bigger security concern would be if we ever supported dot properties; as @shadowspawn has mentioned.

@ljharb
Copy link
Member

ljharb commented Apr 13, 2022

We do not need to be concerned with the user attacking themselves, I’d think.

@bakkot
Copy link
Collaborator

bakkot commented Apr 13, 2022

We do not need to be concerned with the user attacking themselves, I’d think.

While I agree it's not a security concern, I also think it's nice for core modules like this not to break when users start mucking about with built-ins, so +1 to being defensive from me.

@shadowspawn
Copy link
Collaborator Author

We do not need to be concerned with the user attacking themselves, I’d think.

The code modifying the prototype may not be from the user.

For interest: We jump through a lot of hoops using primordials. Is modifying prototype functions considered a significant issue because "helpful" libraries have done it in the past, including perhaps left over monkey patches?

@aaronccasanova
Copy link
Collaborator

I started thinking through related pollution scenarios.

I too have been trying to think through scenarios and think @bakkot caught one in comment #106 that could definitely be abused.

// node pollution.js
// node pollution.js --deploy
const { parseArgs } = require("./index");

function someNpmModule() {
  // Breaks program if author didn't explicitly set the `multiple` config
  Object.prototype.multiple = true;
}

someNpmModule();

const cli = parseArgs({
  options: {
    deploy: { type: "boolean" },
  },
});
// cli: { values: { deploy: [ true ] }, positionals: [] }

console.log("cli:", cli);

if (cli.values.deploy === true) {
  console.log("Run deploy...");
} else {
  // This always prints since `cli.values.deploy` is undefined or an array.
  console.log("Fail deploy...");
}

image

@shadowspawn shadowspawn self-assigned this Apr 14, 2022
@shadowspawn shadowspawn added the enhancement New feature or request label Apr 14, 2022
@bcoe bcoe closed this as completed in #106 Apr 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants