Refuse invalid selectors and backward skipAfter at compile time

[ndreno]

Why

A focused review turned up two places where the engine compiled a rule set without error and then failed silently at request time, which is exactly the behaviour its compile-time refusal exists to prevent (unknown directives, unknown collections, unsupported XPath, unimplemented operators, dangling chains, and unknown markers are all refused). Both were verified with a running test, not reasoning.

Neither triggers on the OWASP Core Rule Set. This closes the gap for custom rule sets and for a CRS rule set with a typo.

1. Regex member-selectors were never validated → silent bypass

A selector like ARGS:/^user/ is compiled with the regex crate at resolve time, and a compile failure resolved to .unwrap_or(false), i.e. no members selected. check_targets validated XPath selectors but not regex ones. Demonstrated before the fix:

valid   ARGS:/^user/      compile=OK  ?user_id=attack caught=true
PCRE    ARGS:/(?=x)user/  compile=OK  ?user_id=attack caught=false   ← silent no-op
badcls  ARGS:/[a-/        compile=OK  ?user_id=attack caught=false   ← silent no-op

A selector using a construct the regex crate rejects (lookahead, invalid class, backreference) compiled fine and then silently inspected nothing — a rule turned into a bypass with no signal, while the operator-level @rx gets the full validate-and-repair path. check_targets now compiles every regex selector with the same constructor the resolver uses, and refuses the rule set if one fails.

2. Backward skipAfter → infinite loop

run_phase resumes at marker_position + 1 with no check that the marker is ahead of the rule. A marker before a rule that skips to it and keeps matching loops forever, hanging the request. Demonstrated before the fix:

compile ACCEPTED a backward skipAfter (no forward-only check)
running phase 1 ... >>> TIMED OUT: infinite loop confirmed

The marker pass only checked existence; it now also refuses a marker that is not ahead of the rule.

Not a regression on CRS

Real CRS 4.9.0 compiles to the same 590 rules with the same 4 detectSQLi/detectXSS refusals after the change — its selectors are all trivial (__utm, _pk_ref, rfi_parameter_.*) and its skips are all forward. The FTW conformance job will confirm detection is unchanged.

Tests

Four added, all passing (169 total, was 165):

• an_invalid_selector_regex_is_a_compile_error
• a_valid_selector_regex_compiles (the CRS !REQUEST_COOKIES:/__utm/ shape)
• a_backward_skip_after_is_a_compile_error
• a_forward_skip_after_still_compiles

Deliberately out of scope

Regex selectors are still recompiled per value at resolve time (162 CRS rules recompile __utm/_pk_ref per cookie per request). Caching the compiled form is a real performance win but touches the serialized rule AST, so it belongs in its own change. The evaluate-step per-value copy and the loose whole-collection exclusion prefix are two more follow-ups noted in the review.