Protection against user session attacks (hijack, replay, tampering, CSRF, XSS...)

Question

We develop a website in JAMStack, all URLs are static HTML page, and each interaction with the server are made by a fetch call on our REST API (micro-services).

When a user sign in, we want to proposes an option to permit them to stay connected as long as they want (years if neeeded). This increase the risks of interception of this session id, so we want to mitigate some attacks (hijacking, session replay, session fixation, tampering, CSRF ... )

My idea is to keep the session id in a cookie (httpOnly, sameSite, secure, path=/api/), and after sign-in to share a random secret to save in a non-extractable CryptoKey that will sign API requests like this:

crypto.sign('HMAC', CryptoKey, timestamp + API_REQUEST_URL + API_REQUEST_JSON)

I put a scenario to explain this in details. Each micro-services share a SERVER_SECRET, a random value of 128 bits

Sign-in:

 Client
   | Send JSON { email, password }
   V
 Server
   | Verify user credentials
   | Generate a random SESSION_ID of 128 bits
   | Generate a CLIENT_SECRET = sha1(SERVER_SECRET + SESSION_ID)
   | Store in DB sessions[SESSION_ID] the identity { user, authorizations, ... }
   | Add in the response header the cookie containing SESSSION_ID
   | Return JSON { CLIENT_SECRET, timestamp }
   V
 Client
   - Save CLIENT_SECRET in a non-extractable CryptoKey
   - Save in localStorage DELTA_SYNC, the delta in seconds from the server timestamp and the client

Next API requests:

 Client
   | Calcul the current TIME_STEP (current timestamp divided per 5 seconds + DELTA_SYNC)
   | Uses the CryptoKey to sign (TIME_STEP + URL + JSON)
   | Send the JSON + header x-signature
   V 
 Server
   | Calcul the current TIME_STEP
   | Extract SESSION_ID from the cookie
   | Generate the SECRET_CLIENT = sha1(SERVER_SECRET + SESSION_ID)
   | Check authenticity crypto.verify('HMAC', SECRET_CLIENT, x-signature, TIME_STEP + URL + JSON)
   |     --> If not match retry with (TIME_STEP - 5 seconds)
   | If matches, we check if the session is still alive in DB
   | Then we got the user & his authorizations to execute the request
   | (...)
   | For all responses: 
   |    - We also sign the TIME_STEP+URL+JSON and add it to the header x-signature
   |    - To prevent time desynchrosiation, we also add the header x-timestamp of our timestamp
   |      (the client can readjust the DELTA_SYNC if needed)
   V
 Client
   | Calcul the TIME_STEP and check authenticity of the answer
   

Advantages:

• If a CRSF attack steal the SESSION_ID, it's useless without the CryptoKey to sign the request
• If a XSS attack access the CryptoKey to sign, it's useless without the SESSION_ID
• Prevent replay attacks (time step of 5 seconds)
• Prevent session fixation (the SESSION_ID alone isn't enough)
• Each client/server have proof that the request/response isn't tampered
• User can stay logged as long as he want

Security questions:

1. Do you believe there is still some attacks possible to hijack the session of the user? (excepted of a physical access to the device of the victim)

Crypto questions:

1. Is it safe to generate the CLIENT_SECRET from sha1(SERVER_SECRET + SESSION_ID) or do you have any suggestions to improve this point?

Answer 1

If a CRSF attack steal the SESSION_ID, it's useless without the CryptoKey to sign the request

A CSRF attack cannot steal a cookie in the first place. It can only make use of the existing cookie for requests in the scope for the cookie. Needing the client side secret in addition to the cookie helps against this.

If a XSS attack access the CryptoKey to sign, it's useless without the SESSION_ID

XSS is script execution in the context of the current page. There are no inherent restrictions to this execution, so it might do signed API requests in the name of the user in the same way as the intended code could do it. Or it might just call internal functions which encapsulates all this functionality already.

Prevent session fixation (the SESSION_ID alone isn't enough)

Session fixation is caused by not assigning a new SESSION_ID when logging in or changing the user. If your application has this bug, then it keeps having it after adding your CLIENT_SECRET since based on your design the same SESSION_ID also results in the same CLIENT_SECRET, i.e. it has no user specific component.

Each client/server have proof that the request/response isn't tampered

Tampered by whom? If it is about MITM-attacks this is correct, but only as long as the MITM did not get the CLIENT_SECRET from the response during login. If it is about client-side tampering like with developer console, browser plugins or XSS - then there is no such proof.

Answer 2

A couple of things to note:

• since you store the SERVER_SECRET and SESSION_ID on the server side, why would you want to calculate the CLIENT_SECRET with every request and not just store it along side the SESSION_ID (e.g. at a lookup table)? That's too CPU expensive and there's not a real security benefit, because an attacker with access to the CLIENT_SECRET at the server side should be able to also access the others too
• you calculate too many things with every request; you calculate the TIME_STEP and CLIENT_SECRET, verify a signature, make a db call, recalculate the TIME_STEP in case of a glitch and (if "For all responses" you also mean error responses) you calculate a signature for each response. That's a lot to process with each request/response cycle, which is probably susceptible to a DoS attack
• DoS or not, your design will cost you a lot on CPU and network resources utilization, which is not ideal for a cloud solution