Cyber Security Quiz: Session Management
10 questions · exam conditions
0:00
Session ManagementQuestion 1 of 10

A session starts at 09:00. The service enforces a 20-minute idle timeout and an eight-hour absolute lifetime. The user remains active throughout the day and successfully sends a request at 16:55. The next request arrives at 17:05.

How should the service handle the request at 17:05 if both timeout policies are correctly enforced?

Accept it because only 10 minutes have elapsed since the user's most recent activity.
Accept it and reset both the idle timeout and the absolute lifetime from 17:05.
Reject it because the absolute lifetime ended at 17:00 despite the recent activity.
Reject it because the idle timeout is measured from the original login rather than recent activity.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Session Management

Practice Session Management in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Session Management, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A session starts at 09:00. The service enforces a 20-minute idle timeout and an eight-hour absolute lifetime. The user remains active throughout the day and successfully sends a request at 16:55. The next request arrives at 17:05.

How should the service handle the request at 17:05 if both timeout policies are correctly enforced?

  1. Accept it because only 10 minutes have elapsed since the user's most recent activity.
  2. Accept it and reset both the idle timeout and the absolute lifetime from 17:05.
  3. Reject it because the absolute lifetime ended at 17:00 despite the recent activity. (correct answer)
  4. Reject it because the idle timeout is measured from the original login rather than recent activity.
Explanation: When a service manages session security, it typically enforces two independent timeout policies simultaneously: an idle timeout (which resets with each user action) and an absolute lifetime (which never resets, regardless of activity). The critical insight is that these policies are independent — satisfying one does not override the other. Here, the session begins at 09:00, so the eight-hour absolute lifetime expires at exactly 17:00. When the request arrives at 17:05, the session has already exceeded its absolute ceiling. C is correct: the service must reject the request because the absolute lifetime ended at 17:00, and no amount of recent activity can extend it. The absolute lifetime exists precisely to prevent indefinitely extended sessions through continuous use. Choice A is the most tempting trap — it correctly observes that only 10 minutes have passed since the 16:55 request, which would satisfy the 20-minute idle timeout. However, it ignores that both policies must pass simultaneously. Clearing one hurdle while failing the other still results in rejection. Choice B compounds this error further by suggesting both timers should reset at 17:05, which fundamentally misunderstands absolute lifetime — by definition, it cannot be reset mid-session. Choice D introduces a false rule: idle timeouts are correctly measured from the most recent activity, not from login time. That part of D's reasoning is backwards, making it wrong for the opposite reason. A useful study habit: whenever you see a session management scenario, ask yourself whether all active policies are satisfied, not just the most obvious one. Absolute lifetimes are easy to overlook precisely because recent activity makes a session feel legitimate.

Question 2

An application sets its session identifier in a cookie with no Expires or Max-Age attribute. The server-side session record remains valid for four hours. A user closes a browser that is configured to discard session cookies on exit. An attacker has already copied the identifier and submits it from another client before the four-hour server timeout.

Which statement best describes the session's status?

  1. Closing the user's browser invalidates the server record, so the copied identifier can no longer be accepted.
  2. The cookie becomes persistent for four hours because the server-side record has a four-hour expiration.
  3. The user's browser discards its cookie, but the copied identifier may remain valid until server-side invalidation or expiration. (correct answer)
  4. The copied identifier fails because cookies without Expires are cryptographically bound to the browser process that created them.
Explanation: When you see a question about session cookies and hijacking, the key distinction to keep in mind is that client-side cookie storage and server-side session validity are completely independent systems. A browser discarding its copy of a cookie does nothing to the server's session record — those are two separate things. Here's the core logic: when no Expires or Max-Age attribute is set, the cookie is a session cookie, meaning the browser holds it only until the window closes. Once the user closes the browser, their local copy is gone. However, the server-side session record has its own four-hour lifespan, completely unaffected by what the browser does. An attacker who already copied the raw session identifier can replay it directly in an HTTP request — no browser cookie required. The server sees a valid token, checks its own records, finds an active session, and grants access. Answer C correctly captures this: the user's browser discards its copy, but the copied identifier remains valid until the server explicitly invalidates or expires it. A is wrong because closing the browser never reaches out to the server to terminate the session — the server has no awareness of the browser closing. B is wrong because the server-side expiration does not retroactively make the client cookie persistent; cookie persistence is a purely client-side attribute controlled by Expires/Max-Age. D is wrong because cookies carry no cryptographic binding to a specific browser process — they are simply strings, freely copyable and replayable. A useful rule of thumb: true session termination requires explicit server-side invalidation (like a logout endpoint). Relying on cookie expiry alone leaves the server-side session dangling and vulnerable to exactly this replay scenario.

