diff --git a/analyzers/rspec/cs/S1854.json b/analyzers/rspec/cs/S1854.json index b75444467df..bc4c78e5f48 100644 --- a/analyzers/rspec/cs/S1854.json +++ b/analyzers/rspec/cs/S1854.json @@ -25,5 +25,5 @@ 563 ] }, - "quickfix": "unknown" + "quickfix": "targeted" } diff --git a/analyzers/rspec/cs/S3241.html b/analyzers/rspec/cs/S3241.html index aa4877e920b..a1ac57dd482 100644 --- a/analyzers/rspec/cs/S3241.html +++ b/analyzers/rspec/cs/S3241.html @@ -1,4 +1,16 @@

Why is this an issue?

-

Private methods are clearly intended for use only within their own scope. When such methods return values that are never used by any of their -callers, then clearly there is no need to actually make the return, and it should be removed in the interests of efficiency and clarity.

+

Private methods are intended for use only within their scope. If these methods return values that are not utilized by any calling functions, it +indicates that the return operation is unnecessary. Removing such returns can enhance both efficiency and code clarity.

+

Noncompliant code example

+
+class SomeClass
+{
+     private int PrivateMethod() => 42;
+
+     public void PublicMethod()
+     {
+          PrivateMethod(); // Noncompliant: the result of PrivateMethod is not used
+     }
+}
+
diff --git a/analyzers/rspec/cs/S3776.html b/analyzers/rspec/cs/S3776.html index acfc6d51f03..c1e8b5f9254 100644 --- a/analyzers/rspec/cs/S3776.html +++ b/analyzers/rspec/cs/S3776.html @@ -45,4 +45,9 @@

Documentation

+

Articles & blog posts

+ diff --git a/analyzers/rspec/cs/S5773.html b/analyzers/rspec/cs/S5773.html index 09c0d2580ee..04f3cd4e1f5 100644 --- a/analyzers/rspec/cs/S5773.html +++ b/analyzers/rspec/cs/S5773.html @@ -1,63 +1,63 @@ +

Deserialization is the process of converting serialized data (such as objects or data structures) back into their original form. Types allowed to +be unserialized should be strictly controlled.

Why is this an issue?

-

During the deserialization process, the state of an object will be reconstructed from the serialized data stream which can contain dangerous -operations.

+

During the deserialization process, the state of an object will be reconstructed from the serialized data stream. By allowing unrestricted +deserialization of types, the application makes it possible for attackers to use types with dangerous or otherwise sensitive behavior during the +deserialization process.

+

What is the potential impact?

+

When an application deserializes untrusted data without proper restrictions, an attacker can craft malicious serialized objects. Depending on the +affected objects and properties, the consequences can vary.

+

Remote Code Execution

+

If attackers can craft malicious serialized objects that contain executable code, this code will run within the application’s context, potentially +gaining full control over the system. This can lead to unauthorized access, data breaches, or even complete system compromise.

For example, a well-known attack vector consists in serializing an object of type TempFileCollection with arbitrary files (defined by an attacker) which will be deleted on the application deserializing this object (when the finalize() method of -the TempFileCollection object is called). This kind of types are called "gadgets".

-

Instead of using BinaryFormatter and similar serializers, it is recommended to use safer alternatives in most of the cases, such as XmlSerializer or DataContractSerializer. If -it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:

- -

Noncompliant code example

-

For BinaryFormatter, -NetDataContractSerializer, +href="https://docs.microsoft.com/en-us/dotnet/api/system.codedom.compiler.tempfilecollection.finalize?view=netframework-4.8">finalize() method of +the TempFileCollection object is called). These kinds of specially crafted serialized objects are called "gadgets".

+

Privilege escalation

+

Unrestricted deserialization can also enable attackers to escalate their privileges within the application. By manipulating the serialized data, an +attacker can modify object properties or bypass security checks, granting them elevated privileges that they should not have. This can result in +unauthorized access to sensitive data, unauthorized actions, or even administrative control over the application.

+

Denial of Service

+

