Skip to content

fix: [reversinglabs_spectra_analyze] parse dns child-key limit for obj:path branch - #885

Open
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/070-dns-limit-obj-path
Open

fix: [reversinglabs_spectra_analyze] parse dns child-key limit for obj:path branch#885
elhoim wants to merge 1 commit into
MISP:mainfrom
elhoim:fix/070-dns-limit-obj-path

Conversation

@elhoim

@elhoim elhoim commented Aug 31, 2026

Copy link
Copy Markdown
Member

In _process_object_recursive, the obj:path branch (misp_modules/modules/expansion/reversinglabs_spectra_analyze.py, ~line 2536) parsed the per-field child limit from the wrong string:

_, _, foreach_path, foreach_filter, foreach_limit = _parse_obj_key(obj_path_value)

if not foreach_path:
    foreach_path = obj_path_value.strip()

obj_path_value comes from child_def.get("obj:path"), e.g. "last_dns_records[type=A,AAAA]" — it never carries a numeric cap. The numeric cap (e.g. "[10]") is instead encoded on the child object's key in MAPPING_RULES, e.g. "dns-ips[10]": { "obj:type": "ip-port", "obj:path": "last_dns_records[type=A,AAAA]", ... }. Since _parse_obj_key was never called on child_key in this branch, foreach_limit stayed at the sentinel default (MAX_FOREACH_ITERATIONS), and the truncation logic a few lines below then silently fell back to MAX_DNS_CHILDREN (25) instead of the declared 10. The sibling foreach-key branch a few lines below (~line 2638) already parses child_key correctly and was not affected.

Impact

For any mapping rule using the obj:path directive with a declared per-field cap smaller than 25 (e.g. dns-ips[10]), an analyst enriching an object from ReversingLabs Spectra Analyze would receive up to 25 child objects (e.g. DNS IP records) instead of the intended 10 — noisier, larger objects than the mapping rule author intended, with no truncation notice reflecting the real limit.

Fix

Also parse child_key with _parse_obj_key in the obj:path branch and use its explicit limit when present, mirroring the sibling foreach-key branch that already does this correctly. This changes observable output only for fields whose mapping declares a limit below the 25-item default: those fields now correctly truncate at their declared cap instead of silently allowing up to 25 children.

Verification

  • python -m py_compile misp_modules/modules/expansion/reversinglabs_spectra_analyze.py — clean.
  • flake8 misp_modules/modules/expansion/reversinglabs_spectra_analyze.py — clean (exit 0).
  • Started the misp-modules server locally (python -m misp_modules -l 127.0.0.1 -p 6666) and ran the full test suite: python -m pytest tests/ -q161 passed, 4 skipped, 5 subtests passed in 10.17s.
  • Sanity-checked the parser directly: _parse_obj_key("dns-ips[10]")('dns-ips', [], 'dns-ips', None, 10), confirming the limit is now correctly extracted from the child key.

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

🤖 Generated with Claude Code

https://claude.ai/code/session_018dfYpyaSZd1nxSRLr8suj8

…j:path branch

The obj:path directive branch of _process_object_recursive derives its
foreach limit by calling _parse_obj_key on the obj:path value (e.g.
"last_dns_records[type=A,AAAA]"), but MAPPING_RULES encodes the per-field
cap on the child object key instead (e.g. "dns-ips[10]"). Since the
obj:path value never carries a numeric suffix, foreach_limit always stays
at the parser's default (MAX_FOREACH_ITERATIONS), so the effective_limit
fallback silently becomes MAX_DNS_CHILDREN (25) instead of the declared
cap of 10, letting the dns-ips and dns-hostnames child objects grow far
beyond what the mapping author intended.

The fix parses child_key with _parse_obj_key as well and, when it yields
an explicit limit, uses that as foreach_limit -- mirroring what the
sibling foreach-key branch a few lines below already does.

Verified with flake8 (clean) and the full pytest suite against a live
misp-modules server on port 6770: 161 passed, 4 skipped, 5 subtests
passed, matching the baseline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018dfYpyaSZd1nxSRLr8suj8
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