mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-10-06 07:57:08 +02:00
CyberSecurityUPandClaude Opus 4.8
c233da8b17
Hard scope stays the safety boundary (you must say what you're allowed to test), but setting it is now frictionless for a normal client pentest where authorization comes from a signed SOW/contract — no bug-bounty program or capability token. - /authorize <host|*.dom|cidr|url> ... (aliases /grant, /inscope-set): set the entire authorized scope in one line (multiple entries), pins it so /target won't re-derive, and seeds the target so /run works immediately. The operator asserts written authorization for the listed assets; guardrails (rate, accounts, destructive) remain tunable via /guardrail. - examples/scopes/engagement.example.yaml — neutral direct-engagement template (no program framing): fill hard scope from the SOW, guardrails documented as yours to tune (e.g. allow destructive in a staging env, raise rate for a lab). The frictionless path already worked (/target x -> authorized against x); this makes the multi-asset direct engagement a single clear command. 422 tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
57 lines
2.6 KiB
YAML
57 lines
2.6 KiB
YAML
# ===========================================================================
|
|
# NeuroSploit scope config — direct engagement (TEMPLATE)
|
|
# ---------------------------------------------------------------------------
|
|
# For a normal pentest where you have WRITTEN AUTHORIZATION from the asset
|
|
# owner (a signed SOW / contract / authorization letter) — no bug-bounty
|
|
# program or HackerOne needed. You, the operator, assert you are authorized
|
|
# for everything in `hard` below. Fill it from the engagement's authorization.
|
|
#
|
|
# You usually don't even need this file: in the REPL just run
|
|
# /authorize app.client.com *.client.com 10.0.0.0/24
|
|
# or on the CLI
|
|
# neurosploit run app.client.com --in-scope "*.client.com" --in-scope 10.0.0.0/24
|
|
# Use this file when the scope is large or you want it version-controlled with
|
|
# the engagement notes.
|
|
#
|
|
# HARD scope is the one thing you MUST set — it is the safety boundary (a host
|
|
# not covered here is refused before any request leaves). Everything else
|
|
# (rate, accounts, destructive verbs) is YOURS to tune for THIS engagement.
|
|
# ===========================================================================
|
|
|
|
# --- HARD: everything you are authorized to test. -------------------------
|
|
hard:
|
|
- app.client.example # a single host
|
|
- "*.client.example" # apex + all subdomains
|
|
- 10.0.0.0/24 # an internal range (reach it with --transport)
|
|
- https://api.client.example/v2 # or just one URL prefix
|
|
|
|
# --- EXCLUDE: anything carved out of the authorization. -------------------
|
|
exclude:
|
|
# - billing.client.example
|
|
# - "*.prod.client.example" # e.g. test staging only
|
|
|
|
# --- SOFT: guardrails — tune these to the engagement's rules. -------------
|
|
soft:
|
|
# Look-only hosts (recon, no payloads) — e.g. shared/third-party infra.
|
|
observe_only: []
|
|
|
|
# Direct engagements often authorize more than a bounty would. Set these to
|
|
# what the SOW allows:
|
|
allow_destructive_methods: false # true only if the authorization covers it (e.g. a staging env)
|
|
allow_account_creation: true # create test accounts to reach authed surface
|
|
max_accounts: 3
|
|
max_requests_per_minute: 240 # raise for a lab / internal test, lower for fragile prod
|
|
|
|
# Hard stops regardless of authorization — things that destroy data or DoS.
|
|
forbidden_payloads:
|
|
- "drop table"
|
|
- "truncate table"
|
|
- "delete from"
|
|
- "rm -rf /"
|
|
- "shutdown"
|
|
- "while(true)"
|
|
|
|
notes:
|
|
- "Authorized under <SOW / contract reference>; owner contact: <email/phone>."
|
|
- "Test window: <when>. Notify <contact> before any high-impact test."
|