Add secure ResX functionality to System.Resources

Background and Motivation

The .NET Framework had ResX* functionality that allowed the use of .resx resource files. .NET Core and later, no longer has this functionality, but does have something similar in System.Windows.Forms of the dotnet / winforms SDK. The original implementation, and the winforms implementation both have security flaws related to loading of assemblies defined in the .resx files themselves.

We have requirements that these resource files must be in plain text on the file system, thus we can't use the compiled .resource assemblies that were implemented. It should be possible to come up with a different schema for these resource files that does not define the assemblies to use in the resource file itself. The new resource files need to retain support for externally linked files. All values should be available as either a string, a byte array, or a stream, and nothing else.

This is a replacement for #47795 which was closed due to the security issues.

Proposed API

TBD, but it should be similar to the original design, including culture support. It should be as simple as possible, similar to how configuration files were greatly simplified in ASP.NET. With the limitation discussed above the existing tooling in Visual Studio for .resx files could be reused with slight modifications. The tooling should include the creation of partial classes as well.

Alternative Designs

I have found a way to hack the current winforms DLLs into an ASP.NET application, but it has the security risks mentioned above, and is reliant of the specific version of the .NET SDK being used.

Risks

The entire purpose of this functionality is to provide functionality w/o the risks that currently exist. There should not be any risk by adding new functionality that itself is safe.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @tarekgh, @buyaa-n, @krwq
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and Motivation

The .NET Framework had ResX* functionality that allowed the use of .resx resource files. .NET Core and later, no longer has this functionality, but does have something similar in System.Windows.Forms of the dotnet / winforms SDK. The original implementation, and the winforms implementation both have security flaws related to loading of assemblies defined in the .resx files themselves.

We have requirements that these resource files must be in plain text on the file system, thus we can't use the compiled .resource assemblies that were implemented. It should be possible to come up with a different schema for these resource files that does not define the assemblies to use in the resource file itself. The new resource files need to retain support for externally linked files. All values should be available as either a string, a byte array, or a stream, and nothing else.

This is a replacement for #47795 which was closed due to the security issues.

Proposed API

TBD, but it should be similar to the original design, including culture support. It should be as simple as possible, similar to how configuration files were greatly simplified in ASP.NET. With the limitation discussed above the existing tooling in Visual Studio for .resx files could be reused with slight modifications. The tooling should include the creation of partial classes as well.

Alternative Designs

I have found a way to hack the current winforms DLLs into an ASP.NET application, but it has the security risks mentioned above, and is reliant of the specific version of the .NET SDK being used.

Risks

The entire purpose of this functionality is to provide functionality w/o the risks that currently exist. There should not be any risk by adding new functionality that itself is safe.

Author:	Kaelum
Assignees:	-
Labels:	api-suggestion, area-System.Resources, untriaged
Milestone:	-

[krwq]

@tarekgh do you pehaps have any clues if we have some alternative solutions?

[tarekgh]

The .NET Framework had ResX* functionality that allowed the use of .resx resource files.

Wasn't supported there by WinForms too? According to the doc

do you pehaps have any clues if we have some alternative solutions?

WinFomrs has this functionality, but it looks there is some security concerns there. @GrabYourPitchforks may know better here. In general, I agree such functionality would be better to exist in the core level and not in WinForms levels because forcing users to host WinForms for just handling resources wouldn't be good.

@Kaelum would be nice of you share more details about your scenarios. Why using .resources files is not enough.

WinFomrs has this functionality, but it looks there is some security concerns there.

I'll cover this first, as it is the second most import issue, behind that of the functionality completely missing. The original concept of resource files was to not only contain text, but to also house fully instantiated objects by declaring the fully qualified type in the .resx file, and dynamically loading that DLL (the security flaw). By only allowing text, byte arrays, and streams, the same objects can still be encoded, but object reconstitution will need to be hard coded in the application code. This puts the burden of safety on the application, not the library.

...would be nice of you share more details about your scenarios. Why using .resources files is not enough.

Our requirements are that the resource files must be in plain text, which includes XML with CDATA blocks. These files cannot be in any binary form, which includes that of being embedded in an assembly, thus .resources files can't be used. On top of that, .resources files can't have a key point to the contents of another file for it's value, which is also a requirement.

If the ResourceManager can be expanded to support this, the functionality would be on par with the original .NET Framework functionality, and it would also be safe to use. The new functionality would not in itself introduce any security issues. If the consumer instantiates an object based on the contents of the resource file, it would be up to the consumer to ensure that the contents is safe, not the library itself.

As I also stated in the original post, this could be very lightweight, and should be. I wholeheartedly agree with @tarekgh when he says:

In general, I agree such functionality would be better to exist in the core level and not in WinForms levels...

as we need this to work on all platforms, including MAC and Linux, which is a problem with WinForms.

[GrabYourPitchforks]

By only allowing text, byte arrays, and streams, the same objects can still be encoded, but object reconstitution will need to be hard coded in the application code. This puts the burden of safety on the application, not the library.

This is a similar approach to we were batting around internally a while back. We were considering adding a few additional items like images and other multimedia formats, but the gist is the same: store only data, not raw objects.