In some cases, an attacker can abuse the deserialization process to cause a denial of service (DoS) condition. By providing specially crafted +serialized data, the attacker can trigger excessive resource consumption, leading to system instability or unresponsiveness. This can disrupt the +availability of the application, impacting its functionality and causing inconvenience to users.

+

How to fix it

+

Code examples

+

Noncompliant code example

+

With BinaryFormatter, SoapFormatter -serializers:

-
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+or SoapFormatter:

+
 var myBinaryFormatter = new BinaryFormatter();
-myBinaryFormatter.Deserialize(stream); // Noncompliant: a binder is not used to limit types during deserialization
+myBinaryFormatter.Deserialize(stream); // Noncompliant
 
-

JavaScriptSerializer -should not use SimpleTypeResolver or other weak resolvers:

-
-JavaScriptSerializer serializer1 = new JavaScriptSerializer(new SimpleTypeResolver()); // Noncompliant: SimpleTypeResolver is unsecure (every types is resolved)
+

With JavaScriptSerializer:

+
+JavaScriptSerializer serializer1 = new JavaScriptSerializer(new SimpleTypeResolver()); // Noncompliant
 serializer1.Deserialize<ExpectedType>(json);
 
-

LosFormatter should not be used without -MAC verification:

-
-LosFormatter formatter = new LosFormatter(); // Noncompliant
-formatter.Deserialize(fs);
-
-

Compliant solution

-

BinaryFormatter, +

Compliant solution

+

With BinaryFormatter, NetDataContractSerializer -, SoapFormatter -serializers should use a binder implementing a whitelist approach to limit types during deserialization (at least one exception should be thrown or a -null value returned):

-
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+or SoapFormatter:

+
 sealed class CustomBinder : SerializationBinder
 {
    public override Type BindToType(string assemblyName, string typeName)
    {
        if (!(typeName == "type1" || typeName == "type2" || typeName == "type3"))
        {
-          throw new SerializationException("Only type1, type2 and type3 are allowed"); // Compliant
+          throw new SerializationException("Only type1, type2 and type3 are allowed");
        }
        return Assembly.Load(assemblyName).GetType(typeName);
    }
@@ -67,43 +67,67 @@ 

Compliant solution

myBinaryFormatter.Binder = new CustomBinder(); myBinaryFormatter.Deserialize(stream);
-

JavaScriptSerializer -should use a resolver implementing a whitelist to limit types during deserialization (at least one exception should be thrown or a null value -returned):

-
+

With JavaScriptSerializer:

+
 public class CustomSafeTypeResolver : JavaScriptTypeResolver
 {
    public override Type ResolveType(string id)
    {
       if(id != "ExpectedType") {
-         throw new ArgumentNullException("Only ExpectedType is allowed during deserialization"); // Compliant
+         throw new ArgumentNullException("Only ExpectedType is allowed during deserialization");
       }
       return Type.GetType(id);
    }
 }
 
-JavaScriptSerializer serializer = new JavaScriptSerializer(new CustomSafeTypeResolver()); // Compliant
+JavaScriptSerializer serializer = new JavaScriptSerializer(new CustomSafeTypeResolver());
 serializer.Deserialize<ExpectedType>(json);
 
-

LosFormatter serializer with MAC -verification:

-
-LosFormatter formatter = new LosFormatter(true, secret); // Compliant
-formatter.Deserialize(fs);
-
+

Going the extra mile

+

Instead of using BinaryFormatter +and similar serializers, it is recommended to use safer alternatives in most of the cases, such as XmlSerializer or DataContractSerializer.

+

If it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:

+
    +
  • by implementing an "allow-list" of types, but keep in mind that novel dangerous types are regularly discovered and this protection could be + insufficient over time.
  • +
  • or/and implementing a tamper protection, such as message authentication codes (MAC). This way + only objects serialized with the correct MAC hash will be deserialized.
  • +

Resources

+

Documentation

+

Articles & blog posts

+ +

Standards

+ diff --git a/analyzers/rspec/vbnet/S3776.html b/analyzers/rspec/vbnet/S3776.html index 5f4131fc12c..526571e1d53 100644 --- a/analyzers/rspec/vbnet/S3776.html +++ b/analyzers/rspec/vbnet/S3776.html @@ -32,4 +32,9 @@

Documentation

+

Articles & blog posts

+ diff --git a/analyzers/rspec/vbnet/S5773.html b/analyzers/rspec/vbnet/S5773.html index af0ad26283d..13a17971e8f 100644 --- a/analyzers/rspec/vbnet/S5773.html +++ b/analyzers/rspec/vbnet/S5773.html @@ -1,61 +1,61 @@ +

Deserialization is the process of converting serialized data (such as objects or data structures) back into their original form. Types allowed to +be unserialized should be strictly controlled.

Why is this an issue?

-

During the deserialization process, the state of an object will be reconstructed from the serialized data stream which can contain dangerous -operations.

+

During the deserialization process, the state of an object will be reconstructed from the serialized data stream. By allowing unrestricted +deserialization of types, the application makes it possible for attackers to use types with dangerous or otherwise sensitive behavior during the +deserialization process.

+

What is the potential impact?

+

When an application deserializes untrusted data without proper restrictions, an attacker can craft malicious serialized objects. Depending on the +affected objects and properties, the consequences can vary.

+

Remote Code Execution

+

If attackers can craft malicious serialized objects that contain executable code, this code will run within the application’s context, potentially +gaining full control over the system. This can lead to unauthorized access, data breaches, or even complete system compromise.

For example, a well-known attack vector consists in serializing an object of type TempFileCollection with arbitrary files (defined by an attacker) which will be deleted on the application deserializing this object (when the finalize() method of -the TempFileCollection object is called). This kind of types are called "gadgets".

-

Instead of using BinaryFormatter and similar serializers, it is recommended to use safer alternatives in most of the cases, such as XmlSerializer or DataContractSerializer. If -it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:

-
    -
  • by implementing an "allow-list" of types, but keep in mind that novel dangerous types are regularly discovered and this protection could be - insufficient over time.
  • -
  • or/and implementing a tamper protection, such as message authentication codes (MAC). This way - only objects serialized with the correct MAC hash will be deserialized.
  • -
-

Noncompliant code example

-

For BinaryFormatter, -NetDataContractSerializer, +href="https://docs.microsoft.com/en-us/dotnet/api/system.codedom.compiler.tempfilecollection.finalize?view=netframework-4.8">finalize() method of +the TempFileCollection object is called). These kinds of specially crafted serialized objects are called "gadgets".

