Authentication and Access Control

Your username identifies you within an application. When you enter it at login, you're claiming that identity, and the application needs evidence before it believes you. Authentication is the process of verifying that claim, commonly by checking the password associated with the account. Once your identity has been verified, the application can decide what you're allowed to see and do.

The password check is only the start. Your browser makes more HTTP requests as you use the site, and those requests need to remain tied to the identity you proved at login. Applications commonly maintain a session for this purpose. One approach is to issue an unpredictable identifier after login and store its association with your account on the server. Later requests carry that identifier so the application can look up the authenticated user.

A developer might assume that anyone requesting a protected page has already passed through the login form. Unfortunately for that developer, your browser has no obligation to follow the intended path! If the page accepts whatever identity the request claims, the password check can be perfectly correct and still fail to protect the account. This is an authentication bypass, and it lets an attacker gain access without ever learning the victim's password.

Sign in at https://challenge.internal/ with username hacker and password 1337. Follow the requests after login and read /challenge/server to investigate how the application identifies you. Your goal is to read the flag in the admin mailbox.

The previous challenge trusted an identity supplied in the page address. Web applications more commonly carry session information in cookies, which let the browser remember a value and send it with later requests. This saves the application from having to include session information in every link and form as you navigate the site.

To set a cookie, a server includes a Set-Cookie header in its response. The browser stores the cookie and sends it back in a Cookie header on requests that match its scope, such as the domain and path it belongs to. An application can use this exchange to issue a session identifier after login and receive it again when the user requests a protected page.

The fact that the server originally set a cookie doesn't make the returned value trustworthy. A client can send a different value, and moving it out of the address bar doesn't put it beyond the user's control. The server still needs to validate its connection to an authenticated session before using it to decide who is making the request. Otherwise, we're back to taking the client's word for who they are!

In this challenge, the application uses cookies. Inspect the login response and the requests that follow to see whether the server actually verifies your identity.