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. - If the client requires a secret for a state within one domain: use the SessionStorage, which is bound to a given domain. - If a secret must be shared over multiple domains but does not need to be known by the client (e.g. the client just forwards it between an identity provider and multiple servers, for instance, at different domains): encrypt the secret. Alternatively, make sure servers can connect to each other on behalf of the client, so that the client does not need to send the secret along.


⬅️ Previous
🏠 Main Page
Next ➡️
0