Question 3

Two APIs trust tokens signed by the same identity provider. A token has a valid signature, has not expired, contains the audience api-a, and includes the scope required for a read operation. The token is presented to API B. API B currently validates only the signature, issuer, and expiration.

What should API B do to prevent this token from being used as a valid session credential for the wrong service?

  1. Accept the token because a common trusted issuer makes tokens interchangeable among all of its APIs.
  2. Reject the token because API B must validate that the audience claim identifies API B as an intended recipient. (correct answer)
  3. Accept the token because possession of the required operation scope overrides an audience mismatch.
  4. Reject the token only if it was transmitted in a cookie rather than an Authorization header.
Explanation: Whenever you see a question about API authentication and JWT (JSON Web Token) validation, think beyond just signature verification — a valid signature only proves the token is authentic, not that it was meant for you. JWTs include an aud (audience) claim that explicitly names which service(s) the token is intended for. In this scenario, the token carries aud: api-a, meaning the identity provider issued it specifically for API A. Even though API B trusts the same issuer and the signature is cryptographically valid, API B is not the intended recipient. If API B skips audience validation, any token issued to any service from the shared identity provider could be replayed against API B — a classic token confused deputy or cross-service token replay attack. The correct fix is B: API B must verify that its own identifier appears in the audience claim before accepting the token as a valid credential. A is wrong because sharing a trusted issuer does not make tokens interchangeable. Audience scoping exists precisely to prevent this assumption — a token is a targeted credential, not a universal pass. C is wrong because scope and audience serve different purposes. Scope controls what operations a token may perform; audience controls which services may honor it. Having the right scope on the wrong service doesn't override the audience mismatch. D is wrong because the transmission mechanism (cookie vs. Authorization header) is irrelevant to audience validation. The flaw exists regardless of how the token was delivered. Study tip: Remember the JWT validation checklist: signature → issuer → expiration → audience. Skipping any one of these creates a distinct vulnerability.

Question 4

A single-page application keeps its access token only in JavaScript memory and sends it in an Authorization header. The API does not accept the token from cookies or URL parameters. Cross-origin requests using that header are not permitted by the API's CORS policy, and the application has no script-injection vulnerability.

Compared with automatically sending an authentication cookie, what session-security effect does this design have?

  1. It reduces conventional CSRF exposure because an attacker's cross-origin page cannot cause the browser to automatically attach the token header. (correct answer)
  2. It eliminates token theft because credentials stored in JavaScript memory are not accessible through any client-side technique.
  3. It increases conventional CSRF exposure because browsers automatically append Authorization headers to cross-site form submissions.
  4. It makes CORS irrelevant because the same-origin policy governs cookies only, not custom request headers.
Explanation: When you see a question comparing cookie-based authentication to token-in-memory authentication, the core concept being tested is how CSRF attacks work — specifically, what the browser sends automatically versus what JavaScript must explicitly attach. Classic CSRF exploits the browser's automatic behavior: when your browser makes a cross-origin request to a target site, it automatically includes any cookies for that site. An attacker's malicious page can silently trigger requests that carry the victim's session cookie without any JavaScript involvement. This is why CSRF tokens and SameSite cookie attributes exist. The design in this passage breaks that automatic attachment chain. The access token lives only in JavaScript memory and must be deliberately injected into the Authorization header by application code. A cross-origin attacker page has no ability to read that token from memory (due to same-origin policy) or cause the browser to attach it automatically — browsers simply don't forward custom Authorization headers on cross-origin requests the way they forward cookies. This makes A correct: conventional CSRF exposure is reduced because the attacker cannot weaponize the browser's automatic credential-forwarding behavior. B is wrong because "no client-side technique can access it" is an overstatement — if the application were vulnerable to XSS, injected scripts could read memory. The passage explicitly notes no XSS vulnerability exists, but that's a contextual assumption, not a universal truth about memory storage. C is factually incorrect. Browsers do not automatically append Authorization headers to form submissions or cross-site requests — that header requires explicit JavaScript code. D is wrong because CORS absolutely governs custom headers on cross-origin requests, not just cookies. A useful mental model: ask yourself, "Can the attacker make the browser do this without JavaScript?" If yes, CSRF is a risk. If the attack requires JavaScript execution in the victim's origin, it's an XSS problem instead.

