pwn.college - Talking Web - State

Main ideas / concepts

• Web applications are remote programs

  • Modern web apps aren’t just static files (e.g., images). They’re typically programs running on remote servers.
  • The browser communicates with the remote server over HTTP.

• Programs can be “stateful”

  • “State” is what changes over time for an interactive program.
  • Examples: logging in, account details, online banking—where the server needs to remember who you are and what actions happened.

• HTTP is stateless (protocol-level statelessness)

  • Even if the web application is stateful, HTTP itself is stateless.
  • The server cannot automatically know which client made a previous request because HTTP does not inherently bind requests together.

• Why normal “remembering” doesn’t work in HTTP

  • If you POST login credentials, the server can respond, but future requests won’t automatically be associated with that prior login.
  • The protocol provides no built-in “this is the same client as before” mechanism.

Instructional / mechanism: how to maintain state with cookies

• Use HTTP cookies to carry state between requests
  • Server → Client: respond with a Set-Cookie header.
  • Client → Server (future requests): include the cookie using the Cookie header.
  • Because the client keeps sending the cookie back, the server can use it to recover the prior state.

Example: login state via cookie value

• Login request

  • POST to a login resource like account.example.com/login (described as account.agample.com in the subtitles).
  • Send form data (URL-encoded) including:
    • username=Connor
    • password=password (hypothetical correct credentials)

• Server response behavior

  • The server sets a cookie in the response header:
    • Set-Cookie: off=Connor
  • It also returns a redirect status:
    • 302 “Moved Temporarily”
  • The client is expected to make another request to the root resource (e.g., /) and include the cookie.

• Subsequent request

  • The browser sends future requests including:
    • Cookie: off=Connor
  • The server reads the cookie and responds with stateful behavior, e.g.:
    • “Hello Connor…”

• Demonstrating persistence across users

  • Another user (e.g., CANAC / “Kanek” in the subtitles) logs in:
    • Server sets: Set-Cookie: off=CANAC
  • When that user requests / again with Cookie: off=CANAC, the server responds:
    • “Hello CANAC…”
  • Key point: state is maintained because each client includes its own cookie value.

Security concern: raw state in cookies can be forged

• Problem

  • Since HTTP requests are just messages, an attacker can craft their own requests.
  • The server may trust cookie contents too much.
  • Example scenario:
    • If the server treats off as “the username” directly,
    • an attacker could send Cookie: off=admin without ever performing the login,
    • and the server might respond “Hello admin…”

• Why this happens

  • HTTP doesn’t enforce that the login previously occurred.
  • The server is basically acting on whatever state the cookie claims.
  • This is framed as a likely source of security issues that will be explored later.

• Important takeaway

  • Web applications must assume clients can generate arbitrary HTTP requests.
  • You should not assume users will only send cookies that the server “told them to send.”

Better approach mentioned: session IDs instead of raw identity

• Recommended mitigation

  • When logging in, don’t store raw “who the user is” (e.g., off=Connor) as directly trusted identity.
  • Instead, store an unguessable session ID in the cookie.

• How session-based state works

  • On login:
    • Server creates a server-side record in a database:
      • session ID → which user it represents (e.g., Connor)
    • Client receives:
      • Set-Cookie: session=<difficult-to-guess-id>
  • On future requests:
    • Client includes:
      • Cookie: session=<id>
    • Server looks up that session ID in its database and authorizes accordingly.

• Same underlying idea, safer use

  • Both methods use cookies to maintain state, but:
    • Raw identity in cookies can be forged if trusted directly.
    • Session IDs are harder to guess and validated server-side.

When raw cookie state may be acceptable

• The lecture notes there can be cases where storing non-sensitive preferences directly in cookies is fine, such as:
  • Theme selection (e.g., theme=dark vs theme=light)
  • If a forged theme value only changes presentation (not privileges), it may not create a security risk.

Overall lesson

• Understanding HTTP’s stateless nature is critical because:
  • The standard format and behavior of HTTP enables cookie-based state transfer,
  • which can lead to common security problems if the server trusts client-provided values incorrectly.
• As a developer, you must design state and authentication/authorization logic with the assumption that clients can construct arbitrary HTTP requests.

---

Speakers / sources featured

• Speaker: The course lecturer (unnamed in subtitles) presenting pwn.college lecture content.
• Source referenced: RFC 1945 (cited as the reference indicating HTTP is stateless).