Release v1.5.11

This version is a bug-fix release that addresses numerous issues across multiple areas of mosparo.

Commands

• Fixed the broken export command, which didn’t get the new flags in v1.5. Reported by thelfensdrfer in #455.
• Fixed the broken import command, which didn’t get the new flags in v1.5. In connection with #455.
• Fixed an incorrect comparison that caused a duplicate import.
• Fixed the error handling in the mosparo:rule-package:import command.
• Fixed the error handling in the mosparo:self-update command.

Rules

• Fixed the random values submission rule type, which caused problems with array values and didn’t match the textarea fields correctly.
• Added the missing validation in the field rules editor when storing the data.
• Fixed the matching in the Unicode block rule type, which was case-sensitive.
• Fixed the matching in the IP address rule type. Subnets were not correctly matched, and differently written IP addresses didn’t match.

Interface

• Fixed a reflected HTML injection in the project search.
• Fixed a stored HTML injection in the rule package delete confirmation.

Frontend widget

• Fixed the handling of fields with names shorter than 3 characters.

API

• Frontend API, request-submit-token: Invalid locales are now ignored correctly and fall back to English.
• Verification API, store-metadata: Fixed incorrect data validation.
• Fixed an incorrectly set HTTP status code for a backend API request without an Authorization header.

Other

• Web cron job: The web cron job no longer stops working when a rule package generates an error.
• Rule package, JSON importer: The importer now correctly counts rule items, as with the ZIP importer.
• Fixed inverted logic in the clearCssCache method, which was doing the wrong thing regarding the shared cache.
• Added the correct escaping to handle translations in JavaScript parts of mosparo.
• Proof-of-work: Switched to random_int to get a more secure random number.
• Two-factor authentication: Use strict comparison for the backup codes.
• Updated the backend and validator translations.

Packaging

• Removed two files from the built ZIP package, reducing the package size by 17.86 MB. Reported by uluzox in #453

After updating to v1.5.11, mosparo needs to recalculate the prepared values and hashes. Please open the web interface after updating and wait until the process is finished.

We’re thankful to all contributors for reporting bugs, suggesting changes, translating strings, and, in general, for making mosparo better.

Release v1.5.10

Version 1.5.10 is a bugfix release. We’ve fixed numerous bugs and adjusted the layers for the unprivileged Docker images.

• Removed duplicate layers from the unprivileged Docker images. Fixed by uluzox in PR #451
• Fixed the nginx error handling in the unprivileged Alpine Docker image. Fixed by uluzox in PR #451
• Fixed a bug in the field rule editor that set the wrong ID on newly created items.
• Fixed the incorrect case and Unicode handling in the word field rule type.
• Fixed the incorrect rule item queries for the domain, email, and website field rule types.
• Fixed the field rule cache, which did not distinguish between field types.
• Fixed the lockout start and lockout times, which were incorrectly calculated.
• Fixed an off-by-one error in the Proof-of-Work logic.
• Fixed the spam submission count when silent mode is enabled.
• Fixed a database query that counted too many requests for the delay and lockout functions.
• Fixed the incorrect handling of the return value when opening a ZIP archive.
• Fixed three small issues in the frontend JavaScript.
• Fixed the exception when nothing was selected in the rule tester.
• Fixed the regeneration of the frontend CSS file if the hash was wrong.
• Fixed a bug in the web cron job that triggered the GeoIP2 download on every cron run.
• Adjusted exception handling in the cleanup command and the web cron job, which now correctly resets the status.
• Hardened the security settings with additional constraints.
• Hardened the processing of the form data fields.
• Hardened project members and users. It’s no longer possible to add a project member more than once to the same project. In addition, it is no longer possible to delete your own user account.

The update will automatically delete project members who were added to a project more than once.

After updating to v1.5.10, mosparo needs to recalculate the prepared values and hashes. Please open the web interface after updating and wait until the process is finished.

If you want to monitor the mosparo versions, for example, to get notified when we release a new version, you can use the following URLs:

• https://updates.mosparo.io/v/versions.json (for a JSON containing the latest versions for the three channels)
• https://updates.mosparo.io/v/stable.txt (for just getting the version number, also usable with develop.txt and beta.txt)

Thank you very much, uluzox, for providing the pull request to adjust the Docker images.

Release v1.5.9

Version 1.5.9 is a bug-fix release of version 1.5.8, which is a security release that was released this morning.

• Fixed the uninitialized property in the form submission validation. Reported by winkelement in #450.

We recommend updating to v1.5.9 as soon as possible.

Release v1.5.8

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.

Security fixes

• Added more missing routes to the permission system, mainly for managing the advanced project settings, the translations (list, add, modify, delete), and the switch design mode functionality.
• Project creation assistant: Fixed access to the project creation assistant.
• Project members: Fixed access to modify and delete the project members.
• Project groups: Fixed access to create, modify, and delete project groups.
• Setup: Fixed an unprotected setup route.
• Web cron job: The web cron job now rejects empty keys and uses hash_equals to verify them.
• Submissions: Added a fix to render a link to the form page only if the URL starts with http:// or https://.
• Import: Changed the token for the import to `random_bytes` to ensure random values.
• Import: Adjusted the logic to ensure that it’s not possible to import something into another project.
• Design mode: Added a CSRF token to the switch design mode functionality.

Other fixes

• Silent mode: Fixed a logic issue that invalidated the results of the honeypot and Proof-of-Work security features.
• API: Changed the parameter retrieval method to ensure the correct data type is returned.
• API: The rule package API pagination was not correctly validated and limited (min, max).
• Rule tester: Removed an unnecessary raw filter.
• Multiple code style fixes.

Docker

• Added the Dockerfiles to generate mosparo images based on the Alpine base package. Alpine has a much smaller footprint, resulting in a smaller download size and fewer potential security issues. uluzox provided the changes for these new images in #448, #449.
• Converted the scripts to shell scripts and removed unnecessary stuff. Provided by uluzox in #448, #449.

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!

Details of the security issues

Description of the security issue

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.

Risk assessment

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.

Release v1.5.7

This release is a security release to fix two security vulnerabilities and add a missing check in the verification API.

• Fixed an authentication bypass via an HMAC signing oracle if the API debug mode is enabled. Found and reported by 5afagy via our security. Affected versions: > v1.1.0-beta.1 < v1.5.7
• Fixed the incomplete list of privileges, which led to a privilege escalation for reader project members. Found and reported by 5afagy. Affected versions: > v1.4.0-beta.1 < v1.5.7
• Added verification of the form signature in the verification process. This is not a security vulnerability, but an incomplete check. Found and reported by 5afagy.
• Added an alert below the API debug mode warning not to use it in a production environment.
• Added an exclamation icon in the project list for each project that has the API debug mode enabled.

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.

Details of the security issues

Description of the security issue

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.

Risk assessment

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.

Changes to mitigate the security issues

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.

Future changes

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.