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

Notes about eslint-plugin-security #670

Closed
fregante opened this issue Jul 1, 2021 · 3 comments
Closed

Notes about eslint-plugin-security #670

fregante opened this issue Jul 1, 2021 · 3 comments
Labels

Comments

@fregante
Copy link
Contributor

fregante commented Jul 1, 2021

(This is a non-issue, just for discussion purposes)

security/detect-object-injection has a lot of false positives. Could a solution be in this long SO answer? https://stackoverflow.com/q/57960770

Related (but no solution here)

@twschiller
Copy link
Contributor

twschiller commented Jul 2, 2021

I don't mind having to write warning suppressions with justification. The main thing is getting the number of down to a level where we're not in a "boy who cried wolf situation" during development and PR review

In "normal" application code, we should by and large be able to use Map or another safe alternative

The main areas where Map wouldn't be feasible right now:

  • Redux code: because the state has objects keyed by dynamic fields. Mitigated by 1) validation of ids, 2) use of Immer by Redux tool kit? State shape could be re-written, bu persisted state would need to be migrated
  • Brick templating: this is actually the area where prototype pollution and similar concerns are relevant. We can/should eventually be executing templating in the sandbox
  • "Page script" getters and setters: another area we can't avoid, and where prototype pollution is relevant. This can't be sandboxed. For getters, we should be freezing/sealing. For setters we should be sanitizing property name and checking for hasOwnProperty, etc.

Overall, this becomes more relevant when we introduce the public marketplace. In that world, we can also "flag" certain kinds of bricks as higher risk due to their potential behavior

@fregante
Copy link
Contributor Author

I've seen this justification a few times in the code:

// OK because we're guarding with hasOwnProperty
// eslint-disable-next-line security/detect-object-injection,@typescript-eslint/no-dynamic-delete
delete current[key];

If that's correct, what do you think about creating a safeGet/safeSet function pair? Like

export function safeGet<
  TKey extends string,
  TObject extends Record<TKey, unknown>
>(object: TObject, key: TKey): TObject[TKey] {
  if (Object.prototype.hasOwnProperty.call(object, key)) {
    // eslint-disable-next-line security/detect-object-injection -- Safe!
    return object[key];
  }

  throw new Error(`Key ${key} is not a direct property of object`);
}

(types are ok but are likely improvable)

This would let us change this:

// Make sure we don't install the content script multiple times
// eslint-disable-next-line security/detect-object-injection -- using PIXIEBRIX_SYMBOL
const existing: string = window[PIXIEBRIX_SYMBOL];

to

import {safeGet} from "@/utils";
const existing: string = safeGet(window, PIXIEBRIX_SYMBOL);

@fregante
Copy link
Contributor Author

@fregante fregante closed this as not planned Won't fix, can't repro, duplicate, stale Aug 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 participants