You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EntityId: Assert valid serialization in unserialize()
In change I4850feb0b5, we removed some tests that called unserialize()
with a serialization that wasn’t actually valid (non-ID strings, ints,
etc.), which noted that “All these cases are kind of an injection vector
and allow constructing invalid ids.” It’s unclear why these cases were
allowed and tested to begin with; my best guess is that unserialize()
skipped validation for performance reasons, but as far as I can tell,
it’s rarely if ever called from production code, so I think it’s better
to add the validation and reject invalid serializations.
We delegate most of the validation to the constructor (which then calls
assertValidIdFormat(); however, we afterwards validate that the
resulting serialization is the same string as in the data, i.e. that the
strtoupper() in the constructor didn’t have an effect.
FederatedPropertyId is not touched because it already calls
assertValidSerialization() in its __unserialize() method.
Change-Id: Id8239ce28ac448ab65a1b911cd25315960fa881e
0 commit comments