fix(tracer): prevent catastrophic backtracking in query string obfuscation on multibyte URL-encoded filenames

[kisungyi92]

Summary

URL-encoded multibyte filenames (Korean/Japanese/CJK) in query string parameters trigger catastrophic backtracking in the default DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXP when combined with auth-related parameters (e.g. a Vault ticket parameter).

In production this caused RegexInterpreter.Go() to consume 16.34s/min (vs 3ms baseline), and system.cpu.user to spike from ~1.6% to 90% with zero application code changes after APM instrumentation.

Datadog Continuous Profiler confirmed the root cause via A/B comparison: TrackPush, StackPush, and Goto (backtracking-only methods) were completely absent before instrumentation and spiked immediately after.

Root Cause

The three backtracking-prone patterns in the default regex fire simultaneously on Vault file download URLs containing URL-encoded Korean filenames:

• (?:%2[^2]|%[^2]|[^"%])+ — 70+ %XX bytes accumulate before failing to find closing ", then full rollback
• ey[I-L](?:[\w=-]|%3D)+\.ey[I-L]... — greedily matches filename chars, fails on required . separator
• (?:[a-z0-9/.+]|%2F|%5C|%2B){100,} — 100+ iterations across %2F-containing encoded content

Example triggering URL:

/Vault/vaultserver.aspx
  ?fileName=%EC%84%A4%EA%B3%84%EC%9E%90%EB%A3%8C_.xlsx
  &vaultId=67BBB9204FE84A8981ED8313049BA06C
  &ticket=VAULT_TOKEN

Changes

Obfuscator.cs — two complementary fixes:

1. Pre-strip high-byte URL-encoded sequences (%80–%FF) before running the obfuscation regex. Credential patterns (tokens, keys, passwords) are ASCII-only; multibyte-encoded characters cannot contain sensitive data, so stripping them removes the backtracking trigger while keeping all ASCII parameters intact.

2. RegexOptions.NonBacktracking on .NET 7+ — guarantees O(n) matching time regardless of input, as defense-in-depth.

QueryStringObfuscatorTests.cs — regression tests:

• Korean/Japanese filename + token parameter (exact production trigger)
• ASCII-only URLs (no regression in existing behavior)
• Performance assertion: completes within 1s on long encoded filenames

Test Plan

• QueryStringObfuscatorTests.ObfuscateWithDefaultPattern_MultibyteUrlEncoding — correctness
• QueryStringObfuscatorTests.ObfuscateWithDefaultPattern_MultibyteUrlEncoding_CompletesWithinTimeout — performance regression guard
• All existing ObfuscateWithDefaultPattern tests still pass

Affected Customers

Any customer where HTTP request URLs contain URL-encoded multibyte characters and a parameter name matching the default regex keyword list (token, auth, sign, secret, key, password, etc.). Particularly likely in Korean/Japanese/Chinese deployments, document management systems, and file servers.

[andrewlock]

Hi @kisungyi92, thanks for raising this, and sorry to hear you ran into issues. Unfortunately, the .NET tracer does not directly target .NET 7+ (for various reasons) so this code won't work as you expect. As for the assertion that "Credential patterns (tokens, keys, passwords) are ASCII-only", I'm not sure whether that's something we can completely assert 🤔

Either way, we'll look into the issue and get back to you, thanks!