The .NET Framework implements a two-layer defense against security vulnerabilities: role-based security and code access security.
Role-based security allows you to control a user's access to application resources and operations.
Code access security can control the code's access to resources and ability to perform privileged operations.
Authentication is the process of obtaining the user's credentials, such as name and password, that will be identified and validated against an authority.
Authorization is the process of determining, based on credentials, whether a user should be granted a specific type of access to a resource.
Impersonation is the process of allowing code to execute with the identity of the client. Impersonation across computers is called delegation.
Evidence is the collection of information about an assembly and its origin that is used to authenticate the assembly with the .NET Framework.
Code access permissions represent the rights to access specific resources.
Code groups are used to define the permissions that an assembly should receive, providing authorization of the code.
Runtime security policy levels are levels of security that can be applied to the Enterprise, Local Computer, User, and Application Domain. Each of these policy levels has its own hierarchy of code groups and permission sets.
Permission requests should be included in applications that access protected resources. Permission requests should request the minimum permissions that your code must receive to run, and they can ensure that your code receives only the permissions that it actually needs.
Your code can place demands on the caller either declaratively or imperatively. When you demand that the caller have a specific permission, the complete call stack is walked to verify that those permissions exist.
Assert is a downstream call that you can make on a permission to enable your code and downstream caller's code to execute code that your code has permission to do but that the downstream callers might not have permission to do.
Strong-named assemblies that are intended to be called by partially trusted code can declare their intent through the use of the AllowPartiallyTrustedCallersAttribute (APTCA) attribute.
SQL Server can be configured to provide authentication using its own security system (SQL Server authentication) and/or integrated Windows authentication.
In SQL Server, the login is used for authentication, but each database contains its own table of users. The database user is granted permissions to access resources.
The AllowPartiallyTrustedCallersAttribute is fully implemented in the System.Data.dll assembly in ADO.NET 2.0.
In Web applications, you can easily encrypt the connection strings by using the aspnet_regiis.exe utility to encrypt the connectionStrings section of the Web.config file.
You can eliminate the threat of SQL injection attacks by passing values as parameters instead of concatenating the values to create a SQL statement.
Stored procedures inherently eliminate SQL injection attacks because the mechanism for passing data to the stored procedure is the parameter.