Most denormalisers do not validate input

[driskell]

Version(s) affected

5.2.2

Description

Most of the denormalisers do not correctly validate the incoming data.

As such, it's very easy to trigger a TypeError crash or similar by passing in invalid data.
The only way to avoid it is to perform manual validation, which leaks elements of the denormalisation process into the caller.

For example attempting to denormalise a PublicKeyCredential from an empty array or one without a rawId will crash with a TypeError

Although this won't occur during normal operation, it can be abused to cause a Denial of Service or excessive logging and alerts

How to reproduce

deserialize('[]', PublicKeyCredentialSource::class, 'json')

Possible Solution

Check keys exist and coerce to necessary types inside denormalisers

Additional Context

No response

[Spomky]

Hi,

What you are observing is actually the expected behaviour.

The denormalisers assume that the incoming payload has the required structure, and they intentionally throw an exception when mandatory fields are missing or of an unexpected type.
Invalid input is meant to fail fast at this stage.

[zll600]

Although this won't occur during normal operation, it can be abused to cause a Denial of Service or excessive logging and alerts

To resolve this problem, I wrap the normalization/denormalization and the serialization/deserialization in a try-catch block to catch possible exceptions, and decide how to handle these errors in my application so that I can get more flexibility 😺

[driskell]

Although this won't occur during normal operation, it can be abused to cause a Denial of Service or excessive logging and alerts

To resolve this problem, I wrap the normalization/denormalization and the serialization/deserialization in a try-catch block to catch possible exceptions, and decide how to handle these errors in my application so that I can get more flexibility 😺

Ah ok. Problem is my linter will heavily complain about catching Exception as it usually a sign of bad architecture. Ideally if the code here is expecting TypeError to be thrown it should be documented as something to handle. Seems at the moment though all kinds of exception can throw and not only that but errors like undefined property. Which are difficult to handle. Ideally the denomralisers would be error free. I use serializer a lot and this is the only time I’ve had it not throw a ExceptionInterface from serializer

[zll600]

Seems at the moment though all kinds of exception can throw and not only that but errors like undefined property. Which are difficult to handle. Ideally the denomralisers would be error free. I use serializer a lot and this is the only time I’ve had it not throw a ExceptionInterface from serializer

I catch the exception as follows

try {
    $attestation = $serializer->deserialize($attestationString, PublicKeyCredential::class, 'json', [
        DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
    ]);
} catch (PartialDenormalizationException $e) {
   // do something I want
   // e.g. rethrow as an InvalidArgumentException exception
}

Ref: https://symfony.com/doc/current/serializer.html#collecting-type-errors-while-denormalizing

I hope this can help you. And please correct me if I am wrong 🙇‍♂️