Challenge 30 ☆☆

Welcome to challenge Challenge 30.

Another Client Secret

The client receives a random value from the server and needs to return it as the answer to prove it is the server. This often happens when, for instance, you need to provide a session token. The token is generated randomly at server startup, so you cannot find it in code. But what if we store it insecurely with the client?

💡 Tip: Secrets are often strings, numbers, or encoded values. Copy and paste exactly what you find.

There are two ways to solve this challenge:

  1. By looking at the storage:

    • Navigate to "localhost:8080" in your web browser.

    • Open the developer console by inspecting.

    • Navigate to the Applications section of the developer console.

    • The value associated with the key "secret" is your answer!

  2. By looking at the network traffic:

    • Navigate to WrongSecrets in your web browser.

    • Open the developer console.

    • Check the network tab: can you spot the extra call for this given challenge and its return value?

Why you should not use localStorage for secret information

LocalStorage persists information across sessions and is easily accessible by javascript. This means there are various ways to obtain any secret information stored in it.

There are various ways to prevent leaking secrets here: - If you don’t have to: don’t store the secret with the client: keep it on the server. - SessionStorage is also accessible to JavaScript, so it does not protect secrets from cross-site scripting. For browser sessions, prefer an opaque session identifier in a Secure, HttpOnly, SameSite cookie, with the session state kept server-side. - Do not rely on client-side encryption for a secret the client must use; the client also needs access to the decryption key. For cross-domain flows, use a server-side exchange or a short-lived, narrowly scoped token instead of storing a reusable secret in browser storage.


⬅️ Previous
🏠 Main Page
Next ➡️
0