2

I am reviewing a Fortify static analysis security test (SAST) scan report in other to identify and suppress false positives. The application framework is C#.NET Core. The SAST report reads in part:

"Method1() stores a non-serializable object as an HttpSessionState attribute on line 111, which can damage application reliability. Storing a non-serializable object as an HttpSessionState attribute can damage application reliability"

The code at Line 111 is like so:

Session[key] = Request.QueryString["abcd"];

I was going to suppress the issue as a false positive because we are storing string objects and strings are serializable by default. But then I researched and found that "string is serializable by default" is only true in .NET framework because string definition is decorated with the Serializable attribute in .NET; whereas, in .NET Core string definition is not decorated with the Serializable attribute.

So, because this is a .NET Core application, is the Fortify SAST assertion correct? Is a string not serializable by default in .NET core? Your insight will be appreciated. Thanks.

jason.kaisersmith
  • 8,712
  • 3
  • 29
  • 51
Adams
  • 79
  • 1
  • 4
  • `But then I researched and found that "string is serializable by default" is only true in .NET framework because string definition is decorated with the Serializable attribute in .NET; whereas, in .NET Core string definition is not decorated with the Serializable attribute.` Show us **where** you found that information. – mjwills May 08 '20 at 02:14
  • Please share a [mcve]. – mjwills May 08 '20 at 02:16
  • @mjwills: when I went to MS doc [.NET framework](https://learn.microsoft.com/en-us/dotnet/api/system.string?view=netframework-4.8) I saw, as expected, that a string is decorated with the Serializable attribute. But there is no such decoration in the case of [.NET core:](https://learn.microsoft.com/en-us/dotnet/api/system.string?view=netcore-3.1). – Adams May 08 '20 at 04:51

1 Answers1

1

My research on this suggests that this is a false positive. There's a similar question to yours from two years ago with several answers that come to a similar conclusion, but I dug into it a little bit more.

The original .NET Framework documentation on serialization indicates that the object as a whole is marked with the [Serializable] attribute, and not the property within it (your string) in this case, but it itself doesn't speak directly to strings.

That said, it looks like the original version of .NET Core didn't actually support the [Serializable] attribute for binary serialization until .NET Core 2.0. However, in that release, you can read the documentation that cites System.String as a supported serializable type, though it still recommends using other serialization frameworks (see the paragraph under the warning at the top of that page).

The .NET Core documentation on serialization is split into several different articles, but again, you can see that in the Basic Serialization document, it again indicate that the class itself is marked (not the string property, though it sports one in the example) and yet also indicates that it will be successfully serialized.

Per the last citation:

[Serializable]  
public class MyObject {  
  public int n1 = 0;  
  public int n2 = 0;  
  public String str = null;  
}  

And logic from those docs that would write a string to the appropriate property and serialize accordingly.

MyObject obj = new MyObject();  
obj.n1 = 1;  
obj.n2 = 24;  
obj.str = "Some String";  
IFormatter formatter = new BinaryFormatter();  
Stream stream = new FileStream("MyFile.bin", FileMode.Create, FileAccess.Write, FileShare.None);  
formatter.Serialize(stream, obj);  
stream.Close();

Thus, I would conclude that this is indeed a false positive as long as you're using .NET Core 2.0, .NET Standard 2.0 or newer with binary serialization and marking that class it's used within with the [Serializable] attribute. Otherwise, check the requirements of the serialization framework you're otherwise using to see if it needs any such attribute decoration (e.g. Newtonsoft.Json doesn't need [JsonProperty] attributes on the properties unless you want to specify custom names for the serialized properties, nor does it need any sort of attribute on the class itself).

Whit Waldo
  • 4,806
  • 4
  • 48
  • 70