Objectives:
• Review the composition of .NET assemblies
• Understand the role of Application Domains
• Define ‘roundtrip engineering’
• Learn to protect assemblies from tampering using strong names
• Understand the role of obfuscation
• Understand the role of publisher certificates
• Understand the role of FxCop.exe
• Define the role of cryptographic services
• Understand the role of hash algorithms and hash codes
• Generate hashed data using the .NET framework
• Validate hash codes programmatically
Chapter Overview
The .NET framework provides numerous technologies which allow developers to build secure applications.
Although most programmers assume .NET security solely revolves around Code Access Security, Role Based
Security and cryptographic services, the assembly itself can be secured to prevent ‘evil doers’ from tampering
with its contents.
In this chapter you will examine several techniques to keep your assembly secure.
Reviewing the .NET Assembly Format
• A .NET assembly is a reusable, binary unit which typically takes a *.dll or *.exe file extension.
• A .NET assembly can contain any number of namespaces, which are simply a collection of semantically
related types.
• A .NET type must be from the set {class, interface, structure, enumeration, delegate}.
• A type consists of any number of members (constructors, methods, properties, nested types, readonly
fields, overloaded operators, etc).
• A single assembly many define multiple namespaces, each containing multiple types:
• Recall that an assembly does not need to define an identically named namespace.
• Regardless of the assembly’s file extension (*.dll or *.exe), assemblies typically consist of the following
elements:
• Common Intermediate Language (CIL): A platform and processor agnostic intermediate language.
• Assembly manifest: A block of metadata which describes the assembly itself (version number, culture,
referenced assemblies, modules, strong name information, etc).
• Type metadata: Metadata that describes the format of each and every type defined in the CIL code as
all as each external type referenced by the CIL code.
• Resources: String tables, image files, sound clips, etc.
• Regardless of which .NET programming language you use, the associated compiler emits platform and
processor agnostic CIL code:
• CIL code is not directly executed by the CLR. Rather, CIL code must be just-in-time compiled before
execution.
• The ngen.exe utility can be used to compile CIL code to native code upon application installation.
• .NET compilers have liberties when translating source code files into CIL code.
• Recall that .NET assemblies leverage the CTS type system, not a ridged binary format as we had in
COM.
• Given this, different .NET language compilers may emit slightly different CIL code for the same set of
statements.
• Assume we have authored two assemblies (both named MySingleFileAsm.dll) using C# and VB.
• This assembly defines a single class named MyCriticalClass.
• This class has a single method named GetSensitiveInformation().
• Here is the C# code and resulting CIL:
public class MyCriticalClass
{
public string GetSensitiveInformation()
{
return "The magic value is 9";
}
}
.method public hidebysig instance string
GetSensitiveInformation() cil managed
{
// Code size 10 (0xa)
.maxstack 1
.locals init ([0] string CS$00000003$00000000)
IL_0000: ldstr "The magic value is 9"
IL_0005: stloc.0
IL_0006: br.s IL_0008
IL_0008: ldloc.0
IL_0009: ret
} // end of method MyCriticalClass::GetSensitiveInformation
• Here is the same class authored in VB and the resulting CIL code:
Public Class MyCriticalClass
Public Function GetSensitiveInformation() As String
Return "The magic value is 9"
End Function
End Class
.method public instance string GetSensitiveInformation() cil managed
{
// Code size 11 (0xb)
.maxstack 1
.locals init ([0] string GetSensitiveInformation)
IL_0000: nop
IL_0001: ldstr "The magic value is 9"
IL_0006: stloc.0
IL_0007: br.s IL_0009
IL_0009: ldloc.0
IL_000a: ret
} // end of method MyCriticalClass::GetSensitiveInformation
• As you can see, CIL code is very human readable…
• Notice that the ‘sensitive string’ within GetSensitiveInformation() can be directly viewed through CIL
disassembly tools such as ildasm.exe or reflector.exe.
• Later in this chapter we will see how this alone can be a large security risk (and various ways to
minimize this threat).
• Review the composition of .NET assemblies
• Understand the role of Application Domains
• Define ‘roundtrip engineering’
• Learn to protect assemblies from tampering using strong names
• Understand the role of obfuscation
• Understand the role of publisher certificates
• Understand the role of FxCop.exe
• Define the role of cryptographic services
• Understand the role of hash algorithms and hash codes
• Generate hashed data using the .NET framework
• Validate hash codes programmatically
Chapter Overview
The .NET framework provides numerous technologies which allow developers to build secure applications.
Although most programmers assume .NET security solely revolves around Code Access Security, Role Based
Security and cryptographic services, the assembly itself can be secured to prevent ‘evil doers’ from tampering
with its contents.
In this chapter you will examine several techniques to keep your assembly secure.
Reviewing the .NET Assembly Format
• A .NET assembly is a reusable, binary unit which typically takes a *.dll or *.exe file extension.
• A .NET assembly can contain any number of namespaces, which are simply a collection of semantically
related types.
• A .NET type must be from the set {class, interface, structure, enumeration, delegate}.
• A type consists of any number of members (constructors, methods, properties, nested types, readonly
fields, overloaded operators, etc).
• A single assembly many define multiple namespaces, each containing multiple types:
• Recall that an assembly does not need to define an identically named namespace.
• Regardless of the assembly’s file extension (*.dll or *.exe), assemblies typically consist of the following
elements:
• Common Intermediate Language (CIL): A platform and processor agnostic intermediate language.
• Assembly manifest: A block of metadata which describes the assembly itself (version number, culture,
referenced assemblies, modules, strong name information, etc).
• Type metadata: Metadata that describes the format of each and every type defined in the CIL code as
all as each external type referenced by the CIL code.
• Resources: String tables, image files, sound clips, etc.
• Regardless of which .NET programming language you use, the associated compiler emits platform and
processor agnostic CIL code:
• CIL code is not directly executed by the CLR. Rather, CIL code must be just-in-time compiled before
execution.
• The ngen.exe utility can be used to compile CIL code to native code upon application installation.
• .NET compilers have liberties when translating source code files into CIL code.
• Recall that .NET assemblies leverage the CTS type system, not a ridged binary format as we had in
COM.
• Given this, different .NET language compilers may emit slightly different CIL code for the same set of
statements.
• Assume we have authored two assemblies (both named MySingleFileAsm.dll) using C# and VB.
• This assembly defines a single class named MyCriticalClass.
• This class has a single method named GetSensitiveInformation().
• Here is the C# code and resulting CIL:
public class MyCriticalClass
{
public string GetSensitiveInformation()
{
return "The magic value is 9";
}
}
.method public hidebysig instance string
GetSensitiveInformation() cil managed
{
// Code size 10 (0xa)
.maxstack 1
.locals init ([0] string CS$00000003$00000000)
IL_0000: ldstr "The magic value is 9"
IL_0005: stloc.0
IL_0006: br.s IL_0008
IL_0008: ldloc.0
IL_0009: ret
} // end of method MyCriticalClass::GetSensitiveInformation
• Here is the same class authored in VB and the resulting CIL code:
Public Class MyCriticalClass
Public Function GetSensitiveInformation() As String
Return "The magic value is 9"
End Function
End Class
.method public instance string GetSensitiveInformation() cil managed
{
// Code size 11 (0xb)
.maxstack 1
.locals init ([0] string GetSensitiveInformation)
IL_0000: nop
IL_0001: ldstr "The magic value is 9"
IL_0006: stloc.0
IL_0007: br.s IL_0009
IL_0009: ldloc.0
IL_000a: ret
} // end of method MyCriticalClass::GetSensitiveInformation
• As you can see, CIL code is very human readable…
• Notice that the ‘sensitive string’ within GetSensitiveInformation() can be directly viewed through CIL
disassembly tools such as ildasm.exe or reflector.exe.
• Later in this chapter we will see how this alone can be a large security risk (and various ways to
minimize this threat).
.NET Security Tutorial
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials