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 @@
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.
++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 @@
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.
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.
+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.
+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:
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".
+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.
+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.
+With BinaryFormatter
,
SoapFormatter
-serializers:
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+orSoapFormatter
: +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
-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
+orSoapFormatter
: +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 asXmlSerializer
orDataContractSerializer
.If it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:
+
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.
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.
+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.
+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:
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".
+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.
+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.
+With BinaryFormatter
,
SoapFormatter
-serializers:
+href="https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.netdatacontractserializer">NetDataContractSerializer
+orSoapFormatter
: +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
-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
+orSoapFormatter
: +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 asXmlSerializer
orDataContractSerializer
.If it’s not possible then try to mitigate the risk by restricting the types allowed to be deserialized:
+