All rules
CA5362Security Enabled by default: No

Potential reference cycle in deserialized object graph

Potential reference cycle in deserialized object graph

Microsoft docs

Description

If deserializing untrusted data, then any code processing the deserialized object graph needs to handle reference cycles without going into infinite loops. This includes both code that's part of a deserialization callback and code that processes the object graph after deserialization completed. Otherwise, an attacker could perform a Denial-of-Service attack with malicious data containing a reference cycle.

This rule doesn't necessarily mean there's a vulnerability, but just flags potential reference cycles in deserialized object graphs.

Cause

A class marked with the System.SerializableAttribute has a field or property may refer to the containing object directly or indirectly, allowing for a potential reference cycle.

How to fix violations

Don't serialize the class and remove the System.SerializableAttribute. Or, redesign your application so that the self-referred members can be removed out of the serializable class.

Example

using System;

[Serializable()]
class ExampleClass
{
    public ExampleClass ExampleProperty {get; set;}

    public int NormalProperty {get; set;}
}

class AnotherClass
{
    // The argument passed by could be `JsonConvert.DeserializeObject<ExampleClass>(untrustedData)`.
    public void AnotherMethod(ExampleClass ec)
    {
        while(ec != null)
        {
            Console.WriteLine(ec.ToString());
            ec = ec.ExampleProperty;
        }
    }
}

using System;

[Serializable()]
class ExampleClass
{
    [NonSerialized]
    public ExampleClass ExampleProperty {get; set;}

    public int NormalProperty {get; set;}
}

class AnotherClass
{
    // The argument passed by could be `JsonConvert.DeserializeObject<ExampleClass>(untrustedData)`.
    public void AnotherMethod(ExampleClass ec)
    {
        while(ec != null)
        {
            Console.WriteLine(ec.ToString());
            ec = ec.ExampleProperty;
        }
    }
}

When to suppress

It's safe to suppress a warning from this rule if:

  • You know the input is trusted. Consider that your application's trust boundary and data flows may change over time.
  • All code processing the deserialized data detects and handles reference cycles without going into an infinite loop or using excessive resources.
Group results
0 yes 0 no
ConsensusNone (disabled)
Severity preference (yes voters)
Suggestion0
Warning0
Error0