# Auth Bypass

> >

- **Type:** Skill
- **Install:** `agentstack add skill-shulkwisec-bb-huge-auth-bypass`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [ShulkwiSEC](https://agentstack.voostack.com/s/shulkwisec)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [ShulkwiSEC](https://github.com/ShulkwiSEC)
- **Source:** https://github.com/ShulkwiSEC/bb-huge/tree/main/skills/curated/auth-bypass

## Install

```sh
agentstack add skill-shulkwisec-bb-huge-auth-bypass
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Authentication Bypass

## What Is Broken and Why

Authentication logic applied only at the login page leaves all downstream pages unprotected.
Applications relying on client-supplied flags (`authenticated`, `role`, `admin`) to gate access
allow trivial bypass by modifying those values. Predictable session tokens enable forging.
Insecure deserialization in cookie handling allows boolean type juggling to short-circuit
credential verification. Credentials transmitted over HTTP expose them to passive interception.
Browser caching of authenticated responses allows offline credential harvesting from shared machines.

## Key Signals

- Login redirect but direct URL access to `/dashboard`, `/admin`, `/profile` returns 200
- Parameters like `authenticated=`, `isAdmin=`, `role=`, `debug=`, `fromtrustIP=` in GET/POST/cookies
- Session cookies with sequential, time-based, or partially-static values
- Login form accepting `' OR '1'='1` or similar SQL payloads
- Application serializes auth state into cookies (`a:2:{s:11:"autologinid";...}`)
- Login or registration form submitting over `http://` instead of `https://`
- Absence of `Secure` flag on session cookies
- No `Cache-Control: no-store` on pages containing sensitive data
- `Set-Cookie` not issuing new token after successful authentication (session fixation overlap)

## Methodology

1. **Map all authenticated endpoints**: Spider application; note every URL requiring login.
2. **Forced browsing**: Without authenticating, request each protected URL directly. Record any
   that return 200 or partial content.
3. **Parameter tampering**: Intercept login and post-login requests; add or modify boolean
   parameters (`authenticated=yes`, `admin=true`, `debug=true`, `fromtrustIP=true`).
4. **Cookie manipulation**: Decode cookies (base64, URL, serialization); identify role/auth fields;
   modify and re-submit.
5. **Session prediction**: Collect 50+ session tokens under identical conditions; analyze for
   patterns (incrementing integers, timestamp encoding, partial static prefix).
6. **SQL injection on login**: Attempt classic payloads in username/password fields.
7. **Deserialization probe**: If PHP serialized format detected in cookie, craft boolean bypass.
8. **Transport test**: Replace `https://` with `http://` for login, registration, and password
   flows; observe if credentials submit over plain HTTP.
9. **Cache test**: Log in, log out, press Back; reload authenticated pages; check local cache files.

## Payloads & Tools

```bash
# Forced browsing — direct access to protected page
curl -s http://TARGET/admin/dashboard -o /dev/null -w "%{http_code}"

# Parameter tampering via GET
curl "http://TARGET/home?authenticated=yes&admin=true"

# SQL injection on login form
# Username field: ' OR '1'='1'--
# Password field: anything
curl -X POST http://TARGET/login \
  -d "user=' OR '1'='1'--&pass=x"

# PHP unserialize boolean bypass cookie
# Original: a:2:{s:11:"autologinid";s:32:"";s:6:"userid";s:1:"2";}
# Bypass:   a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
# Encode to base64 and set as cookie value
python3 -c "
import base64
payload = b'a:2:{s:11:\"autologinid\";b:1;s:6:\"userid\";s:1:\"2\";}'
print(base64.b64encode(payload).decode())
"

# Check if login submits over HTTP
curl -v -X POST http://TARGET/login \
  -d "user=admin&pass=PASSWORD" 2>&1 | grep -E "< HTTP|Location:|Set-Cookie"

# Verify Secure flag on session cookie
curl -I https://TARGET/login | grep -i "set-cookie"

# Check cache headers on sensitive pages
curl -I https://TARGET/account/profile | grep -iE "cache-control|pragma|expires"
```

## Bypass Techniques

- If login page redirects to HTTPS but form action is still HTTP, credentials are transmitted
  unencrypted.
- `Cache-Control: private` does NOT prevent local browser caching; only `no-store` does.
- Applications that check `$_GET['authenticated']` but not `$_POST['authenticated']` may be
  bypassed by moving the parameter to the query string.
- PHP type juggling: `"0e123" == "0e456"` evaluates true; password hash comparison bypasses
  possible if hash begins with `0e`.
- Encoded/encrypted cookie values containing auth state may still be decodable if using weak
  schemes (XOR, base64-only, ECB mode).

## Exploitation Scenarios

**Scenario 1 — Forced Browse to Admin Panel**
Setup: Application checks auth only at `/login`; `/admin/` has no server-side session check.
Trigger: Unauthenticated GET to `http://TARGET/admin/users`.
Impact: Full administrative interface accessible without credentials.

**Scenario 2 — PHP Unserialize Boolean Bypass**
Setup: Application stores serialized PHP array in cookie for "remember me" functionality.
Trigger: Replace password hash field with `b:1` (boolean true); server evaluates `true == hash`
as true due to loose comparison.
Impact: Login as any known user ID without knowing their password.

**Scenario 3 — Credential Interception via HTTP**
Setup: Login page loads over HTTPS but form POSTs to `http://TARGET/authenticate`.
Trigger: Passive network capture on shared network (coffee shop, corporate proxy).
Impact: Plaintext username and password captured; full account takeover.

## False Positives

- A 200 response on a forced browse may be the login redirect rendered client-side (SPA),
  not actual unauthorized access to data.
- Debug parameters present in requests may be logged but not processed by server; verify
  actual behavior change, not just parameter acceptance.
- Sequential-looking session IDs may include a cryptographic HMAC suffix that prevents forging.

## Fix Patterns

- Enforce server-side session validation on every protected route, not just at login.
- Never trust client-supplied authentication state flags; derive auth state from server session.
- Use cryptographically random session IDs (256-bit entropy, minimum 50 characters).
- Set `Secure` and `HttpOnly` flags on all session cookies.
- Redirect all HTTP traffic to HTTPS; deploy HSTS.
- Use strict PHP comparison (`===`) to prevent type juggling in authentication checks.
- Set `Cache-Control: no-cache, no-store` and `Pragma: no-cache` on all authenticated responses.

## Related Skills

[[default-credentials]] is the first thing to try once a login form is found — auth bypass and default creds are two paths to the same goal. [[password-reset-flaws]] represents another common bypass vector: a weak reset flow can grant access without ever attacking the login form directly. If a SQL injectable login is found, [[sql-injection]] contains the full methodology for exploiting it. When a session cookie is obtained, validate its security posture using [[cookie-attacks]].

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [ShulkwiSEC](https://github.com/ShulkwiSEC)
- **Source:** [ShulkwiSEC/bb-huge](https://github.com/ShulkwiSEC/bb-huge)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-shulkwisec-bb-huge-auth-bypass
- Seller: https://agentstack.voostack.com/s/shulkwisec
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.