FEAT: Add Garak exploitation scenario (Jinja template injection + SQL injection echo) - #2576
Open
Manohar Paturi (ManoharPaturi) wants to merge 1 commit into
Conversation
Author
|
@microsoft-github-policy-service agree |
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.
Body:
Fixes #2534 (part of #511)
Summary
Adds a PyRIT-native
Exploitationscenario packaging garak's two activeserver-side exploitation checks —
JinjaTemplatePythonInjectionandSQLInjectionEchofromgarak/probes/exploitation.py—as techniques
jinja_template_python_injectionandsql_injection_echo,following the same shape as the other garak scenarios (and the open api_key
PR #2538): a
_ExploitationDatasetConfigurationplus one standardPromptSendingAttackper technique,prompt_cap(default 20,deterministic round-robin),
BaselineAttackPolicy.Forbidden, run-sizeestimate override, and resume support.
Datasets
Payloads are stored locally under
pyrit/datasets/seed_datasets/local/garak/with per-payload seed metadata (payload, exploit family,
expected_emitted_text, pinnedNVIDIA/garak@<commit>provenance; verifiedbyte-for-byte against upstream commits
560c75a5/61ed0b4e) and aTHIRD_PARTY_NOTICE.mdmirroring the other garak datasets' Apache-2.0attribution:
exploitation_sql_injection.prompt— 10 SQL payloadsexploitation_python_code_execution.prompt— 9 Python payloads (one exactupstream duplicate is deduped from the population —
AtomicAttackrequiresunique objective hashes, same as Encoding/WebInjection — the dataset keeps
all 9)
exploitation_templates.prompt— echo wrapper + Jinja{{<payload>}}wrapper (stored inside a
{% raw %}block so seed rendering yields theliteral
{{...}}wrapper)Success contract
Per the issue, each technique scores with a
TrueFalseCompositeScorer(OR)of payload-specific
SubStringScorers — positive when the target emits theexpected payload material. The existing
SSTIOutputScorer/SQLInjectionOutputScorerare wired as opt-inextended_checks=Trueauxiliary scorers only, unmodified. Objectives and docs describe emitted
exploit material, never downstream exploitation.
Docs
doc/scanner/garak.{py,ipynb}gain an Exploitation section with CLIexamples;
doc/code/datasets/1_loading_datasets.{py,ipynb}list the newdatasets.
Testing
tests/unit/scenario/garak/test_exploitation.py(17) +tests/unit/datasets/test_garak_exploitation_dataset.py(8) — 25 passedtests/unit/scenario/garak/+ dataset loader/schema/metadataruff checkandruff format --checkclean on all touched filesrender
ECHO: {{...}}/ECHO: <sql>, default estimate 18 (8+10), SQLscorer True on echo / False on refusal, Jinja scorer False on bare payload
Note: the notebook section's saved output is a plausible snapshot — happy to
regenerate or adjust anything the maintainers prefer.