Security Considerations

This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.

This topic describes security considerations that are specific to developing, deploying, and running Telerik Data Access applications. You should also follow recommendations for creating secure .NET Framework applications.

In This Topic

General Security Considerations

The following security considerations apply to all applications that use Telerik Data Access.

Use only trusted data source providers

To communicate with the data source, a provider must do the following:

Receive the connection string from the Telerik Data Access.
Translate the command tree to the data source's native query language.
Assemble and return result sets.

During the logon operation, information that is based on the user password is passed to the server through the network libraries of the underlying data source. A malicious provider can steal user credentials, generate malicious queries, or tamper with the result set.

Encrypt your connection to protect sensitive data

Telerik Data Access does not directly handle data encryption. If users access data over a public network, your application should establish an encrypted connection to the data source to increase security. For more information, see the security-related documentation for your data source.

Secure the connection string

Protecting access to your data source is one of the most important goals when securing an application. A connection string presents a potential vulnerability if it is not secured or if it is improperly constructed. When you store connection information in plain text or persist it in memory, you risk compromising your entire system. The following are the recommended methods for securing connection strings:

Use Windows Authentication with a SQL Server data source - when you use Windows Authentication to connect to SQL Server data source, the connection string does not contain logon and password information.
Encrypt configuration file sections using protected configuration - ASP.NET provides a feature called protected configuration that enables you to encrypt sensitive information in a configuration file. Although primarily designed for ASP.NET, you can also use protected configuration to encrypt sections of configuration files in Windows applications. For a detailed description of the new protected configuration capabilities, see MSDN.
Store connection strings in secured configuration files - you should never embed connection strings in your source code. You can store connection strings in configuration files, which eliminates the need to embed them in your application's code. By default, the Telerik Data Access Create Model Wizard stores connection strings in the application configuration file. You must secure this file to prevent unauthorized access.
Use connection string builders when dynamically creating connections - if you must construct connection strings at runtime, use the DbConnectionStringBuilder class. This string builder class helps to prevent connection string injection attacks by validating and escaping invalid input information. Also use the appropriate string builder class to construct the data source connection string that is part of the Telerik Data Access connection string.

Do not pass connections outside the security context

After a connection has been established, you must not pass it outside the security context. For example, one thread with permission to open a connection should not store the connection in a global location. If the connection is available in a global location, then another malicious thread can use the open connection without having that permission explicitly granted to it.

Be aware that logon information and password may be visible in a memory dump

When data source logon and password information is supplied in the connection string, this information is maintained in memory until garbage collection reclaims the resources. This makes it impossible to determine when a password string is no longer in memory. If an application crashes, a memory dump file may contain sensitive security information, and the user who is running the application or any user with administrative access to the computer can view the memory dump file. Use Windows Authentication for connections to Microsoft SQL Server.

Grant users only the necessary permissions in the data source

A data source administrator should grant only the necessary permissions to users.

Run applications with minimum permissions

When you allow a managed application to run with full-trust permission, the .NET Framework does not limit the application's access to your computer. This may enable a security vulnerability in your application to compromise the entire system. To use code access security and other security mechanism in the .NET Framework, you should run applications by using partial-trust permissions that are needed to enable the application to function. The following code access permissions are the minimum permissions your Telerik Data Access application needs:

FileIOPermission:Write to open the specified metadata files or PathDiscovery to search a directory for metadata files.
ReflectionPermission:RestrictedMemberAccess to support LINQ queries.
SecuritPermission:SerializationFormatter to serialize exceptions by using the ISerializable interface.
Permission to open a database connection and execute commands against the database.

Do not install untrusted applications

Telerik Data Access does not enforce any security permissions and will invoke any user-supplied data object code in process regardless of whether it is trusted or not. Ensure that authentication and authorization of the client is performed by the data store and by your application.

Restrict access to all configuration files

An administrator must restrict write access to all files that specify configuration for an application, including the application configuration file <application>.exe.config. The provider invariant name is modifiable in the app.config. The client application must take responsibility for accessing the underlying provider through the standard provider factory model by using a strong name.

Restrict permissions to the RLINQ file

An administrator must restrict write access to the RLINQ file to only users who modify the domain model. Telerik Data Access only requires read access to these files at run time.