Question 5

Before a victim signs in, an attacker causes the victim's browser to use a session identifier known to the attacker. The application preserves that same identifier when the anonymous session becomes authenticated.

Which session-management change most directly prevents the attacker from reusing the known identifier as an authenticated session?

  1. Regenerate the session identifier immediately after authentication and invalidate the preauthentication identifier on the server. (correct answer)
  2. Mark the existing identifier HttpOnly after authentication while preserving its value and associated server-side session.
  3. Extend the existing session's expiration after authentication so the victim is not prompted to sign in again.
  4. Hash the existing identifier in application logs while continuing to accept its original value from the browser.
Explanation: Whenever you see a scenario where an attacker plants a session identifier before authentication and the application keeps using it after authentication, you're looking at a session fixation attack. The core vulnerability is that the server treats the pre-authentication session as valid for the authenticated state — so the fix must sever that continuity. Option A directly dismantles the attack: by regenerating a brand-new session identifier the moment the user authenticates and invalidating the old one server-side, the attacker's known identifier becomes worthless. Even though the attacker knows the original value, the server no longer honors it. This is the standard, well-established defense against session fixation. Option B is a trap. Marking the cookie HttpOnly only prevents JavaScript from reading it — it does nothing to prevent the attacker from using the already-known identifier, since the attacker obtained it before this flag was set. The identifier's value and server mapping remain intact, so the session is still hijackable. Option C extends the attack window rather than closing it. Keeping the same identifier longer simply gives the attacker more time to exploit the session they already know about. Expiration management addresses timeout policies, not fixation. Option D is cosmetic and irrelevant to the attack vector. Hashing the identifier in logs doesn't change what the server accepts from the browser. The original value still authenticates successfully, so nothing is actually protected. The study tip here: for session fixation, always ask "does this fix break the link between the old identifier and the new authenticated state?" If the answer is no, it's not a real defense. Regeneration on authentication is the canonical answer.

Question 6

An application authenticates users with a cookie configured as Secure, HttpOnly, and SameSite=Lax. An attacker hosts a page that automatically submits a cross-site POST request to the application's funds-transfer endpoint. The endpoint relies only on the authentication cookie and does not use a separate anti-CSRF token.

Which outcome is most likely in a modern browser using the stated cookie configuration?

  1. The cookie is included because Secure permits transmission on any HTTPS request, including cross-site POST requests.
  2. The cookie is withheld on the cross-site POST, although it could be included during some top-level cross-site GET navigations. (correct answer)
  3. The cookie is included because HttpOnly prevents script access but does not impose any cross-site transmission restrictions.
  4. The cookie is withheld from every cross-site request, including top-level links that use a safe HTTP method.
Explanation: When you see a question involving cookie attributes and cross-site requests, your focus should immediately shift to SameSite — it's the attribute specifically designed to control cross-site transmission, and it's the heart of CSRF protection. SameSite=Lax is a middle-ground policy. It withholds the cookie on cross-site subrequests (like auto-submitted forms, images, or fetch calls) but does allow it on top-level navigations using safe methods like GET. So when an attacker's page silently fires a cross-site POST, the browser recognizes this as a cross-site subrequest with an unsafe method and withholds the cookie — meaning the funds-transfer endpoint receives no authentication credential and the attack fails. However, if someone clicked a link that triggered a top-level GET navigation to the site, the cookie would be sent. That nuance is exactly what B captures, making it the correct answer. A is wrong because Secure only enforces that the cookie travels over HTTPS — it says nothing about whether the cookie crosses site boundaries. Conflating "secure channel" with "permitted on any request" is a classic trap. C is wrong for a similar reason: HttpOnly prevents JavaScript from reading the cookie via document.cookie, but it imposes zero restrictions on which requests the browser attaches it to. D overstates the restriction. SameSite=Lax is not as strict as SameSite=Strict; it still permits the cookie on top-level GET navigations, so saying it's withheld from every cross-site request is inaccurate. For your exam, memorize the three SameSite values as a spectrum: None sends always, Lax sends on top-level safe navigations only, and Strict never sends cross-site. Questions will frequently test whether you can distinguish Lax from Strict.