+

Privilege escalation

+

Unrestricted deserialization can also enable attackers to escalate their privileges within the application. By manipulating the serialized data, an +attacker can modify object properties or bypass security checks, granting them elevated privileges that they should not have. This can result in +unauthorized access to sensitive data, unauthorized actions, or even administrative control over the application.

+

Denial of Service

+

In some cases, an attacker can abuse the deserialization process to cause a denial of service (DoS) condition. By providing specially crafted +serialized data, the attacker can trigger excessive resource consumption, leading to system instability or unresponsiveness. This can disrupt the +availability of the application, impacting its functionality and causing inconvenience to users.

+

How to fix it

+

Code examples

+

Noncompliant code example

+

With BinaryFormatter, SoapFormatter -serializers:

-
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+or SoapFormatter:

+
 Dim myBinaryFormatter = New BinaryFormatter()
-myBinaryFormatter.Deserialize(stream) ' Noncompliant: a binder is not used to limit types during deserialization
+myBinaryFormatter.Deserialize(stream) ' Noncompliant
 
-

JavaScriptSerializer -should not use SimpleTypeResolver or other weak resolvers:

-
-Dim serializer1 As JavaScriptSerializer = New JavaScriptSerializer(New SimpleTypeResolver()) ' Noncompliant: SimpleTypeResolver is unsecure (every types is resolved)
+

With JavaScriptSerializer:

+
+Dim serializer1 As JavaScriptSerializer = New JavaScriptSerializer(New SimpleTypeResolver()) ' Noncompliant: SimpleTypeResolver is insecure (every type is resolved)
 serializer1.Deserialize(Of ExpectedType)(json)
 
-

LosFormatter should not be used without -MAC verification:

-
-Dim formatter As LosFormatter = New LosFormatter() ' Noncompliant
-formatter.Deserialize(fs)
-
-

