Skip to content

[high] fix: [backscatter_io] accept ip-dst-only requests and reject empty ones - #838

Open
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/028-backscatter-io-input-guard
Open

elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/028-backscatter-io-input-guard

Conversation

@elhoim

@elhoim elhoim commented Aug 31, 2026 •

Copy link
Copy Markdown
Contributor

BLUF — Backscatter.io enrichment now works for ip-dst-only requests and rejects empty ones.

  • Problem — check_query in backscatter_io.py bails out on not request.get("ip-src") and request.get("ip-dst"), rejecting exactly the valid ip-dst-only case, while a request with neither attribute falls through and queries the API with value=None; the following if "ip-src" in request also lets an empty ip-src key shadow a populated ip-dst.
  • Fix — Negates the second half of the guard and switches the value-selection test to request.get("ip-src").
  • Effect — Analysts enriching an ip-dst attribute get results instead of "Unsupported attributes type", and empty requests fail cleanly.

The input guard in check_query was inverted, so it silently mishandled valid enrichment requests:

if not request.get("ip-src") and request.get("ip-dst"):
    misperrors["error"] = "Unsupported attributes type."
    return output
profile = {"success": True, "config": config, "playbook": "generic"}
if "ip-src" in request:
    profile.update({"value": request.get("ip-src")})
else:
    profile.update({"value": request.get("ip-dst")})

The condition only bails out when ip-src is absent and ip-dst is present — i.e. it rejects the exact case it should support (a valid ip-dst-only request), while a request with neither attribute falls through the guard entirely and reaches profile["value"] = request.get("ip-dst"), which resolves to None. Separately, if "ip-src" in request treats an empty/falsy ip-src key as present, shadowing a perfectly good ip-dst value.

Impact: An analyst enriching an ip-dst attribute with the Backscatter.io module gets Unsupported attributes type even though ip-dst is a supported attribute type for this module, and a malformed request (no IP at all) proceeds to query the API with value=None instead of failing cleanly.

Fix: Negate the second half of the guard (and not request.get("ip-dst")) so it only rejects requests where both are absent, and switch the value-selection check to request.get("ip-src") so an empty ip-src no longer masks a populated ip-dst. Purely a bug fix — no behaviour change beyond making ip-dst-only requests work as intended.

Found during a review of the repository; other findings are being submitted as separate PRs.

Verification

  • flake8 on the changed file: clean, no output.
  • Full module test suite: 161 passed, 4 skipped, 5 subtests passed in 105.43s (0:01:45).

🤖 Generated with Claude Code

The input guard in check_query reads "if not request.get("ip-src") and
request.get("ip-dst")", which is inverted. A hover or expansion on a plain
ip-dst attribute is rejected with "Unsupported attributes type." even though
ip-dst is a declared input, while a request carrying neither ip-src nor ip-dst
passes the guard and ends up with value None, so the module queries
backscatter.io with query=None and the analyst gets an opaque API error
instead of a clear unsupported-attribute message. The guard now requires both
values to be absent before bailing out, and the value is picked from whichever
of the two is actually populated rather than from mere key presence.

Verified with flake8 on the changed file and the full test suite against a
local modules server: 161 passed, 4 skipped, 5 subtests passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018dfYpyaSZd1nxSRLr8suj8
@elhoim elhoim changed the title fix: [backscatter_io] accept ip-dst-only requests and reject empty ones [high] fix: [backscatter_io] accept ip-dst-only requests and reject empty ones Sep 3, 2026

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