Question 7

A service issues signed, self-contained access tokens that expire after 30 minutes. It does not maintain a token denylist or consult a server-side session record for each request. A user logs out five minutes after a token is issued, and the logout process deletes the browser's copy of the token.

What happens if an attacker copied the token before logout and presents it 10 minutes later?

  1. The token is rejected because deleting the browser's copy also invalidates the token's server-side signature.
  2. The token is accepted until its expiration unless another revocation mechanism is added to token validation. (correct answer)
  3. The token is rejected because every signed token implicitly depends on an active browser cookie.
  4. The token is accepted indefinitely because signed self-contained tokens cannot contain expiration claims.
Explanation: When a question describes tokens that are "signed" and "self-contained," your mind should jump to stateless authentication — most commonly JWTs. The critical design trade-off here is that stateless tokens carry all their own validation data (signature, expiration, claims) and require no server-side lookup. This efficiency comes at a cost: the server has no memory of individual tokens, so it cannot unilaterally "forget" one before it expires. In this scenario, the token was issued with a 30-minute lifetime. Deleting it from the browser removes the client's copy, but the token itself remains cryptographically valid. When the attacker presents it 10 minutes after logout — still within the 25-minute window remaining — the server checks the signature (valid) and the expiration claim (not yet reached), and accepts it. B is correct: without an added revocation mechanism like a denylist or short-lived session record, the token works until it expires naturally. A is wrong because browser-side deletion has zero effect on a token's cryptographic signature. Signatures are generated server-side at issuance; deleting a copy of the token elsewhere doesn't alter or revoke that signature. C is wrong because stateless tokens are explicitly designed to be independent of cookies or server sessions — that's the whole architectural point. Tying validity to a browser cookie would defeat the purpose. D is wrong because self-contained tokens absolutely can — and in practice almost always do — include an expiration claim (exp in JWT terminology). Expiration is a standard feature, not a contradiction. As a study rule: whenever you see "stateless tokens" paired with "logout," immediately ask yourself whether a revocation mechanism exists. If it doesn't, logout is only cosmetic.

Question 8

A web application uses an opaque cookie as the identifier for a server-side authenticated session. Its logout endpoint responds by setting the cookie's expiration to a time in the past, but it leaves the corresponding server-side session record active.

Which modification provides the strongest logout behavior against an attacker who copied the cookie before logout?

  1. Invalidate the server-side session record and also instruct the browser to remove its session cookie. (correct answer)
  2. Remove only the browser cookie and shorten the server-side session's idle timeout for future logins.
  3. Change the cookie's Path attribute while preserving the existing identifier and server-side record.
  4. Mark the deleted cookie Secure and HttpOnly while leaving the copied identifier active.
Explanation: When analyzing session management and logout security, the key question to ask is: where is the session's source of truth? In server-side session architectures, the server holds the authoritative record — the cookie is merely a pointer to it. A secure logout must destroy that server-side record, not just manipulate the cookie. Answer A is correct because it attacks both sides of the session simultaneously. By invalidating the server-side session record, the server will reject any future requests carrying that session identifier — even if an attacker has a perfect copy of the cookie. Instructing the browser to delete its cookie is good hygiene, but the server-side invalidation is what actually closes the door on the stolen credential. Answer B only shortens the idle timeout for future sessions, doing nothing about the currently stolen, still-active session record. The attacker's copied cookie remains fully functional until the old session naturally expires. Answer C changes the Path attribute while keeping the same session identifier and server-side record intact. This is purely cosmetic — the session is still alive, and the attacker's cookie still maps to a valid server-side record regardless of path scoping. Answer D adding Secure and HttpOnly flags to an already-deleted cookie is meaningless. These flags govern how the browser handles the cookie during active use; they offer zero protection against a cookie that was already exfiltrated before logout. Study tip: On session-security questions, always distinguish between the token (cookie) and the session record (server state). An attacker who steals the token bypasses any client-side cookie manipulation — only revoking the server-side record provides real protection.

