We use serialized columns in many places in core where JSON encoded arrays could be used. This can lead to security vulnerabilities in some contexts and we should move away from it if possible.
Where it is not possible, we should use the "allowed_classes" option for unserialize to reduce risk: https://www.php.net/manual/en/function.unserialize.php
Audit core to find instances of serialized columns, and determine where moving to JSON is possible.
In this issue or a follow up:
1. Deprecate SerializedColumnNormalizerTrait and friends in favor of killing unserializes
2. Write a PSA to tell people to fix their custom normalizers that use unserialize, and call out unserialize generally as probably a bad practice
See above.
None.
TBD.
TBD.
TBD.
Active
11.0 🔥
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Coming here from
📌
Allow field types to control how properties are mapped to and from storage
Needs review
as part of introducing JSON data storage. Also am abstracting out all the various calls to unserialize() in SqlContentEntityStorage, which makes it pretty easy to support an additional key/keys in the property definition alongside serialize to specify allowed_classes.
