Bug #85035
closed
Security: Manipulate pid for FE login
0%
Description
A user can login with EXT:felogin by changing the hidden input field "pid", e.g. to
<input name="pid" value="1,2,3,4,5,6,7,8,9,10,...,999" type="hidden">
Let's assume you have a TYPO3 BE which contains several websites. If a user has a valid login for one of these websites, he can login to all other websites, too.
The pid shouldn't be shown and submitted in frontend, it should be configurable by TypoScript.
Updated by Markus Klein almost 6 years ago
- Project changed from TYPO3 Core to 1716
- Category deleted (
Authentication)
Updated by Oliver Hader almost 6 years ago
- Category set to OW-A02: Broken Authentication
Okay, without focussing on PID values that means (just an assumption, not verified yet):
- user (with valid login) is able to login int websiteA.com
- user can clone the cookie for websiteB.com (where user would not have access in terms of fe_users record)
- thus, a user is able to reuse it's session data in a different website scope
Updated by Helmut Hummel almost 6 years ago
Since user authentication is performed before page id is resolved,
there is no way to set a pid list for only a part of the page tree (chicken/egg problem).
In which page tree we end up, we only know after authentication.
Therefore different pid for fe user storage is only useful for organizational purposes. It is not possible to use this for authorization.
Authorization can solely be controlled with user groups.
This means in a multi site setup and a requirement that fe users from one site don't have access to other sites,
the fact that a user successfully logged in, must not be used to restrict access. Instead access restriction must be done with user groups.
What could be possible though (but isn't implemented) is to enforce pid for fe users per domain.
Updated by Helmut Hummel almost 6 years ago
- Project changed from 1716 to TYPO3 Core
- Category deleted (
OW-A02: Broken Authentication)
Updated by Helmut Hummel almost 6 years ago
- Status changed from New to Needs Feedback
Updated by Sven Burkert almost 6 years ago
I already expected this answer ("use user groups") ;)
But this doesn't solve the problem that a user still can login where he shouldn't (login is successful, but he can't access any restricted page unless he is in the right user group).
Updated by Anja Leichsenring almost 2 years ago
- Status changed from Needs Feedback to Rejected
after the issue is open for so long and without any interaction, I think the explanation and guidelines given by Helmut are sufficient.
Here the key takeaways:
- don't use pure 'logged in' status as authorization, always rely on user groups
- use different login storage folders only if strictly necessary for organisational purpose
Updated by Chris Müller almost 2 years ago
- Related to Task #97692: Streamline felogin documentation added
Updated by Sven Burkert over 1 year ago
Isn't this bug identical to the now fixed security issue https://typo3.org/security/advisory/typo3-core-sa-2022-013 ? @Oliver Hader
@Torben Hansen Thanks for fixing this.