Skip to content

FIX: match label keys containing dots or hyphens in attack result and message filters - #3063

Open
Jaafer Rahmani (bIackr0se) wants to merge 1 commit into
microsoft:mainfrom
bIackr0se:fix/dotted-label-key-filters
Open

Jaafer Rahmani (bIackr0se) wants to merge 1 commit into
microsoft:mainfrom
bIackr0se:fix/dotted-label-key-filters

Conversation

@bIackr0se

Copy link
Copy Markdown
Contributor

Description

Label filters on attack results and message pieces do not find labels whose key contains . or -, although the label key allowlist (_LABEL_KEY_PATTERN, ^[A-Za-z0-9_.\-]+$) accepts both characters.

On SQLiteMemory, with one attack result labeled {"team.name": "safety"} and another labeled {"team": "safety"} (file-backed database):

get_attack_results_async(labels={"team.name": "safety"})   -> []   (expected the first result)
get_message_pieces_async(labels={"team.name": "safety"})   -> []   (expected its conversation)

On AzureSQLMemory, the same filters raise while the query is built, for any key with . or -:

sqlalchemy.exc.ArgumentError: This text() construct doesn't define a bound parameter named 'are_label_team.name_0'

The GUI attack list passes its label filters to the same method:

GET /api/attacks?label=team.name:safety   -> 200, no attacks   (expected the first result)

Causes:

  • SQLite builds the JSON path as $.{key}, so team.name is read as the nested path team -> name.
  • Azure SQL builds the bind parameter names from the key (are_label_{key}_{idx}, are_ml_{key}), and SQLAlchemy reads :are_label_team.name_0 as a parameter named are_label_team. It also puts the key into the SQL text as '$.{key}'.

The fix follows the scenario label helpers, which already handle these keys: SQLite quotes the key ($."{key}"), and Azure SQL binds the quoted path as a parameter and names the parameters by position (are_label_path_0, are_label_0_0, are_ml_path_0, are_ml_0). Plain keys such as operation match the same rows as before.

After the fix, both SQLite calls and the GUI request above return the team.name result, the team result is still found by its own key, and the Azure SQL conditions compile with '$."team.name"' and '$."run-id"' as bound paths.

Tests and Documentation

  • test_get_attack_results_by_labels_key_with_dot_or_hyphen (team.name, run-id; single value and list of values) and test_get_message_pieces_by_label_key_with_dot, on SQLite memory.
  • test_label_conditions_bind_whole_keys_with_dot_or_hyphen: Azure SQL attack result and message piece conditions with two keys and several values, checking the bound paths and values.
  • The four existing Azure SQL tests that assert parameter names now use the positional names.
  • On main, the new SQLite team.name cases and the new Azure SQL test fail; the SQLite run-id case passes on both, since SQLite reads - inside an unquoted key.
  • Unit tests under tests/unit/memory, the backend label tests, Ruff, and ty pass.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant