The back-end user field is missing a whitelist to change to password hash, where should the permission be collected in that layer.
Where should the authority be collected? Collected in three places: the list of fields that can be changed, authorization by group, and verification before writing to the server. The hidden entry on the interface is just a visual closure, and when there is no restriction at the request level, the fields that can be submitted are still determined by the visitor.
What does the field whitelist block?
A fix was verified that explains the problem form: PbootCMS fixed the issue of missing field whitelist for quick user value modification in the update log on September 8, 2026, which can rewrite any administrator password hash.
The writing style of such interfaces is usually 'pass what to change what', directly corresponding the submitted key to the column of the data table. This saves the mapping work, but the visibility of the column is determined by the request. Once a column like password hash falls into the writable set, changing the value once is equivalent to replacing the login credentials, and it is not necessary to crack it to log in to the backend.
The practice of the whitelist is reversed: the interface only declares the fields that are allowed to be changed, and the rest of the keys and values are ignored and exceptions are recorded. When the columns to be changed are increased, the declaration is changed, not the restriction is loosened.
It is not enough to hide the entry only on the interface
To determine where the permission judgment is collected, there is a simple question: bypass the interface, directly send a request to the interface, will the result change? If it changes, it means that the restriction is only on the front end.
Similarly, there are three types of 'seemingly received' writing methods: do not give the entry only in the menu, hide buttons according to the role in the template, and remove a certain input item in the form. These three places do not prevent the request itself, and it is equivalent to no prevention when the server does not verify.
The effective position is: before writing, check whether the role can modify this record and this field according to the group, and leave logs for unauthorized attempts.
How should the grouping and permissions be divided?
Divide according to responsibility, not by head count. Content editing requires draft and publishing rights, but should not have user management and backup recovery; Operations need member and order-related operations, but should not be able to modify the template; Technical maintenance can touch deployment and backup, but does not need to batch rewrite the text.
AnQiCMS (AnQi CMS) supports setting access permissions for different user groups in user management and VIP groups, separating the configuration of content, member, and operation and maintenance responsibilities. The significance of grouping lies in limiting the cost of over-authorization to a group, rather than allowing any backend account to access the entire site.
High-risk actions are collected separately. Operations such as backup, upgrade, and multi-site should remain disabled by default and explicitly enabled as needed; those who need to use them can enable them.
The sensitive word filtering and content review at the content layer manage whether the published text is compliant, but will not prevent unauthorized writing; do not use it as a permission layer.
How to match password storage and session
The field has been received, but we still need to look at what is stored. Passwords should be saved as irreversible hashes instead of readable plaintext, the session after login should be maintained with signed credentials such as JWT, and when switching identities between sites, the same forgeable credentials should not be used - this is why similar issues should be evaluated together with injection: getting access to write the user table, and being able to forge sessions, combined together is from changing one line of data to accessing the backend.
The verification sequence after completion: Try to change sensitive fields with a low-privilege account, confirm that it is rejected and there are logs; then check if the session expires immediately with the change of permissions to avoid the continued use of old credentials.
Common questions
Will the field whitelist affect normal business?It will not affect, as long as the columns that truly need to be opened are written into the declaration; supplement the declaration when new columns are added.
Is it only the backend interface that needs this level of verification?No, any entry that 'writes to the database by pressing the submit key' is applicable, including import and batch changes.
How often should permissions be reviewed?Review permissions after each change in personnel responsibilities and the addition of new interfaces, which is more in line with actual risks than checking regularly by calendar.