[#35574] - [4.0] Avoid exception on wrong validation code and just redirect to login
- Fixed in Code Base
- 23 Jan 2022
- Medium
- Build: 4.0-dev
- # 35574
- Diff
- bembelimen:4.0/verification-fail
User tests: Successful: Unsuccessful:
Summary of Changes
I got some reports from user, that they land on the error page when they try to validate their account. When I check their account they are already verified and activated. The issue is, that some email application pre-fetch urls (and show e.g. previews) which triggers the validation and if then the user clicks, Joomla! throws an exception.
Testing Instructions
- Set registration to user activation
- Register a new user
- click on the verification link
- click again on the verification link
Actual result BEFORE applying this Pull Request
Expected result AFTER applying this Pull Request
User is redirected to the login (with the same message as normal message)
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End com_users |
| Labels |
Added:
?
|
||
Also your screenshot shows this is an issue in Joomla 3 - yet this PR only addresses it in Joomla 4, it would need to be applied to Joomla 3 and then merged up to Joomla 4.
I see your point, but think the the "common user" expects to just click in the email link and that's it.
The Screenshot is from J! 4.
The "common user" expects Joomla to implement things securely, according to established security best practice and norms.
Regardless of the screenshot, if this is an issue in Joomla 3 also then it should be first addressed there.
I have tested this item
Marking this as successful as, as it handles the exception with a redirect as designed.
However, what seems to be out of scope of this PR, and is a security issue @joomla/security is the changing of a security credential (account validation) by GET request, which should be addressed, as nothing should change when making GET requests, which are designed for page retrieval and not updating a user object.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35574.
For the record this was reported to the Joomla security strike team, via their email address, however I did not receive any reply to my report to date
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35574.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35574.
| Labels |
Added:
?
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-01-23 16:06:56 |
| Closed_By | ⇒ | bembelimen | |
| Labels |
Added:
?
Removed: ? |
||
Funny, I'll find the link in a moment, but when I reported this, I was told it was not an issue...
This is the wrong fix though. (Edit: This fix fixes the token not found in a better way, I agree with that, but it doesnt solve the root problem which is the GET request is validating the user)
A non-form-token'ed, GET request should not be allowed to validate a users account. An unauthenticated GET request performing anything other than data retrieval is fundamentally wrong. A GET request should not be updating a user entity's security credentials.
We would never allow this anywhere else. We would never allow a GET request to perform an action like this.
Moving the verification to a POST, with the user having to click the link to prefil a form, and then click a form submit button, as a POST is the correct fix for this root issue.
This PR fixes the symptoms and not the cause.