fix(query): ensures 'passwords and secrets' queries do not flag fields in 'Proto' files (.proto)

[cx-andre-pereira]

Reason for Proposed Changes

• Currently passwords and secrets queries will wrongfully flag ".proto" files. These files cannot hold any sensitive values within their set fields since they serve as schema definitions only and do not store any actual values associated with the defined fields.
• It is true, however, that commented lines are allowed in said files and could include secrets, as such the way to avoid False Positives will be by the use of new "Avoiding Proto File fields" allow rules.

Proposed Changes

• Added 4 new allow rules one for each of the following queries :

  • "Generic Password" - 487f4be7-3fd9-4506-a07a-eae252180c08
    • regex : (?i)password\\s*=\\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

  ---

  • "Generic Secret" - 3e2d3b2f-c22a-4df1-9cc6-a7a0aebb0c99
    • regex : (?i)secret[_]?(key|value)?\\s*=\\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

  ---

  • "Generic Private Key" - 2f665079-c383-4b33-896e-88268c1fa258
    • regex : (?i)private[_]?key\\s*=\\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

  ---

  • "Generic Token" - baee238e-1921-4801-9c3f-79ae1d7b2cbc
    • regex : (?i)token(_)?(key)?\\s*=\\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

  ---

  • "Encryption Key" - 9fb1cd65-7a07-4531-9bcf-47589d0f82d6
    • regex : (?i)encryption[_]?key\\s*=\\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

  ---

• The regex associated with the queries all follow a very similar pattern designed to ensure as little headroom for False Negatives as possible. The prefix to each regex is purely based on the main regex pattern associated with each query, the suffix is identical between all regex : \\s*(0|[1-9][0-9]{0,8})\\s*(\\[.+=.+\\]\\s*;|\\[.+=.+,\\s*$|\\[\\s*$|;)

• The suffix enforces the use of "=" and at least 1 integer value, additionally up to 8 more digits can be caught by the regex and finally there can be 4 possible scenarios at the end:

• 1 - \\[.+=.+\\]\\s*; - Accounts for the most common "options block" use case.

• 2 - \\[.+=.+,\\s*$ - Accounts for cases where comma separated options are used in different lines.

• 3 - \\[\\s*$ - Accounts for cases where the "options block" is opened but not defined in that same line.

• 4 - ; - Accounts for the most basic attribution with no "options block".

• Note only scenario 2 and 3 enforce end of line since 1 and 4 can be followed by a comment, another field declaration or the end of the message declaration "}" with a brand new one possible right after; additionally scenarios 2, 3 and 4 are based on samples from the oficial Language Guide (proto 3) while 1 is mostly based in protoc-gen-openapiv3 and v2, specific options use it applies to standard use of options as well.
  All this is based on the ".proto" files syntax since it:

• Is mostly whitespace insensitive;

• Does not support the use of ":" over "=" or any other value;

• Only supports "field numbers" up to 536,870,911(hence the 9 digit limit);

• Must have a semicolon at the end of each statement, note that there can be an arbitrary number of whitespaces before said semicolon and newlines can be used in option declarations (scenarios 2 and 3 account for these) before the statement ends.

• A new negative and positive test sample was added, along with those the "inspector_test" was expanded to include a sample of type "PROTO".

• Note that in the positive sample there is a "False Positive" scenario, one that is too generic to ever distinguish through an allow rule where a field is simply attributed a value and the associated "options block" is defined in a different line, there is no bracket, comma or semicolon in sight to help us distinguish the scenario at all, only a direct, clean "<type> field_name = <field_number>" type attribution.

I submit this contribution under the Apache-2.0 license.

[cx-artur-ribeiro]

LGTM