In general I'd be fine with advancing this plan. But ultimately it would look like this would be a new format, not something that is expected to be backward compatible with .NET Framework applications. We would need to figure out if back-compat is an issue here.

@GrabYourPitchforks I've been thinking about the backwards compatibility, and as long as the value can be returned as either a byte[] or Stream, the format would not vary by that much, and should be readable. The majority of the existing .resx schema is attributes that can safely be ignored, as they are the fully qualified object names. Current example:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
[snip]
  </xsd:schema>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <resheader name="reader">
    <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
  <resheader name="writer">
    <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
  </resheader>
  <assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  <data name="Type_mismatch_on_column" xml:space="preserve">
    <value>Type mismatch on column {0}: [{1}].</value>
  </data>
  <data name="Type_mismatch_on_parameter" xml:space="preserve">
    <value>Type mismatch on parameter {0}.</value>
  </data>
  <data name="Unknown_column" xml:space="preserve">
    <value>Unknown column: [{0}]</value>
  </data>
  <data name="CountryCodesJson" type="System.Resources.ResXFileRef, System.Windows.Forms">
    <value>CountryCodes.json;System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089;UTF-8</value>
    <comment>https://github.com/lukes/ISO-3166-Countries-with-Regional-Codes/raw/master/all/all.json</comment>
  </data>
  <data name="CountryCodesXml" type="System.Resources.ResXFileRef, System.Windows.Forms">
    <value>CountryCodes.xml;System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089;UTF-8</value>
    <comment>https://github.com/lukes/ISO-3166-Countries-with-Regional-Codes/raw/master/all/all.xml</comment>
  </data>
</root>

The majority is fluff and can easily be ignored/removed. However, the external file references should probably be changed so that a <link> element replaces the <value> and <comment> elements, and solely contains either an absolute or relative file system reference. That would be breaking, and could be addressed in the Visual Studio tooling. It is unlikely that anyone using the legacy .resx files is not also using Visual Studio.

Proposal format to replace the above .resx file:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="Type_mismatch_on_column">
    <value>Type mismatch on column {0}: [{1}].</value>
  </data>
  <data name="Type_mismatch_on_parameter">
    <value>Type mismatch on parameter {0}.</value>
  </data>
  <data name="Unknown_column">
    <value>Unknown column: [{0}]</value>
  </data>
  <data name="CountryCodesJson">
    <link>CountryCodes.json</link>
  </data>
  <data name="CountryCodesXml">
    <link>CountryCodes.xml</link>
  </data>
</root>

Alternate proposed format (breaking, while still supporting CDATA):

<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="Type_mismatch_on_column" type="value">Type mismatch on column {0}: [{1}].</data>
  <data name="Type_mismatch_on_parameter" type="value">Type mismatch on parameter {0}.</data>
  <data name="Unknown_column" type="value">Unknown column: [{0}]</data>
  <data name="CountryCodesJson" type="link">CountryCodes.json</data>
  <data name="CountryCodesXml" type="link">CountryCodes.xml</data>
</root>

I'm fine with either of the above formats, or anything similar. I think that the legacy file naming format for localization could be used, but if there is something better, that's good as well.

[koszeggy]

As I commented also in #47795, I created a library, which supports handling .resx files and attempts to fix a sort of issues:

• It does not have any 3rd party reference, and it can be used on any platform
• It is more or less compatible with the WinForms version (and can read and write compatible .resx files)
• Many System.Resources types have been reimplemented, including ResXFileRef, ResXDataNode, ResXResourceReader, ResXResourceWriter and ResXResourceSet classes (see the links for the comparisons and possible incompatibilities)
• The original ResXResourceReader may load assemblies during parsing the .resx file even if its UseResXDataNodes property is true. In contrast, the replacement ResXResourceReader does not resolve any type even if its SafeMode is false until the value of a specific resource is explicitly accessed.
• The replacement ResXDataNode provides more properties to examine the raw .resx content before deserializing it. It has separate GetValue and GetValueSafe methods. The latter prevents loading new assemblies during the possible deserialization.
• The replacement ResXDataSet is a read-write object. It supports adding new resources and saving them. It always reads only the raw .resx content, even if its SafeMode property is false, in which case deserialization occurs only when a non-string value is explicitly obtained. And if SafeMode is true, then GetString never throws an exception: for non-string values it returns the underlying XML value.
• ResXResourceManager, HybridResourceManager and DynamicResourceManager have no corresponding types in System.Resources. They can be used the same way as a regular ResourceManager but they can work on .resx files and they support adding new resources. All of them have a SafeMode property. See the links for more details.

Feel free to migrate it in the dotnet code base. Until then, it is available as a NuGet package.

@koszeggy in the interim, we are actually using your library, so Thank You for that!

However, long term, it would be significantly better if the functionality of this issue were added to the core functionality of ,NET. It would by no means negate your library, but it would provide the bare basics that others could use (including yourself) to build upon, and would be inline with how the ASP.NET team reduced the configuration file functionality to the bare bones. And best of all, it would be an officially supported Microsoft Standard.