Version 1.5.9 is a bug-fix release of version 1.5.8, which is a security release that was released this morning.
We recommend updating to v1.5.9 as soon as possible.
Version v1.5.8 is a security release containing multiple security fixes, logic fixes, and other optimizations. After the release of v1.5.7, we’ve conducted an internal review and found multiple issues.
hash_equals to verify them.http:// or https://.raw filter.If you’re using the Docker image, we recommend using the Alpine-based images in the future. Switching should be possible without any problems.
Thank you, uluzox, for providing the pull request!
Most of the important security fixes address improperly protected routes (privilege escalation). As announced in v1.5.7, we’ll switch to a ‘deny-by-default’ system, which will prevent this from happening in the future.
The issue allows the wrong users (in most cases, project members with the editor and reader roles) to access functions that only a project owner should.
The incorrectly protected route in the setup does not allow an attacker to change anything but can generate more load than necessary, making it an important fix. To prevent such issues in the future, we’ve also added another check, so now two different checks protect the setup.
The web cron job endpoint technically allowed empty keys and didn’t use the correct method to validate the keys.
We recommend updating to v1.5.8 as soon as possible.
Apart from the incorrectly protected setup route, all other fixes are only available if you have project members with the roles editor or viewer, or if you have enabled the web cron job.
If you cannot update as soon as possible, you can block access to the /setup/* routes to prevent the incorrectly protected setup route from causing any harm.
The other security-related fixes are not directly a threat to your mosparo installation.
This release is a security release to fix two security vulnerabilities and add a missing check in the verification API.
We thank 5afagy for reporting, helping to understand, and fixing these security vulnerabilities and issues.
We recommend updating to v1.5.7 as soon as you can.
API Debug mode: The idea of the API debug mode is to help developers understand what is going wrong. Since the information mosparo returned was not masked, the same information can also be used by an attacker to create a valid API authorization.
Privilege escalation: The newly added submission rules (v1.5) as well as some functions of the optimized rule editor (v1.4) were not correctly protected. A project member with the role `Reader` can access and manipulate submission and field rules.
Both risks are high and can be a real threat to a mosparo project. But there are very simple solutions for both risks (without updating to v1.5.7):
API debug mode: Disable the API debug mode in a project. The risk of this issue is eliminated. If the API debug mode was enabled in a productive environment, you should reissue the API keys.
Privilege escalation: Remove all project members with the role ‘Reader’. The risk of this issue is eliminated.
If the API debug mode is enabled, an attacker could send valid API requests for the verification, statistics, and rule package API endpoints.
In both cases, an attacker can change rules (privilege escalation) or rule packages (API debug mode). The other functionalities (verification and statistics API endpoints for API debug mode) do not change how mosparo works.
It is not possible to request any form or user data. Since there is no API endpoint for this, an attacker cannot request any form or user data. It is possible to request the metadata for a submission via the verification API endpoint, but the metadata is submitted manually from the frontend anyway (not internal metadata).
The API debug mode should not be enabled in a productive environment.
API debug mode: The API debug mode now masks sensitive values. This is still helpful for a developer, but does not allow a valid API request.
Privilege escalation: The privileges were adjusted so that a project member with the reader role can no longer change the rules.
For both cases, we’ve identified better solutions for the future. With our next bigger release, v1.6, we’ll resolve both situations with better options:
API debug mode: The API debug mode will be removed from mosparo. Instead, we’ll add an API response history that tracks API responses in a separate list in the administration area. Tracking can be enabled if required.
Privilege escalation: The system right now uses an ‘allowed by default’ system, which means that a reader always has access to every new route. With v1.6, we change that system to a ‘denied by default’ system, which means that a reader does not have access by default.
This release is a maintenance release to update the dependencies and the translations.
Version 1.5.5 is a security release to fix an issue with API authentication.
Thank you, senti-man, for finding and reporting this issue to us in private via the security advisories.
We recommend updating to v1.5.5 as soon as you can.
The API endpoints use hashes to validate requests and grant access to the backend. We’ve wrongfully used a simple string comparison, which means that you could guess the private API key by measuring the time.
The risk of this security issue is manageable. To exploit this issue, an attacker needs to make many requests (thousands) and needs favorable network conditions to guess the correct private key.
Even if the attacker found the private key, the only bad things the attacker could do are adding metadata to a submission and manipulating rule packages, if there are any, in a mosparo project.
It is not possible to request any form or user data. If an attacker successfully obtained the private key, they could only obtain metadata for a submission, project statistics, and the contents of a rule package.
As suggested by senti-man, we’ve switched the hash comparison to the hash_equals method, which PHP provides specifically for this kind of attack.