Assembly Security Threats and Various Countermeasures
• .NET assemblies (if left unprotected) can be vulnerable to a number of security risks:
• Here is a high-level overview of common security risks.
• Further details will be provided over the remainder of this class.
• (1) The first threat is access by unauthorized users:
• As shown later in this class, this threat can be avoided through various forms of
authentication/authorization (such as Role Based Security (RBS)).
• Using RBS, you can create assemblies (as well as types and type members) which can only be accessed
by specific users or groups.
• (2) Next, CIL can be reverse-engineered by evil doers:
• If left unprotected, an assembly can be disassembled, altered and redeployed.
• This could allow an ‘evil doer’ to change the implementation of your type members.
• This threat can be minimized through the use of strong naming, publisher certificates and obfuscation.
• (3) Any exposed sensitive information (connection strings, unhandled exceptions, etc) can be a major
threat:
• Again, using tools like ildasm.exe, evil doers could directly view any string data.
• Unhandled exceptions could clue-in an evil doer as to how an assembly functions under the hood (for
example, an unhandled FileNotFoundException which prints out the location of a sensitive file in the call
stack).
• These issues can be avoided by not storing sensitive data in the assembly and obfuscating the assembly.
• (4) “Code injection” is a term describing the threat of evil-doers inserting bogus (but syntactically
correct) information into an executing assembly:
• For example, providing bogus data to an input field to cause a buffer overflow.
• SQL injection attacks also fall into this category, whereby malicious SQL statements are passed into
your application for processing.
• Obviously the way to avoid this threat is to validate all input fields using validation controls, authoring
custom business logic, etc.
• (5) Assemblies can be hijacked by a ‘luring attack’.
• Malicious code could bypass the authorization of an assembly using a trusted assembly as an
intermediary.
• As shown later in this class, luring attacks can be prevented using Code Access Security (CAS).
• (6) Finally, an assembly may attempt to access an external resource which it is not authorized to use
(such as the system registry, parts of the file system, etc):
• Code Access Security provides an ‘identity’ to an assembly which can be used by the CLR to monitor
what the assembly attempts to access.
• .NET assemblies (if left unprotected) can be vulnerable to a number of security risks:
• Here is a high-level overview of common security risks.
• Further details will be provided over the remainder of this class.
• (1) The first threat is access by unauthorized users:
• As shown later in this class, this threat can be avoided through various forms of
authentication/authorization (such as Role Based Security (RBS)).
• Using RBS, you can create assemblies (as well as types and type members) which can only be accessed
by specific users or groups.
• (2) Next, CIL can be reverse-engineered by evil doers:
• If left unprotected, an assembly can be disassembled, altered and redeployed.
• This could allow an ‘evil doer’ to change the implementation of your type members.
• This threat can be minimized through the use of strong naming, publisher certificates and obfuscation.
• (3) Any exposed sensitive information (connection strings, unhandled exceptions, etc) can be a major
threat:
• Again, using tools like ildasm.exe, evil doers could directly view any string data.
• Unhandled exceptions could clue-in an evil doer as to how an assembly functions under the hood (for
example, an unhandled FileNotFoundException which prints out the location of a sensitive file in the call
stack).
• These issues can be avoided by not storing sensitive data in the assembly and obfuscating the assembly.
• (4) “Code injection” is a term describing the threat of evil-doers inserting bogus (but syntactically
correct) information into an executing assembly:
• For example, providing bogus data to an input field to cause a buffer overflow.
• SQL injection attacks also fall into this category, whereby malicious SQL statements are passed into
your application for processing.
• Obviously the way to avoid this threat is to validate all input fields using validation controls, authoring
custom business logic, etc.
• (5) Assemblies can be hijacked by a ‘luring attack’.
• Malicious code could bypass the authorization of an assembly using a trusted assembly as an
intermediary.
• As shown later in this class, luring attacks can be prevented using Code Access Security (CAS).
• (6) Finally, an assembly may attempt to access an external resource which it is not authorized to use
(such as the system registry, parts of the file system, etc):
• Code Access Security provides an ‘identity’ to an assembly which can be used by the CLR to monitor
what the assembly attempts to access.
Assembly Security Threats
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