Read-Only Security Protection via Client-Side Key Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In REST-based architectures, it is challenging to distinguish between authorized system changes to read-only fields and unauthorized requests, particularly in stateless backend/frontend interactions, leading to vulnerabilities such as hacking, interception, and replay attacks, without relying on backend storage.
Innovation Solution
Implementing a read-only security protection engine that generates and verifies security keys based on client-side state information, using a source string including identifiers, values, and session data, to ensure authorized changes while preventing unauthorized modifications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If stateless backend/frontend interactions are used in REST architecture, then system scalability and simplicity are improved, but security against unauthorized modifications to read-only fields deteriorates
Solution Approach 1:
The system performs preliminary actions by generating security keys based on read-only field values before transmitting data to the client. These security keys are embedded in the response along with the read-only values, establishing a trusted reference that the client can use to verify subsequent save requests without requiring backend storage or session state.
Solution Approach 2:
Security keys act as an intermediary mechanism between the backend and client device. The backend generates these keys based on read-only field values, and the client uses them to verify save requests. This intermediary enables security verification in a stateless architecture without requiring the backend to store or remember previous interactions.
2Reliability
If security keys are generated and verified on the client side based on read-only field values, then security against hacking and replay attacks is improved, but system complexity increases
Solution Approach 1:
The client device performs self-service security verification by generating security keys locally based on read-only field values received from the backend. The client compares its generated key with the key provided in the save request response, enabling security verification without additional backend complexity or external security services.
Solution Approach 2:
The system changes the parameter of security verification from server-side state management to client-side cryptographic verification. By transforming the read-only field values into security keys using a deterministic algorithm, the system enables complex security checks to be performed through simple parameter transformation and comparison on the client side.
3Productivity
If backend storage is avoided for session management, then system scalability and performance are improved, but ability to track and verify authorized changes deteriorates
Solution Approach 1:
The system extracts the essential session verification information (read-only field values and their corresponding security keys) from the backend response and transmits it to the client. This extraction eliminates the need for backend storage of session information while providing the client with sufficient data to verify authorized changes independently.
Solution Approach 2:
The backend creates a copy of the read-only field values and embeds them in the response along with generated security keys. This copying mechanism provides the client with a local reference that replicates the backend's authoritative data, enabling verification without requiring the backend to retain or recall original session state.
Data Source
AI summary
The present disclosure involves systems, software, and computer implemented methods for read-only security protection. One example method includes receiving, from a client device, an on-change request to change an editable leading field from a first editable leading field value to a second editable leading field value. The editable leading field is referenced in an on-change rule. The on-change request includes a first security key and the client device is not allowed to modify the read-only target field. The on-change rule is executed to change the read-only target field from a first read-only target field value to a second read-only target field value based on the second editable leading field value. A second security key is generated based on at least the second read-only target field value and provided to the client device in response to the on-change request.