Insufficient synchronization during commitment phase

Problem/Motivation

Part of 🌱 [Meta] Address low risk issues found in security Audit Active

Cure53 identified that some web requests may still be handled by the web application while it concurrently updates itself in maintenance mode. This induces the risk of attackers timing high-frequency traffic during update periods in order to execute code within the web application, while the files of the new version have only partially been synchronized to the web root directory. In very rare edge cases when the race condition is met, this could lead to security issues that stem from incompatible or corrupt logic between individual files.
As an example, this was confirmed by frequently updating the .htaccess file in the web directory, which suddenly and momentarily rendered a protected directory accessible.

Steps to reproduce

Proposed resolution

To mitigate this issue, Cure53 advises that the web application performs the same actions as implemented by a graceful restart on modern web servers. The software must ensure that web requests cannot execute code from the updated directory during the entire file synchronization process. Alternatively, the window of opportunity for these errors can be decreased by minimizing the commitment phase to a handful of rename operations. However, this requires architectural changes to the application and will never comprehensively nullify the outstanding risk.

Remaining tasks

User interface changes

API changes

Data model changes