Question 9

A load-balanced application stores opaque-session records only in each web server's memory. Requests are distributed across servers without session affinity. Users intermittently appear logged out when consecutive requests reach different servers. The organization also requires logout to invalidate a session immediately across all servers.

Which change best satisfies both reliable session continuity and immediate centralized invalidation?

  1. Replicate the session cookie under several names so that each server can select whichever copy matches its own local session store.
  2. Enable permanent session affinity so that each client always reaches the same server, continuing to store sessions only in that server's local memory.
  3. Replace the opaque identifier with a long-lived signed token that every server validates independently without consulting any shared state.
  4. Store session records in a shared server-side repository so that every web server validates the opaque identifier against a single, consistent data store. (correct answer)
Explanation: When a question describes session state spread across multiple servers with no shared store, your immediate focus should be: where does session truth live, and who can reach it? Any solution must answer two demands simultaneously — continuity across servers and instant, global invalidation. The approach that satisfies both requirements is D: moving session records into a shared, centralized repository (think Redis, a database, or a dedicated session store). Every web server queries the same data store on each request, so it doesn't matter which server the load balancer routes you to — they all see identical, up-to-date session state. Invalidation is equally simple: delete or expire the record in one place, and every server immediately sees it as invalid on the next lookup. A is a creative-sounding but hollow fix. Replicating a cookie under multiple names doesn't solve the core problem — each server still checks only its own local memory. If your session lives on Server 1, Server 2 still won't find it under any cookie name. B (sticky sessions / session affinity) solves continuity but breaks invalidation. If a server crashes or a user's affinity is disrupted, the session vanishes. More critically, you cannot guarantee immediate invalidation across all servers because sessions remain siloed per server. C describes a stateless signed token (like a JWT). These are self-contained, so no server needs shared state — but that's precisely the problem. Without a shared revocation list, you cannot immediately invalidate a token before it naturally expires. A useful rule of thumb: whenever a question pairs "load balancing" with "immediate invalidation," centralized server-side state is almost always the right architectural answer.

Question 10

A client and an attacker both possess refresh token R1. The legitimate client uses R1 first and receives access token A2 and refresh token R2. The authorization server marks R1 as used. The attacker later attempts to exchange R1.

Under refresh-token rotation with reuse detection, what is the most security-focused response to the attacker's later request?

  1. Reactivate R1 and invalidate R2 because simultaneous possession proves the legitimate client used the wrong token.
  2. Reject R1 but preserve R2 because the legitimate client exchanged the older token before the attacker.
  3. Accept R1 one more time but issue an access token with a shorter lifetime and no replacement refresh token.
  4. Reject R1, revoke the associated refresh-token family including R2, and require the client to authenticate again. (correct answer)
Explanation: When you see a question about OAuth refresh-token security, focus on what the protocol is actually defending against: token theft that goes undetected. Refresh-token rotation with reuse detection exists precisely for this scenario — if a used token appears again, the system cannot determine who is legitimate, so it must assume compromise and act aggressively. That logic makes D the correct answer. When the attacker presents the already-used R1, the server cannot distinguish whether the attacker or the legitimate client is the bad actor. The safest response is to revoke the entire token family — including the legitimately issued R2 — and force reauthentication. Yes, this disrupts the real user temporarily, but it guarantees the attacker gains nothing and forces the legitimate user to re-establish trust through full credentials. A is backwards: reactivating R1 and invalidating R2 would actually reward the attacker's replay attempt and punish the legitimate client who followed the protocol correctly. B sounds reasonable but is dangerously incomplete. Rejecting R1 while preserving R2 leaves a live token in circulation during a confirmed theft event. The attacker may have already compromised more of the session than you know. C is a classic "compromise" trap — issuing a short-lived access token to a suspicious request still grants the attacker some access, which no security-focused design should permit after detecting a reuse event. Study tip: On security questions, watch for answers that seem "balanced" or "lenient" — real security protocols under confirmed attack scenarios prioritize containment over convenience. When token reuse is detected, the correct posture is always revoke-all, not revoke-some.