.NET has its own security mechanism with two general features: Code Access Security (CAS), and validation and verification. Code Access Security is based on evidence that is associated with a specific assembly. Typically the evidence is the source of the assembly. Code Access Security uses evidence to determine the permissions granted to the code. Other code can demand that calling code is granted a specified permission. The demand causes the CLR to perform a call stack walk: every assembly of each method in the call stack is checked for the required permission; if any assembly is not granted the permission a security exception is thrown.

When an assembly is loaded the CLR performs various tests. Two such tests are validation and verification. During validation the CLR checks that the assembly contains valid metadata and CIL, and whether the internal tables are correct. Verification is not so exact. The verification mechanism checks to see if the code does anything that is 'unsafe'. The algorithm used is quite conservative; hence occasionally code that is 'safe' does not pass. Unsafe code will only be executed if the assembly has the 'skip verification' permission, which generally means code that is installed on the local machine.

.NET Framework uses appdomains as a mechanism for isolating code running in a process. Appdomains can be created and code loaded into or unloaded from them independent of other appdomains. This helps increase the fault tolerance of the application, as faults or crashes in one appdomain do not affect rest of the application. Appdomains can also be configured independently with different security privileges. This can help increase the security of the application by isolating potentially unsafe code. The developer, however, has to split the application into subdomains; it is not done by the CLR.

<configSections> contains the "Microsoft.Csf" and "Microsoft.Web.Services2" <sectionGroup> tags - these <sectionGroup> tags need to be specified in order for the sections to be used properly.
One ASP.NET Security Task that was essentially impossible to perform in a shared ASP.NET 1.1 hosting environment was connection string encryption. Encrypting connection strings, encrypting application settings, or any part of Web.config required additional access to the hosting environment above and beyond what most 3rd party host providers were willing to provide to their customers.

ASP.NET 2.0 has now made this monumental task of encrypting configuration sections within Web.config a snap. There are no more excuses in .NET 2.0 as to why you haven't encrypted sensitive information, such as connection strings, in your Web.config. Not only can you encrypt config sections using aspnet_regiis from the command line, but you can also encrypt and unencrypt Web.config on the fly in code.
Encrypt AppSettings Programatically by programmer.

Shown below is a snippet of the application settings in Web.config in ASP.NET 2.0. Unprotected, you can read the application settings really easily. However, if this is private data that you don't want people to know, it is best to encrypt it.

<appSettings>
<add key="SiteName" value="My Website" />
<add key="SecretKey" value="56789012" />
appSettings>

The code for protecting and unprotecting sections in your Web.config is fairly trivial, because WebConfigurationManager-related classes handle all the work for you. I added two buttons to a web page, called btnProtect and btnUnProtect, to protect and unprotect on the fly. Here is the code of interest:

protected void UnProtect_Click(object sender, EventArgs e)
{
UnProtectSection("appSettings");
}

protected void Protect_Click(object sender, EventArgs e)
{
ProtectSection("appSettings",
"DataProtectionConfigurationProvider");
}

private void ProtectSection(string sectionName,
string provider)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);

ConfigurationSection section =
config.GetSection(sectionName);

if (section != null &&
!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}

private void UnProtectSection(string sectionName)
{
Configuration config =
WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);

ConfigurationSection section =
config.GetSection(sectionName);

if (section != null &&
section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}

The code is very self-explanatory. The amazing part is how trivial it is. Here is what the application settings look like when encrypted:

<appSettings configProtectionProvider=
"DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>
AQApppsswertyERjHoAwE/Cl+sBAAA
AXmrl4EN1VUSGDS9ZSSydRwQAAAACAA
AAAAADZgAAqAAAABAAAAA280OtZlZwu
D3U+ihvi23456gtfrdAEAAAr655566
AJ6AnDzWM1o3osh/Y6fcYtwAAQAA1PR
+wzfwgBgZ4y0yHU4uxaaMET13u21Bv3
zVE7aA7Z5pCWAYs54LNLNYQ673kmzAL
osWb7OMuzW6BPwMpwer456tggy
...
CipherValue>
CipherData>
EncryptedData>
appSettings>