Do not crash on a JWT with a non-base64url signature (fixes #6101)

[chan770]

Summary

Fixes #6101 — an unhandled binascii.Error that aborts the whole run when a request value matches the JWT pattern but carries a malformed/truncated signature.

Root cause

JWT_REGEX accepts a signature segment of any length ([A-Za-z0-9_-]*), and parseJWT only validates that the header and payload decode — it never checks the signature. So a value such as eyJ….eyJ….<41 chars> (41 base64url chars = length % 4 == 1, which is impossible base64) passes as a JWT with alg=HS256 and reaches crackHMAC, where decodeBase64(signature) lets binascii.Error propagate out through auditJWT / checkJWT, crashing the scan:

File "/share/sqlmap/lib/utils/jwt.py", line 99, in crackHMAC
  target = decodeBase64(data["signature"], binary=True)
...
binascii.Error: Invalid base64-encoded string: number of data characters (41) cannot be 1 more than a multiple of 4

Fix

A signature that is not valid base64url cannot be an HMAC we could verify, so crackHMAC now treats it as not crackable (returns None) instead of raising. This is the only place the untrusted signature is decoded; the header/payload decodes already sit inside parseJWT's try/except. All other auditJWT findings (alg-none, no-expiry, etc.) are unaffected.

Verification

• Reproduced the exact crash on the unpatched code; patched code returns None.
• python -m doctest lib/utils/jwt.py → 10 passed, 0 failed (includes a new regression doctest and the existing real HMAC-crack case).
• convert.py doctests → 39 passed, 0 failed.