.NET Framework 1.1 Security Guidelines - Reflection

From Guidance Share

Revision as of 03:27, 13 December 2007; JD (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Security issues when using Reflection

With reflection, you can dynamically load assemblies, discover information about types, and execute code. You can also obtain a reference to an object and get or set its private members. This has a number of security implications:

  • If your code uses reflection to reflect on other types, make sure that only trusted code can call you. Use code access security permission demands to authorize calling code. For more information, see Chapter 8, "Code Access Security in Practice." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh08.asp
  • If you dynamically load assemblies, for example, by using System.Reflection.Assembly.Load, do not use assembly or type names passed to you from untrusted sources.
  • If your assemblies dynamically generate code to perform operations for a caller, make sure the caller is in no way able to influence the code that is generated. This issue is more significant if the caller operates at a lower trust level than the assembly that generates code.
  • If your code generation relies on input from the caller, be especially vigilant for security vulnerabilities. Validate any input string used as a string literal in your generated code and escape quotation mark characters to make sure the caller cannot break out of the literal and inject code. In general, if there is a way that the caller can influence the code generation such that it fails to compile, there is probable security vulnerability.

For more information, see "Secure Coding Guidelines for the .NET Framework" in the MSDN Library at http://msdn.microsoft.com/library/en-us/dnnetsec/html/seccodeguide.asp

Personal tools