Compliant solution

-

BinaryFormatter, +

Compliant solution

+

With BinaryFormatter, NetDataContractSerializer -, SoapFormatter -serializers should use a binder implementing a whitelist approach to limit types during deserialization (at least one exception should be thrown or a -null value returned):

-
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+or SoapFormatter:

+
 NotInheritable Class CustomBinder
     Inherits SerializationBinder
     Public Overrides Function BindToType(assemblyName As String, typeName As String) As Type
         If Not (Equals(typeName, "type1") OrElse Equals(typeName, "type2") OrElse Equals(typeName, "type3")) Then
-            Throw New SerializationException("Only type1, type2 and type3 are allowed") ' Compliant
+            Throw New SerializationException("Only type1, type2 and type3 are allowed")
         End If
         Return Assembly.Load(assemblyName).[GetType](typeName)
     End Function
@@ -65,42 +65,66 @@ 

Compliant solution

myBinaryFormatter.Binder = New CustomBinder() myBinaryFormatter.Deserialize(stream)
-

JavaScriptSerializer -should use a resolver implementing a whitelist to limit types during deserialization (at least one exception should be thrown or a null value -returned):

-
+

With JavaScriptSerializer:

+
 Public Class CustomSafeTypeResolver
     Inherits JavaScriptTypeResolver
     Public Overrides Function ResolveType(id As String) As Type
         If Not Equals(id, "ExpectedType") Then
-            Throw New ArgumentNullException("Only ExpectedType is allowed during deserialization") ' Compliant
+            Throw New ArgumentNullException("Only ExpectedType is allowed during deserialization")
         End If
         Return Type.[GetType](id)
     End Function
 End Class
 
-Dim serializer As JavaScriptSerializer = New JavaScriptSerializer(New CustomSafeTypeResolver()) ' Compliant
+Dim serializer As JavaScriptSerializer = New JavaScriptSerializer(New CustomSafeTypeResolver())
 serializer.Deserialize(Of ExpectedType)(json)
 
-

LosFormatter serializer with MAC -verification:

-
-Dim formatter As LosFormatter = New LosFormatter(True, secret) ' Compliant
-formatter.Deserialize(fs)
-
+

Going the extra mile

+

Instead of using BinaryFormatter +and similar serializers, it is recommended to use safer alternatives in most of the cases, such as XmlSerializer or DataContractSerializer.

+

If it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:

+
    +
  • by implementing an "allow-list" of types, but keep in mind that novel dangerous types are regularly discovered and this protection could be + insufficient over time.
  • +
  • or/and implementing a tamper protection, such as message authentication codes (MAC). This way + only objects serialized with the correct MAC hash will be deserialized.
  • +

Resources

+

Documentation

+

Articles & blog posts

+ +

Standards

+ diff --git a/analyzers/src/SonarAnalyzer.CSharp/sonarpedia.json b/analyzers/src/SonarAnalyzer.CSharp/sonarpedia.json index 9613a4c04c0..1ad472bfd63 100644 --- a/analyzers/src/SonarAnalyzer.CSharp/sonarpedia.json +++ b/analyzers/src/SonarAnalyzer.CSharp/sonarpedia.json @@ -3,7 +3,7 @@ "languages": [ "CSH" ], - "latest-update": "2023-09-26T11:50:13.709546400Z", + "latest-update": "2023-10-09T08:25:23.804824400Z", "options": { "no-language-in-filenames": true } diff --git a/analyzers/src/SonarAnalyzer.VisualBasic/sonarpedia.json b/analyzers/src/SonarAnalyzer.VisualBasic/sonarpedia.json index 96ad31a40f2..4e866ece165 100644 --- a/analyzers/src/SonarAnalyzer.VisualBasic/sonarpedia.json +++ b/analyzers/src/SonarAnalyzer.VisualBasic/sonarpedia.json @@ -3,7 +3,7 @@ "languages": [ "VBNET" ], - "latest-update": "2023-09-26T11:50:28.755447400Z", + "latest-update": "2023-10-09T08:26:00.454774600Z", "options": { "no-language-in-filenames": true }