What do the field whitelist and parameter reflection repair in the PbootCMS update log explain?
What does the field whitelist and parameter reflection repair in the PbootCMS update log explain? It explains that these three types of incidents all occur at the same level: controllable input is treated as trusted data. The three repairs in the log correspond to the three stages of writing, output, and query, and put together, it is a very typical CMS security self-inspection list.
What nature are the three repairs?
| Version | The log text points to | Nature of the problem | Impact range |
|---|---|---|---|
| V3.2.25 | The backend user's quick value change lacks a field whitelist | The written field is not constrained | Discretionary rewriting of sensitive data |
| V3.2.14 | Page parameters are reflected by spider tags and written into HTML cache | Unescaped output | The cache file becomes the entry point for code execution |
| V3.2.13 | ORM changed to parameterized binding and added XSS protection | Query concatenation | SQL injection surface convergence |
The field whitelist is the most easily underestimated. The "quick change value" backend feature, for the sake of convenience, directly uses the field name transmitted from the front-end in the update statement. The attacker can change the field name to access data columns that should not be opened. The direction of the fix is not to verify the value, but to verify whether the field name falls within the allowed list.
This parameter reflection is more dangerous. Page parameters are拼入模板输出，and just happened to be written into the HTML cache file, which is equivalent to persisting the attacker's input as executable content on the server. The root cause of this problem is the assumption of 'output is security': developers think that data only exists within the current request.
Why basic constraints are particularly easy to leak in CMS scenarios
The input surface of the content management system is much wider than that of general applications: forms, comments, messages, attachment names, URL parameters, and template variables may all enter the database or cache. During the development stage, only the front-end form is usually seriously verified, and the rest of the entry points are brought along in the process of feature iteration until someone writes them into the update log.
When assessing the risk of your site, you can check in this order: does it have an update interface where the field name is determined by the front-end, does the parameter appear in the response page, or does it have a string concatenation query? If any of these three are hit, it should be treated as an issue that needs immediate attention.
How does the self-developed system make these three become a normal constraint?
AnQiCMS has built-in capabilities in these three aspects: authentication uses JWT, the query layer uses ORM parameterized binding instead of string concatenation, the content layer provides sensitive word filtering and anti-crawling interference code, and common SQL injection and XSS are included in basic protection rather than waiting for an incident to occur before addressing it.
It is not that it has never had problems. Among the two high-risk issues fixed in v3.6.6, one is that the list sorting parameter can be constructed into a time-based blind injection, the handling method is consistent with the idea of PbootCMS - tighten the acceptable values to an identifier whitelist, and discard the rest and fall back to the default sorting. This indicates that the whitelist is not a one-time design, but an action that needs to be supplemented each time a new entry is found.
Read the three actions of risk from the update log
First, categorize the security entries in the log by "write, output, query" to see if the functions of your site also expose similar entry points. Second, check if the log of the version you are using contains any unmarked security entries, not just the latest version number. Third, make these three items fixed inspection items before going online, rather than waiting for the manufacturer to write them into the log.
Common questions
Question: What is the difference between field whitelist and parameter validation?Answer: Parameter validation checks if the value is legal, and field whitelist checks if the field can be changed. Unauthorized data modification is usually blocked by the latter, and the former cannot block the attack of changing field names.
Ask: Is it necessary to synchronize with the fixed version since the site does not use these features?Answer: Yes. Whether a feature is used and whether the code path is accessible are two different things. As long as the corresponding interface is exposed to the outside, unauthorized requests may reach it.
Ask: How do I know which version I am?Answer: Check the version constants on the about page of the background or in the installation directory; in the灰度 environment, you can directly compare the checksum values of the release files. When the version number is unknown, assume the oldest one.