ADO.NET 2.0 Security Guidelines - Code Access Security Considerations

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe


Use a Custom Policy if You Need to Access Non-SQL Server Databases from Partial Trust ASP.NET Applications

Default medium trust ASP.NET policy grants applications the SqlClientPermission. This means that Web applications configured to run at medium trust can access SQL Server databases. If you need to access additional database types by using an alternate provider, you must create a custom policy and grant the appropriate permission (such as OleDbPermission) to access non–SQL Server OLE DB data sources.

For more information about customizing policy, see "How To: Use Medium Trust in ASP.NET 2.0" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000020.asp.

Consider Restricting Database Access on Hosted Servers

Adding the unrestricted OleDbPermission to your policy file means that your application can use any OLE DB provider on the server. In a hosted environment, an administrator might need to use the more advanced form of the OleDbPermission syntax to lock down connection strings used with OleDbPermission to allow access only to specific databases. The following example shows how to restrict access to a specific OLE DB data source.

<IPermission class="OleDbPermission"
            version="1">
 <add ConnectionString=
         "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\data\w4w.mdb"
      KeyRestrictions=""
      KeyRestrictionBehavior="AllowOnly"/>
</IPermission>
 

For more information, see "How To: Use Medium Trust in ASP.NET 2.0" at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000020.asp.

Do Not Rely on StrongNameIdentityPermission to Restrict Full Trust Callers

If you protect your data access code with a link demand for a StrongNameIdentityPermission to restrict the code that can call your code, be aware that this only works for partial trust callers. The link demand will always succeed for full trust callers regardless of the strong name of the calling code.

In .NET 2.0 any fully trusted assembly will satisfy any demand, including a link demand for an identity permission that the assembly does not satisfy. In .NET 1.0 this did not happen automatically. However, a fully trusted assembly could simply call Assembly.Load, supplying as evidence the strong name it wants to satisfy or alternatively it could turn code access security off.

The only protection against fully trusted code is to put it in a separate process and run that process with a restricted token so that its limits are enforced by the operating system. This applies whether code marks its interfaces as internal, private, or places link demands for StrongNameIdentityPermission on them.

The following code sample shows a method decorated with a link demand for a specific StrongNameIdentityPermission.

using System.Security.Permissions;
. . .
[StrongNameIdentityPermission(SecurityAction.LinkDemand,
                             PublicKey="002...4c6")]
public void GetCustomerInfo(int CustId)
{
}
Personal tools