The Auth Surface
Authentication and authorization bugs pay well. JWT vulnerabilities, IDOR, and CSRF have consistently produced medium-to-critical findings across programs. The auth surface is also broader than it looks: it’s not just the login page. It’s every endpoint that makes an access decision, every token that gets issued, every session that can be fixed or stolen.
Seven capabilities cover this space; static secret extraction now lives under mg-artifact-audit apikey.
mg-jwt: Token Analysis and Attack
mg-jwt target-bounty --token <jwt>
The tool decodes the token immediately and prints the header, claims, and signature. From there, several attack paths are available:
HMAC brute-force tries a wordlist against the signature:
mg-jwt target-bounty --token <jwt> --brute --wordlist /usr/share/wordlists/rockyou.txt
Without a wordlist, a built-in list of common JWT secrets is used (secret, password,
jwt, the domain name, and similar). HMAC-SHA256 is implemented directly in the tool
with no JWT library. This avoids library variations in how “none” and algorithm
confusion attacks are handled.
Algorithm confusion tests RS256-to-HS256: grab the public key from the JWKS endpoint, sign a modified token with it as the HMAC secret, and submit it. Applications that don’t validate the algorithm field accept this.
Claim manipulation modifies the sub, role, or exp fields and re-signs with
a known secret (if brute-force succeeded) or submits unsigned to test for algorithm
acceptance without verification.
mg-authz: IDOR and BOLA Testing
mg-authz target-bounty --session-a <cookie-a> --session-b <cookie-b>
Insecure Direct Object References require two accounts. Session A creates or accesses resources. Session B, which should not have access, tries to reach the same resources.
The tool replays requests from the crawl corpus under both sessions. When session B
receives a 200 response on a resource created by session A, that’s an IDOR finding.
The test covers endpoint parameters that suggest object IDs: numeric IDs in path
segments, UUID patterns, id=, user_id=, account= query parameters.
IDOR findings are written with the specific URL, parameter, and both response bodies for comparison. The evidence section of the finding includes the full session-A resource URL and the session-B replay that succeeded.
mg-oauth: OAuth Flow Testing
mg-oauth target-bounty
The tool tests four OAuth weaknesses. First, state parameter validation: it initiates a flow, intercepts the state value, and tries submitting the authorization code without it, with a modified value, and with a predictable pattern (incrementing integer, MD5 of the client ID).
Second, redirect_uri bypass: common bypass techniques including path traversal
(/callback/../attacker), adding a path suffix, open redirect chaining to an attacker
domain, and loose validation where only the domain prefix is checked.
Third, PKCE downgrade: attempting to initiate a flow without a code challenge when PKCE is supposed to be required.
Fourth, implicit flow: testing whether the authorization server allows response_type=token
when it should only support code.
reqwest runs with redirect::Policy::none() so each Location header in the OAuth
flow is inspected rather than followed, which is necessary for detecting redirect URI
issues that only appear in the intermediate redirect.
mg-session-audit: Session Security Properties
mg-session-audit target-bounty
Four checks against the session handling:
Session fixation: set a known session ID in the cookie before authenticating, then check whether the same session ID is preserved after login. If it is, an attacker who plants a session cookie before the user logs in inherits the authenticated session.
Cookie flags: every Set-Cookie header inspected for Secure, HttpOnly, SameSite,
and Max-Age. Missing HttpOnly means XSS can steal the token. Missing Secure means
the cookie transmits over HTTP. These findings compound with other vulnerabilities.
Token entropy: the session token is base64 decoded and run through a basic entropy check. Short tokens or tokens with obvious patterns (incrementing, timestamp-based) are flagged.
Logout invalidation: makes an authenticated request to confirm the session works, logs out, then replays the same authenticated request. A 200 response after logout means the session token is still valid server-side.
mg-artifact-audit apikey: Static Secret Detection
mg-artifact-audit apikey target-bounty
mg-artifact-audit apikey operates on the crawl corpus without making any network requests. It reads
every file in crawl/ and runs a regex catalog against the content. The catalog is
compiled once at startup via OnceLock and covers AWS keys, GitHub tokens, Stripe
keys, Slack webhooks, Twilio tokens, generic api_key and secret patterns, and
several others.
Matched secrets are masked to the first 8 characters in the output to avoid full exposure in findings files. The full value is available in the raw crawl file if needed for validation.
This is similar to what mg-crawl does during the crawl phase, but runs post-hoc
against any crawl corpus, including ones that have been augmented manually.
mg-brute: Credential Testing
mg-brute target-bounty --login-url https://target.example.com/login
When no credential lists are provided, the tool uses built-in lists of common
username and password combinations. Custom lists are loaded with --userlist and
--passlist.
Lockout detection watches for 429 and 403 responses. When lockout is detected, the tool pauses and logs the condition rather than continuing and locking out all tested accounts.
Successful credentials are printed to stdout immediately when found and written to
findings/ as a CRITICAL finding. The finding includes the URL, the successful
credential pair (password masked), and the response evidence.
mg-csrf: Cross-Site Request Forgery
mg-csrf target-bounty
The tool first identifies state-changing endpoints: POST, PUT, PATCH, DELETE requests
from the crawl corpus. For each, it checks three things: whether a CSRF token is
present in the form or request, whether the session cookie has a SameSite attribute,
and whether the server validates the Origin header.
Severity depends on the combination:
- No CSRF token and no
SameSitecookie: HIGH. Both mitigations are absent. - One mitigation present, one absent: MEDIUM.
- Both present: informational note only.
Origin validation is tested by replaying the state-changing request with a modified
Origin header pointing to an external domain. If the server accepts it, the
Origin check is not a real mitigation.
Auth Testing in Sequence
These capabilities work best run in order: mg-jwt and mg-artifact-audit apikey
first (static analysis, no traffic), then mg-session-audit (single authenticated
session), then mg-authz
(two-session comparison), then mg-csrf and mg-oauth (flow testing). Credentials
found by mg-brute or secrets found by mg-artifact-audit apikey feed directly into subsequent
tests. An API key found in the crawl corpus might unlock additional endpoints that
become new targets for injection testing or
IDOR testing.