Repository navigation
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
Open
Jaafer Rahmani (bIackr0se) wants to merge 1 commit into
Jaafer Rahmani (bIackr0se) wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):On
AzureSQLMemory, the same filters raise while the query is built, for any key with.or-:The GUI attack list passes its label filters to the same method:
Causes:
$.{key}, soteam.nameis read as the nested pathteam->name.are_label_{key}_{idx},are_ml_{key}), and SQLAlchemy reads:are_label_team.name_0as a parameter namedare_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 asoperationmatch the same rows as before.After the fix, both SQLite calls and the GUI request above return the
team.nameresult, theteamresult 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) andtest_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.main, the new SQLiteteam.namecases and the new Azure SQL test fail; the SQLiterun-idcase passes on both, since SQLite reads-inside an unquoted key.tests/unit/memory, the backend label tests, Ruff, andtypass.