T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:357
- Finding
- Authentication Bypass Through Unverified Session Cookie<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 357–381 **Vulnerability Type**: Authentication bypass caused by trusting an unverified cookie **Risk Level**: High ### Vulnerable Code ```tsx const publicRoutes = ['/', '/login', '/register', '/api/webhooks'] const authRoutes = ['/login', '/register'] export function middleware(request: NextRequest) { const { pathname } = request.nextUrl const token = request.cookies.get('session')?.value // Public routes — allow if (publicRoutes.some(route => pathname.startsWith(route))) { // Redirect authenticated users away from auth pages if (token && authRoutes.some(route => pathname.startsWith(route))) { return NextResponse.redirect(new URL('/dashboard', request.url)) } return NextResponse.next() } // Protected routes — require auth if (!token) { const loginUrl = new URL('/login', request.url) loginUrl.searchParams.set('callbackUrl', pathname) return NextResponse.redirect(loginUrl) } return NextResponse.next() } ``` ### Technical Analysis The middleware considers a request authenticated whenever the `session` cookie contains any non-empty value. It does not cryptographically verify the cookie, resolve it against a trusted server-side session store, or validate properties such as expiration, revocation status, issuer, or audience. Cookies are controlled by the requesting client. Unless another trusted layer independently validates the session, an attacker can create an arbitrary `session` cookie and satisfy the middleware’s only authentication condition. This pattern is especially hazardous because it is presented as a production authentication pattern. Applications that copy it may rely on the middleware as their primary access-control boundary. Route-level authorization does not correct the middleware flaw unless every protected page, API handler, and Server Action independently validates the authenticated session. ### Attack Path 1. The ...[truncated 1407 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Replace cookie-presence checks with trusted session validation: 1. Use the selected authentication framework’s middleware or server-side session API rather than manually checking whether a cookie exists. 2. For signed tokens, verify the cryptographic signature and validate expiration, issuer, audience, and token type before accepting the request. 3. For opaque session identifiers, resolve the identifier through a trusted server-side session store and verify that the session is active, unexpired, and not revoked. 4. Use secure cookie settings: `HttpOnly`, `Secure`, an appropriate `SameSite` policy, a restricted `Path`, and a narrowly scoped `Domain`. 5. Reject malformed, expired, revoked, or unverifiable sessions by default. 6. Perform independent authentication and resource-level authorization in every Server Action, Route Handler, and sensitive data-access operation. Middleware should be treated as defense in depth, not the sole authorization boundary. 7. Add tests proving that arbitrary, expired, incorrectly signed, and revoked session cookies cannot access protected routes. 8. Update the Skill documentation so its production example demonstrates actual verification rather than cookie presence. A hardened conceptual pattern is: ```tsx export async function middleware(request: NextRequest) { const session = await verifySession(request) if (!session) { const loginUrl = new URL('/login', request.url) loginUrl.searchParams.set('callbackUrl', request.nextUrl.pathname) return NextResponse.redirect(loginUrl) } return NextResponse.next() } ``` `verifySession` must use a trusted authentication library or perform complete cryptographic/server-side validation; it must not merely return the cookie value. ]]>