Security Enhancement: Tamper Proofing State with Cryptographic Signatures

[5fff]

Summary

This proposal addresses a security vulnerability in Mesop's core state management architecture. Currently, the server blindly trusts the state object sent back from the client during UI events. An attacker can maliciously tamper with this state on the client-side, leading to serious security risks.

I propose implementing a cryptographic signature mechanism, similar to JWT, to verify the integrity of the state object on every request, ensuring it has not been modified by the client.

Background: The Current State Management Flow

Mesop's stateless server architecture is a key design feature that enables a great developer experience, including seamless hot-reloading. The flow is as follows:

1. The server sends the initial UI component tree and the complete state object to the client's browser.

2. When a user interaction triggers an event, the browser makes a POST request to the /ui endpoint.

3. Crucially, this request payload includes the entire state object as it exists on the client.

4. The Mesop server uses this client-provided state to run the event handler, re-render the UI, and send the new state back to the client.

The security issue lies in step 4: The server implicitly trusts that the state object received from the client has not been tampered with.

The Vulnerability: Client-Side State Tampering

Because the state is controlled by the client, a malicious actor can easily intercept the outgoing /ui request using browser developer tools and modify the state payload.

Example Attack Scenario:

Imagine a state object with a user authorization flag:

@me.stateclass
class State:
  is_admin: bool = False
  # ... other UI state properties

An attacker could perform an action, intercept the request, and change the JSON payload from {"is_admin": false} to {"is_admin": true}. The stateless server would receive this modified state and, without any integrity checks, might grant the user administrative privileges for the duration of that request's processing.
This forces security-conscious developers to distrust the me.state object completely and re-validate every piece of data against a server-side source of truth on every event. This undermines the convenience of the state management system and introduces a significant risk for developers who are not aware of this underlying trust issue.

Proposed Solution: State Signing and Verification

To fix this, we can adopt the proven model used by technologies like JWT to ensure data integrity. The server should sign the state object before sending it to the client and verify that signature upon its return.

Proposed Workflow:

1. Generate a Secret Key: The Mesop server should use a secret key (e.g., configured via a MESOP_SECRET_KEY environment variable or retrieved from Secret Store). This key must remain private to the server.
2. Sign the State: When the server is about to send the state to the client, it serializes the state object and uses the secret key to create a cryptographic signature (e.g., using HMAC-SHA256).

# Pseudocode on the server
state_json = serialize(state)
signature = hmac_sha256(MESOP_SECRET_KEY, state_json)

# Send both to the client
response_payload = { "state": state_json, "signature": signature }

3. Verify the Signature: When the server receives a request from the client, it must perform a verification step before processing the event handler.

# Pseudocode on the server
received_state = request.payload["state"]
received_signature = request.payload["signature"]

# Server re-calculates what the signature should be
expected_signature = hmac_sha256(MESOP_SECRET_KEY, received_state)

# Securely compare the two signatures
if not hmac.compare_digest(expected_signature, received_signature):
    # TAMPERING DETECTED!
    # Reject the request with a 400 Bad Request error.
    return

# If signatures match, the state is trusted.
# Proceed with running the event handler.

Benefits of this Approach

• Prevents Tampering: This completely closes the client-side state manipulation attack vector.
• Increases Trust: Developers can trust that the me.state object is consistent with what the server last sent, making it much safer for application logic.
• Improves Security by Default: It provides a critical security layer out-of-the-box, protecting developers who may not initially be aware of the stateless architecture's nuances.

Performance Considerations

The performance impact of this feature would be negligible and is a worthwhile trade-off for the immense security gain.

• Computational Overhead: HMAC-SHA256 is an extremely fast and efficient algorithm. The computational cost of generating a signature on each response and verifying it on each request is minimal and would not introduce any noticeable latency.
• Network Payload: The signature itself is small. A Base64-encoded SHA256 hash adds only 44 bytes to each request and response payload. This is an insignificant increase in data transfer size.

Given these points, the security benefits of ensuring state integrity far outweigh the minor performance costs.

This change would be a significant enhancement to the security and robustness of the Mesop framework.

[richard-to]

Thanks @5fff for filing this issue. I agree that this can definitely be footgun for Mesop developers who are not aware of how Mesop state works. And it is easy to use Mesop state in a way that is insecure.

And definitely the possibility of the request being tampered with is a concern. We do perform an origin check to make sure the request is from the same origin. We also considered CSRF (#310), but decided the origin check was enough.

For the is_admin scenario, that sounds more like an authz check which would definitely be safer checking an internal data source and not exposed as Mesop state. But to your point, Mesop users may not realize that.

I think adding this signature check does help a bit. But I'm also not a security expert, so I'm a bit hesitant on implementing it. I believe the typical approach would be to use CSRF token. Granted the Mesop case is a bit weirder in terms of how it works.

And either way, I do strongly recommend validating input before making any API calls or database calls.

@wwwillchen do you have any thoughts on this? What was your original thinking here in regard to the state?

[wwwillchen]

Chatted with @richard-to offline, just to recap some thoughts:

• Mesop state was intended to be use for non-sensitive state, what's usually held in client-side state for a rich single-page-app with a JS framework. For example, storing how many button clicks, or what page / tab a user has navigated to, etc. As you're pointing out, it should definitely not be used for sensitive state like access controls because it can be tampered.
• For sensitive state, I highly recommend keeping it on the server-side and then looking up whether the user is an admin without relying on Mesop state. If you do need to use Mesop state for some reason, I'd recommend encrypting it yourself and storing the signed/encrypted state on Mesop and then manually decrypting it in the server.
• Given that the Mesop core team has very limited bandwidth, I don't think we'll be able to implement this proposal. I agree the peformance overhead here is probably negligible, the bigger consideration here is around backwards compatibility: for example, when this is rolled out, there may be existing clients without signed states, and the server should handle this properly (e.g. telling the client to reload, perhaps); we'd also need to think about all the existing apps and whether they would be required to adopt a secret key (this would be a breaking change and prevent a lot of apps from using the latest Mesop version) or this should be optional (which can create confusion and possible security risk as outlined here). The amount of coding work probably isn't that much, but carefully migrating our ecosystem to a safer default is likely a very significant effort.