- Release Date: January 22, 2019
- Component Type: 3rd party extensions (not being part of TYPO3 default installation)
- Impact: Enumeration of usernames and email addresses, Information Disclosure
- Type: Advisory
TYPO3 extensions, which allow to create frontend user accounts or newsletter subscriptions, typically use server side validators to ensure that a given username or email address is unique.
Validation results - like "A user with the given username already exist" or "This email address is already subscribed to the newsletter" - allow remote users to create a list of usernames and email addresses of frontend users or newsletter subscribers of the TYPO3 website.
This information can be used to attack the TYPO3 frontend login, for example, through a brute-force or a username/password attack. In some cases (e.g. sites with information for special target groups) this behavior can also be seen as an information disclosure.
To classify possible enumeration of email and usernames as security and privacy risk depends on individual scenarios and the overall requirements of a web application. Basically the scope is to respond with generic messages without revealing details to third parties.
To avoid username and email address enumeration in general, the following process is suggested.
Frontend user registration
- Do not use validators, which check for uniqueness of username and email address field values
- Check for username and email address uniqueness on server side before saving the new frontend user
- If an account with the username or email address exist, send an email with password recovery instructions to user (frontend user must contain a valid email address)
- If no account with username or email address exist, create new account with provided user data and proceed with following registration steps (e.g. send opt-in email)
- Display a generic message without providing information about existing accounts (e.g. "An email with further registration instructions has been sent.")
Some TYPO3 extensions for frontend user management (e.g. femanager, sf_register or sr_feuser_register) contain signal slots or hooks, which may be used to implement the suggested process.
- Do not use validators to check the uniqueness of an email address
- Check email address uniqueness on server side before saving the newsletter subscription
- If email address is already subscribed to the newsletter, ignore registration and do not save data
- If email address is not subscribed to the newsletter, save registration and proceed with following subscription steps (e.g. send opt-in email)
- Display a general message (e.g. "An email with further registration instructions has been sent.")
Thanks to Loek Hilgersom who reported this issue