Security Considerations for Queries

The following security considerations apply when querying a conceptual model. These considerations apply to LINQ queries using OpenAccessContext.

Prevent SQL injection attacks

Applications frequently take external input (from a user or another external agent) and perform actions based on that input. Any input that is directly or indirectly derived from the user or an external agent might have content that uses the syntax of the target language in order to perform unauthorized actions. When the target language is a Structured Query Language (SQL), such as Transact-SQL, this manipulation is known as a SQL injection attack. A malicious user can inject commands directly into the query and drop a database table, cause a denial of service, or otherwise change the nature of the operation being performed.

SQL injection attacks - SQL injection attacks can be performed in SQL by supplying malicious input to values that are used in a query predicate and in parameters names. To avoid the risk of injection, you should never combine user input with SQL command text.
LINQ to OpenAccessContext injection attacks - although query composition is possible in LINQ to OpenAccessContext, it is performed through the object model API. Unlike SQL queries, LINQ to OpenAccessContext queries are not composed by using string manipulation or concatenation, and they are not susceptible to traditional SQL injection attacks.

Prevent very large result sets

A very large result set could cause the client system to shut down if the client is performing operations that consume resources proportional to the size of the result set. Unexpectedly large result set can occur under the following conditions:

In queries against a large database that do not include appropriate filter conditions.
In queries that create Cartesian joins on the server.
In nested queries.

When accepting user input, you must make sure that input cannot cause result sets to become larger than what the system can handle. You can also use the Take method in LINQ to limit the size of the result set.

Avoid returning IQueryable results when exposing methods to potentially untrusted callers

Avoid returning IQueryable types from methods that are exposed to potentially untrusted callers for the following reasons:

A consumer of a query that exposes an IQueryable type could call methods on the result that expose secure data or increase the size of the result set. For example, consider the following method signature:
```
public IQueryable<Customer> GetCustomer(int customerId)
```
You can change the return type of the methods to IEnumerable and calling a method (such as .ToList) that materializes the results.
Because IQueryable queries are executed when the results are iterated over, a consumer of a query that exposes an IQueryable type could catch exceptions that are thrown. Exceptions could contain information not intended for the consumer.

Security Considerations for Persistent Classes

The following security considerations apply when generating and working with persistent classes.

Do not share a Telerik Data Access across application domains

Sharing an OpenAccessContext with more than one application domain may expose information in the connection string. Instead, you should transfer serialized objects or object graphs to the other application domain and then attach those objects to an OpenAccessContext in that application domain.

Prevent type safety violations

If type safety is violated, Telerik Data Access cannot guarantee the integrity of data in objects. If type safety is violated, Telerik Data Access cannot guarantee the integrity of data in objects. Type safety violations could occur if you allow untrusted applications to run with full-trust code access security.

Handle Exceptions

Access methods and properties of an OpenAccessContext within a try-catch block. Catching exceptions prevents unhandled exceptions from exposing entries in the domain model information to users of your application.

Security Considerations for ASP.NET Applications

The following should be considered when you work with paths in ASP.NET applications.

Verify whether your host performs path checks

When the |DataDirectory| (enclosed in pipe symbols) substitution string is used, Telerik Data Access verifies that the resolved path is supported. For example, ".." is not allowed behind DataDirectory. That same check for resolving Web application root operator (~) is performed by the process hosting ASP.NET. IIS performs this check, however, hosts other than IIS may not verify that the resolved path is supported. You should know the behavior of the host on which you deploy Telerik Data Access application.

Do not make assumptions about resolved path names

Although the values to which the root operator (~) and the DataDirectory substitution string resolve should remain constant during the application's runtime, Telerik Data Access does not restrict the host from modifying these values.

Verify the path length before deployment

Before deploying a Telerik Data Access application, you should ensure that the values of the root operator (~) and DataDirectory substitution string do not exceed the limits of the path length in the operating system.

Security Considerations for Telerik Data Access Metadata

The following security considerations apply when generating and working with domain model.

Do not expose sensitive information through logging

Telerik Data Access metadata service components do not log any private information. If there are results that cannot be returned because of access restrictions, database management systems and file systems should return zero results instead of raising an exception that could contain sensitive information.