* fix(azuresastoken): match SAS tokens regardless of parameter order
The keyPat regex required a fixed parameter order
(sp, st, se, [sip], [spr], sv, sr, sig) and literal ':' in the timestamps.
Real SAS tokens vary: Azure Storage Explorer emits the parameters in a
different order (sv first, sp last) and URL-encodes the ':' in st/se as
%3A, so those tokens were silently missed.
Match a contiguous run of query parameters and validate the SAS-specific
parameters (sp, sv, sr, sig, and st/se, plus optional sip) in code instead.
This makes detection order-independent and tolerant of URL-encoded values
while preserving the previous validations (permission set, resource type,
timestamp shape, IP format) so the existing false-positive cases still
return no result.
Adds test cases for the alternate-order / URL-encoded-timestamp token and
for a non-SAS query string.
Closes#4732
* fix(azuresastoken): accept lowercase percent-encoded colons in timestamps
timeValuePat only matched uppercase %3A for the URL-encoded ':' in start
and expiry timestamps, but percent-encoding hex digits are case-insensitive
per RFC 3986, so a token encoded with %3a was silently missed. Accept
%3[Aa] in both separator positions and add a lowercase-hex test case.
* fix(azuresastoken): exclude '=' from the SAS value class
The sasQueryPat value class allowed '=', so a SAS token preceded by a
short lowercase key (e.g. 'sas=sp=r&...', or 'oken=' inside 'token=')
matched from that key: the first value greedily absorbed 'sp=r', and
since FindAllString returns non-overlapping matches the real run
starting at 'sp' was never tried. keyMatchIsSASToken then found no 'sp'
parameter and the token was silently missed.
Exclude '=' from the value class. Azure URL-encodes any '=' inside a
value (signature padding becomes %3D), so no legitimate value is dropped.
Adds a regression test for a token preceded by a lowercase assignment
(fails on the old class with zero results).
genisis0x
f38f8f7dd7