Security and Microsoft .NET
In this article I will explain you about Security and Microsoft .NET.
This article has been
excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors
of C# Corner.
The .NET Framework security system is built to provide protection as software
undergoes the metamorphosis to multiple mobile components. The .NET security
system provides a fine-grained, extensible policy and permission system so that
people can run more powerful software code without compromising the system to
security-related risks. The .NET security system enables administrators to
create robust security policies at all levels because administrators are not
forced to determine the trust of users at runtime.
As you will see later, .NET security policies are completely customizable.
Developers can focus mainly on the application logic rather than delving into
security details. Thus they do not need to deal with security at the core level.
Security is handled capably by the CLR in the .NET Framework. Developers can use
and extend .NET security at any time.
Security, an essential part of the .NET Framework, starts immediately after a
class is loaded in the .NET runtime memory area; the framework performs many
initial verification checks to ensure that the code is accessing memory in a
controlled way. Then the framework controls code access to the resources via
code access security.
In the .NET Framework, all code is essentially type safe because it references
only memory blocks that have been reserved for its use and it accesses objects
only through valid, exposed interfaces. From a security point of view,
referencing only designated memory allows multiple objects to safely share a
single address space and allows the accessing of objects only through their
exposed interfaces, thus ensuring that security checks connected with these
specific interfaces are not omitted.
The .NET Framework's security model checks code security not only during load
time but also during runtime. It also allows security checks based on the
identity of the code and of the user. Security policies established and
maintained by administrators or developers govern the access to resources
granted to a given assembly.
The .NET Framework's security model has six major areas:
- type safety and verification, which
ensures that code accesses memory in a controlled way;
- code signing, which ensures that code has
not been tampered with after release by establishing an identity for the
- cryptographic services and data signing,
which protect application data;
- code access security, which, based on the
caller's identity and origin, provides permission to access resources;
- role-based security, which controls code
access based on the user's identity; and
- isolated storage, which persists data in a
safe way on a client computer.
Figure 22.3 depicts some significant features
of the code access security mechanism.
Figure 22.3: Code Access Security in Action
Figure 22.4 outlines some significant features of the role-based security
Figure 22.4: Role-Based Security in Action
The CLR associates strong typing in the metadata, like members, parameters of
methods, array elements, return values of methods, and static values, with
strong typing in the MSIL code, like local variables and stack slots. This
two-way strong-typing enforcement ensures type safety. Thus, regardless of the
language used to develop the program, the resultant executable files or or DLLs
are sure to be type safe, because they are all ultimately MSIL code. The CLR
verifies all of the loaded code before it is run. On demand, you can skip this
verification process by explicitly trusting an assembly through the use of
The .NET Framework security solution is based on the notion of managed code,
with security rules imposed by the CLR. Most managed code is verified to ensure
type safety and the predictable behavior of other security properties. In a
verified code block, a method declared to accept an Int16 value, for example,
will disallow a call attempt with a 16-byte parameter as unsafe. Verification
also ensures that execution flows only to recognized locations (e.g., method
entry points), a process that prevents execution from jumping to an arbitrary
The verification mechanism prevents nontype-safe code from executing and catches
many common programming errors before they cause damage. Well-known system
vulnerabilities, such as access to memory that has not been initialized and the
arbitrary transfer of execution control, are completely disallowed. This
mechanism benefits users because the code they run is checked prior to each
execution. It also benefits developers, who will find that many common,
security-related bugs that have traditionally caused trouble during development
are now identified during the verification process and thus prevented from
damaging system resources.
Besides preventing unauthorized users from accessing the system, the framework
further protects application code and data by enforcing security restrictions on
managed code. These restrictions arise from the six-pronged approach to security
found in the .NET Framework. Let's delve into the details of these six .NET
security areas mentioned earlier.
- Type-safe code can read from or
write to allowed memory locations only. During Just-In-Time (JIT)
compilation, the MSIL code and metadata are examined to verify that the MSIL
code is genuinely type safe and well formed. You can skip this verification
if you set your policies that way.
- Code signing sets an assembly's
uniqueness so that other external processes cannot change the assembly. With
strong-named assemblies, each file in the assembly loaded at runtime is
hashed and that hash value is compared to the hash value stored in the
manifest for that file. If the hash values do not match, the system refuses
to load the file and throws an exception. As an alternative or as an added
precaution, you may want to sign strong-named assemblies by using Microsoft
Authenticode. This is useful in environments where a trust hierarchy is
already in place and certificates are required. For example, Microsoft
ActiveX controls are expected to have certificates that are downloaded and
run inside Microsoft Internet Explorer.
- Cryptographic services and data signing
(encryption of data) classes of .NET help you to offer a secure
environment for your data by providing nearly all of the common cryptography
algorithms. Thus, you can encrypt and decrypt your data with various
- Code access security permits code
to access protected resources as long as code really has the requested
permission (the right to access protected resources). Your code has a
permission set that is constructed according to the active security policy.
When your code accesses system resources, the system checks the code for the
- Role-based security allows the
system to make decisions about a user's authority to access resources based
on the user's identity and role membership information, which is determined
by the code.
- Isolated storage, a virtual file
system for data storage, is isolated per assembly and user. For example,
Web-based applications downloaded from intranet or Internet sites may not
have access to the ordinary file system. Such applications can have their
data, files, and directories stored in this isolated virtual file system.
You can limit the size of isolated storage.
Hope this article
would have helped you in understanding Security and Microsoft .NET. See other articles on the website on .NET and C#.
| ||The Complete Visual
C# Programmer's Guide covers most of the major components that make
up C# and the .net environment. The book is geared toward the
intermediate programmer, but contains enough material to satisfy the
advanced developer. |